Learn for free

 

Se encuentran abiertas las inscripciones para los cursos Gugler!!!

¡Tengo grandes noticias! Estoy emocionado de anunciar que ya están abiertas las inscripciones para los tan esperados cursos Gugler. Si estás buscando avanzar en tu carrera, aprender nuevas habilidades, o simplemente profundizar tus conocimientos en áreas tecnológicas, ¡estos cursos son para ti!

Inscripciones abiertas del segundo cuatrimestre 2024. Inscripciones.gugler.com.ar

dotnet new gitignore

Cuando creo un nuevo proyecto en GitHub, lo primero que agrego en el repositorio inicial es el archivo .gitignore porque no quiero tener basura en mi repo. 

No mucha gente sabe que dotnet cli proporciona un comando para crear un archivo .gitignore, prácticamente perfecto.

En la carpeta raíz del proyecto, ejecutamos el siguiente comando :

dotnet new gitignore

Y listo! Se genera un archivo .gitignore con el siguiente contenido : 

## Ignore Visual Studio temporary files, build results, and

## files generated by popular Visual Studio add-ons.

##

## Get latest from https://github.com/github/gitignore/blob/main/VisualStudio.gitignore

# User-specific files

*.rsuser

*.suo

*.user

*.userosscache

*.sln.docstates

# User-specific files (MonoDevelop/Xamarin Studio)

*.userprefs

# Mono auto generated files

mono_crash.*

# Build results

[Dd]ebug/

[Dd]ebugPublic/

[Rr]elease/

[Rr]eleases/

x64/

x86/

[Ww][Ii][Nn]32/

[Aa][Rr][Mm]/

[Aa][Rr][Mm]64/

bld/

[Bb]in/

[Oo]bj/

[Ll]og/

[Ll]ogs/

# Visual Studio 2015/2017 cache/options directory

.vs/

# Uncomment if you have tasks that create the project's static files in wwwroot

#wwwroot/

# Visual Studio 2017 auto generated files

Generated\ Files/

# MSTest test Results

[Tt]est[Rr]esult*/

[Bb]uild[Ll]og.*

# NUnit

*.VisualState.xml

TestResult.xml

nunit-*.xml

# Build Results of an ATL Project

[Dd]ebugPS/

[Rr]eleasePS/

dlldata.c

# Benchmark Results

BenchmarkDotNet.Artifacts/

# .NET

project.lock.json

project.fragment.lock.json

artifacts/

# Tye

.tye/

# ASP.NET Scaffolding

ScaffoldingReadMe.txt

# StyleCop

StyleCopReport.xml

# Files built by Visual Studio

*_i.c

*_p.c

*_h.h

*.ilk

*.meta

*.obj

*.iobj

*.pch

*.pdb

*.ipdb

*.pgc

*.pgd

*.rsp

*.sbr

*.tlb

*.tli

*.tlh

*.tmp

*.tmp_proj

*_wpftmp.csproj

*.log

*.tlog

*.vspscc

*.vssscc

.builds

*.pidb

*.svclog

*.scc

# Chutzpah Test files

_Chutzpah*

# Visual C++ cache files

ipch/

*.aps

*.ncb

*.opendb

*.opensdf

*.sdf

*.cachefile

*.VC.db

*.VC.VC.opendb

# Visual Studio profiler

*.psess

*.vsp

*.vspx

*.sap

# Visual Studio Trace Files

*.e2e

# TFS 2012 Local Workspace

$tf/

# Guidance Automation Toolkit

*.gpState

# ReSharper is a .NET coding add-in

_ReSharper*/

*.[Rr]e[Ss]harper

*.DotSettings.user

# TeamCity is a build add-in

_TeamCity*

# DotCover is a Code Coverage Tool

*.dotCover

# AxoCover is a Code Coverage Tool

.axoCover/*

!.axoCover/settings.json

# Coverlet is a free, cross platform Code Coverage Tool

coverage*.json

coverage*.xml

coverage*.info

# Visual Studio code coverage results

*.coverage

*.coveragexml

# NCrunch

_NCrunch_*

.*crunch*.local.xml

nCrunchTemp_*

# MightyMoose

*.mm.*

AutoTest.Net/

# Web workbench (sass)

.sass-cache/

# Installshield output folder

[Ee]xpress/

# DocProject is a documentation generator add-in

DocProject/buildhelp/

DocProject/Help/*.HxT

DocProject/Help/*.HxC

DocProject/Help/*.hhc

DocProject/Help/*.hhk

DocProject/Help/*.hhp

DocProject/Help/Html2

DocProject/Help/html

# Click-Once directory

publish/

# Publish Web Output

*.[Pp]ublish.xml

*.azurePubxml

# Note: Comment the next line if you want to checkin your web deploy settings,

# but database connection strings (with potential passwords) will be unencrypted

*.pubxml

*.publishproj

# Microsoft Azure Web App publish settings. Comment the next line if you want to

# checkin your Azure Web App publish settings, but sensitive information contained

# in these scripts will be unencrypted

PublishScripts/

# NuGet Packages

*.nupkg

# NuGet Symbol Packages

*.snupkg

# The packages folder can be ignored because of Package Restore

**/[Pp]ackages/*

# except build/, which is used as an MSBuild target.

!**/[Pp]ackages/build/

# Uncomment if necessary however generally it will be regenerated when needed

#!**/[Pp]ackages/repositories.config

# NuGet v3's project.json files produces more ignorable files

*.nuget.props

*.nuget.targets

# Microsoft Azure Build Output

csx/

*.build.csdef

# Microsoft Azure Emulator

ecf/

rcf/

# Windows Store app package directories and files

AppPackages/

BundleArtifacts/

Package.StoreAssociation.xml

_pkginfo.txt

*.appx

*.appxbundle

*.appxupload

# Visual Studio cache files

# files ending in .cache can be ignored

*.[Cc]ache

# but keep track of directories ending in .cache

!?*.[Cc]ache/

# Others

ClientBin/

~$*

*~

*.dbmdl

*.dbproj.schemaview

*.jfm

*.pfx

*.publishsettings

orleans.codegen.cs

# Including strong name files can present a security risk

# (https://github.com/github/gitignore/pull/2483#issue-259490424)

#*.snk

# Since there are multiple workflows, uncomment next line to ignore bower_components

# (https://github.com/github/gitignore/pull/1529#issuecomment-104372622)

#bower_components/

# RIA/Silverlight projects

Generated_Code/

# Backup & report files from converting an old project file

# to a newer Visual Studio version. Backup files are not needed,

# because we have git ;-)

_UpgradeReport_Files/

Backup*/

UpgradeLog*.XML

UpgradeLog*.htm

ServiceFabricBackup/

*.rptproj.bak

# SQL Server files

*.mdf

*.ldf

*.ndf

# Business Intelligence projects

*.rdl.data

*.bim.layout

*.bim_*.settings

*.rptproj.rsuser

*- [Bb]ackup.rdl

*- [Bb]ackup ([0-9]).rdl

*- [Bb]ackup ([0-9][0-9]).rdl

# Microsoft Fakes

FakesAssemblies/

# GhostDoc plugin setting file

*.GhostDoc.xml

# Node.js Tools for Visual Studio

.ntvs_analysis.dat

node_modules/

# Visual Studio 6 build log

*.plg

# Visual Studio 6 workspace options file

*.opt

# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)

*.vbw

# Visual Studio 6 auto-generated project file (contains which files were open etc.)

*.vbp

# Visual Studio 6 workspace and project file (working project files containing files to include in project)

*.dsw

*.dsp

# Visual Studio 6 technical files

*.ncb

*.aps

# Visual Studio LightSwitch build output

**/*.HTMLClient/GeneratedArtifacts

**/*.DesktopClient/GeneratedArtifacts

**/*.DesktopClient/ModelManifest.xml

**/*.Server/GeneratedArtifacts

**/*.Server/ModelManifest.xml

_Pvt_Extensions

# Paket dependency manager

.paket/paket.exe

paket-files/

# FAKE - F# Make

.fake/

# CodeRush personal settings

.cr/personal

# Python Tools for Visual Studio (PTVS)

__pycache__/

*.pyc

# Cake - Uncomment if you are using it

# tools/**

# !tools/packages.config

# Tabs Studio

*.tss

# Telerik's JustMock configuration file

*.jmconfig

# BizTalk build output

*.btp.cs

*.btm.cs

*.odx.cs

*.xsd.cs

# OpenCover UI analysis results

OpenCover/

# Azure Stream Analytics local run output

ASALocalRun/

# MSBuild Binary and Structured Log

*.binlog

# NVidia Nsight GPU debugger configuration file

*.nvuser

# MFractors (Xamarin productivity tool) working folder

.mfractor/

# Local History for Visual Studio

.localhistory/

# Visual Studio History (VSHistory) files

.vshistory/

# BeatPulse healthcheck temp database

healthchecksdb

# Backup folder for Package Reference Convert tool in Visual Studio 2017

MigrationBackup/

# Ionide (cross platform F# VS Code tools) working folder

.ionide/

# Fody - auto-generated XML schema

FodyWeavers.xsd

# VS Code files for those working on multiple tools

.vscode/*

!.vscode/settings.json

!.vscode/tasks.json

!.vscode/launch.json

!.vscode/extensions.json

*.code-workspace

# Local History for Visual Studio Code

.history/

# Windows Installer files from build outputs

*.cab

*.msi

*.msix

*.msm

*.msp

# JetBrains Rider

*.sln.iml

##

## Visual studio for Mac

##

# globs

Makefile.in

*.userprefs

*.usertasks

config.make

config.status

aclocal.m4

install-sh

autom4te.cache/

*.tar.gz

tarballs/

test-results/

# Mac bundle stuff

*.dmg

*.app

# content below from: https://github.com/github/gitignore/blob/master/Global/macOS.gitignore

# General

.DS_Store

.AppleDouble

.LSOverride

# Icon must end with two \r

Icon

# Thumbnails

._*

# Files that might appear in the root of a volume

.DocumentRevisions-V100

.fseventsd

.Spotlight-V100

.TemporaryItems

.Trashes

.VolumeIcon.icns

.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share

.AppleDB

.AppleDesktop

Network Trash Folder

Temporary Items

.apdisk

# content below from: https://github.com/github/gitignore/blob/master/Global/Windows.gitignore

# Windows thumbnail cache files

Thumbs.db

ehthumbs.db

ehthumbs_vista.db

# Dump file

*.stackdump

# Folder config file

[Dd]esktop.ini

# Recycle Bin used on file shares

$RECYCLE.BIN/

# Windows Installer files

*.cab

*.msi

*.msix

*.msm

*.msp

# Windows shortcuts

*.lnk

Libros gratuitos de webcodegeeks

 

Download IT Guides!   The Best Web Programming Languages to Learn A more comprehensive list of tasks to which web development commonly refers, may include web engineering, web design, web content development, client liaison, client-side/server-side...     Web Developer Interview Questions A more comprehensive list of tasks to which web development commonly refers, may include web engineering, web design, web content development, client liaison, client-side/server-side...     Git Tutorial Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite...     Docker Containerization Cookbook Docker is the world's leading software containerization platform. Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code,...

Libros Gratuitos de Java Code Geeks

 

Download IT Guides!

Cracking the Leadership Code Yes, you can learn the skills to effectively lead people, organizations, and employees. With the right motivation and knowledge, you can be a leader who knows what it takes to succeed. Throughout his extensive experience in training leaders

Git Tutorial Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite option for developers,

Libros Gratuitos de Web Code Geeks

 

Download IT Guides!   Building Web Apps With Node.js Node.js applications are designed to maximize throughput and efficiency, using non-blocking I/O and asynchronous events. Node.js applications run single-threaded, although Node.js uses...     AngularJS Programming Cookbook It aims to simplify both the development and the testing of such applications by providing a framework for clientside model-view-controller (MVC) and model-view-viewmodel (MVVM)...     GWT Programming Cookbook Google Web Toolkit, or GWT Web Toolkit, is an open source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java. Other than a...     Git Tutorial Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite...

Libros Gratuitos de Java Code Geeks

 

Download IT Guides!   Docker Containerization Cookbook Docker is the world's leading software containerization platform. Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code,...     Git Tutorial Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite...     Spring Framework Cookbook The Spring Framework is an open-source application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application,...     Apache Hadoop Cookbook Apache Hadoop is an open-source software framework written in Java for distributed storage and distributed processing of very large data sets on computer clusters built from commodity...

Sextos pasos en GIT

Seguimos con GIT. 

Administrando branches : Si deseamos lista todas las branches :

$ git branch

Siempre hay una branch llamada ”master”, y es en la que comienzas por defecto.

Algunos aconsejan dejar la rama ”master” sin tocar y el crear nuevas branches para tus propios cambios. El branch ”master” es una convención útil. Otros pueden asumir que tu repositorio tiene un branch con este nombre, y que contiene la versión oficial del proyecto. Puedes renombrar o destruir la branch ”master”, pero también podrías respetar esta costumbre.

Después de un rato puedes notar que estás creando branches de corta vida de manera frecuente por razones similares: cada branch sirve simplemente para salvar el estado actual y permitirte saltar a un estado anterior para solucionar un bug de alta prioridad o algo.

Es análogo a cambiar el canal de la TV temporalmente, para ver que otra cosa están dando. Pero en lugar de apretar un par de botones, tienes que crear, hacer checkout y eliminar branches y commits temporales. Por suerte, Git tiene un atajo que es tan conveniente como un control remoto de TV:

$ git stash

Esto guarda el estado actual en un lugar temporal (un stash) y restaura el estado anterior. Tu directorio de trabajo se ve idéntico a como estaba antes de que comenzaras a editar, y puedes solucionar bugs, traer cambios desde otros repositorios, etc. Cuando quieras volver a los cambios del stash, escribe:

$ git stash apply

Puedes tener varios stashes, y manipularlos de varias maneras. Como es de imaginar, Git mantiene branches de manera interna para lograr este truco mágico.

Aplicaciones como Mozilla Firefox permiten tener varias pestañas y ventanas abiertas. Cambiar de pestaña te da diferente contenido en la misma ventana.

Los branches en git son como pestañas para tu directorio de trabajo. Siguiendo esta analogía, el clonar es como abrir una nueva ventana. La posibilidad de ambas cosas es lo que mejora la experiencia del usuario.

En un nivel más alto, varios window managers en Linux soportan múltiples escritorios. Usar branches en Git es similar a cambiar a un escritorio diferente, mientras clonar es similar a conectar otro monitor para ganar un nuevo escritorio.

Otro ejemplo es el programa screen. Esta joya permite crear, destruir e intercambiar entre varias sesiones de terminal sobre la misma terminal. En lugar de abrir terminales nuevas (clone), puedes usar la misma si ejecutas screen (branch). De hecho, puedes hacer mucho más con screen, pero eso es un asunto para otro manual.

Usar clone, branch y merge, es rápido y local en Git, animándote a usar la combinación que más te favorezca. Git te permite trabajar exactamente como prefieras.

Quintos pasos en GIT

Seguimos con GIT. 

Supongamos que estás trabajando en alguna prestación, y que por alguna razón, necesitas volver a una versión vieja y poner temporalmente algunos ”print” para ver como funciona algo. Entonces:

$ git commit -a
$ git checkout HASH_SHA1

Ahora puedes agregar cualquier código temporal horrible por todos lados. Incluso puedes hacer commit de estos cambios. Cuando termines,

$ git checkout master

para volver a tu trabajo original. Observa que arrastrarás cualquier cambio del que no hayas hecho commit.

¿Que pasa si quisieras cambiar los cambios temporales? Fácil:

$ git checkout -b sucio

y haz commit antes de volver a la branch master. Cuando quieras volver a los cambios sucios, simplemente escribe:

$ git checkout sucio

Al fin podemos contar toda la historia:los archivos cambian al estado pedido, pero debemos dejar al branch master. Cualquier commit de aquí en adelante, llevan tus archivos por un nuevo camino, el podrá ser nombrado posteriormente.

En otras palabras, luego de traer un estado viejo, Git automáticamente te pone en una nueva branch sin nombre, la cual puede ser nombrada y salvada con git checkout -b.

Algunos proyectos requieren que tu código sea evaluado antes de que puedas subirlo. Para hacer la vida más fácil para aquellos que revisan tu código, si tienes algún cambio grande para hacer, puedes partirlo en dos o mas partes, y hacer que cada parte sea evaluada por separado.

¿Que pasa si la segunda parte no puede ser escrita hasta que la primera sea aprobada y subida? En muchos sistemas de control de versiones, deberías enviar primero el código a los evaluadores, y luego esperar hasta que esté aprobado antes de empezar con la segunda parte.

En realidad, eso no es del todo cierto, pero en estos sistemas, editar la Parte II antes de subir la Parte I involucra sufrimiento e infortunio. En Git, los branches y merges son indoloros (un termino técnico que significa rápidos y locales). Entonces, luego de que hayas hecho commit de la primera parte y la

hayas enviado a ser revisada:

$ git checkout -b parte2

Luego, escribe la segunda parte del gran cambio sin esperar a que la primera sea aceptada. Cuando la primera parte sea aprobada y subida,

$ git checkout master

$ git merge parte2

$ git branch -d parte2  # ya no se necesita esta branch

y la segunda parte del cambio está lista para la evaluación. ¡Pero esperen! ¿Qué pasa si no fuera tan simple? Digamos que tuviste un error en la primera parte, el cual hay que corregir antes de subir los cambios. ¡No hay problema! Primero, vuelve a la branch master usando

$ git checkout master

Soluciona el error en la primera parte del cambio y espera que sea aprobado. Si no lo es, simplemente repite este paso. Probablemente quieras hacer un merge de la versión arreglada de la Parte I con la Parte II:

$ git checkout parte2

$ git merge master

Ahora es igual que lo anterior. Una vez que la primera parte sea aprobada:

$ git checkout master

$ git merge parte2

$ git branch -d parte2

y nuevamente, la segunda parte está lista para ser revisada. Es fácil extender este truco para cualquier cantidad de partes.

Quizás quieras trabajar en todos los aspectos de un proyecto sobre la misma branch. Quieres dejar los trabajos-en-progreso para ti y quieres que otros vean tus commits solo cuando han sido pulcramente organizados. Inicia un par de branches:

$ git checkout -b prolijo

$ git checkout -b mezcla

A continuación, trabaja en lo que sea: soluciona bugs, agrega prestaciones, agrega código temporal o lo que quieras, haciendo commits seguidos a medida que avanzas. Entonces:

$ git checkout prolijo

$ git cherry-pick HASH_SHA1

aplica un commit dado a la branch ”prolijo”. Con cherry-picks apropiados, puedes construir una rama que contenga solo el código permanente, y los commits relacionados juntos en un grupo.

Cuartos pasos en GIT

En Git, y otros sistemas de control de versiones distribuidos, clonar es la operación standard. Para obtener archivos se crea un clon de un repositorio entero. En otras palabras, prácticamente se crea una copia idéntica del servidor central. Todo lo que se pueda hacer en el repositorio principal, también podrás hacerlo.

Nosotros podemos inicializar un repositorio en un servidor central y luego clonarlo en nuestro equipo:

$ git clone otra.computadora:/ruta/a/archivos

y luego de clonarlo podemos hacer commit o pull :

$ git commit -a
$ git pull otra.computadora:/ruta/a/archivos HEAD

va a traer (pull) el estado de los archivos desde la otra máquina hacia la que estás trabajando. Si hiciste cambios que generen conflictos en un archivo, Git te va a avisar y deberías hacer commit luego de resolverlos.

Muchas veces deseamos hacer un fork de un proyecto, porque queremos probar una tecnología o porque queremos hacer cambios grandes, sin estorbar nuestro día a día por lo que podemos hacer un fork del proyecto y luego mergearlo cuando queramos,  Entonces en tu servidor:

$ git clone git://servidor.principal/ruta/a/archivos

Y luego clonamos dicho fork en cada uno de los cliente, si terminamos el cambio de tecnología podemos mergear con el repositorio principal.

Terceros pasos en GIT.

Seguimos con GIT. 

Cuando trabajamos de forma profesional debemos compartir nuestros cambios de forma tal de poder trabajar de forma colaborativa con nuestros compañeros, normalmente hacemos release cuando terminamos. Para hacer esto con Git, en el directorio donde guardamos nuestro código hacemos :

$ git init
$ git add .
$ git commit -m "Primer lanzamiento"

Entonces podemos decirle los otros desarrolladores que ejecuten:

$ git clone tu.maquina:/ruta/al/script

para descargar tu código. Esto asume que tienen acceso por ssh. Si no es así, podemos ejecutar git daemon y nuestros compañeros pueden usar:

$ git clone git://tu.maquina/ruta/al/script

De ahora en más, cada vez que necesitemos compartir código, escribimos :

$ git commit -a -m "Siguiente lanzamiento"

y los demás desarrolladores puede actualizar su versión yendo al directorio y ejecutando:

$ git pull

Averigua que cambios hiciste desde el último commit con:

$ git diff

O desde ayer:

$ git diff "@{yesterday}"

O entre una versión en particular y 2 versiones hacia atrás:

$ git diff SHA1_HASH "master~2"

En cada caso la salida es un patch (parche) que puede ser aplicado con git apply

Para ver cambios desde hace 2 semanas, se puede hacer:

$ git whatchanged --since="2 weeks ago"

Ojo ver esto se hace un tanto difícil, por lo que es una buena idea utilizar una software que nos deje ver los cambios de una forma más gráfica. Si te gusta la consola tig es una buena opción.

Segundos pasos en GIT

Sigamos revisando algunos comandos de GIT. Si necesitamos ir a un commit anterior debemos saber su id, el id es un hash del commit, por lo tanto podemos listar todos los commit recientes con :

$ git log

Luego podemos ir hasta el commit determinado con :

$ git reset --hard SHA1_HASH

Ojo esto va a borrar a los commit más nuevos. Pero si queremos saltar a un estado anterior temporalmente usamos :

$ git checkout SHA1_HASH

Esto te lleva atrás en el tiempo, sin tocar los commits más nuevos. Sin embargo,
como en los viajes en el tiempo de las películas de ciencia ficción, estarás en una
realidad alternativa, porque tus acciones fueron diferentes a las de la primera
vez. Esta realidad alternativa se llama branch (rama). Por ahora solo recordemos que :

$ git checkout master

te llevará al presente. También, para que Git no se queje, siempre debemos hacer un commit o resetear los cambios antes de ejecutar checkout.

Puedes elegir commits específicos para deshacer.

$ git commit -a
$ git revert SHA1_HASH

va a deshacer solo el commit con el hash dado. Ejecutar git log revela que el
revert es registrado como un nuevo commit.

Hasta ahora solo hemos  trabajado con nuestro repositorio local que es un poco raro, normalmente tambien tenemos un repositorio remoto donde poder compartir código con los demás desarrolladores. Si queremos obtener una copia de un repositorio remoto debemos clonar este repositorio:

$ git clone git://servidor/ruta/a/los/archivos

luego de clonarlo podemos obtener su última versión con pull :

$ git pull

Primeros pasos en GIT

Git es lo mejor que le pudo pasar al control de versiones pero a diferencia de SVN su potencia nos hace sufrir un poco. No es fácil de aprender, por lo tanto voy a escribir una serie de post con un resumen de lo que voy aprendiendo.

Antes de empezar a leer, espero que estés familiarizado con conceptos como control de versiones, conflictos, merge, branch, etc… Porque no tengo ganas de explicarlos :(

Antes, cada proyecto usaba un control de versiones centralizado un ejemplo es SVN. Un servidor en algún lado contenía todo el código. Nadie más los tenía. Cada programador tenía una versión y una parte del código. Cada tanto debíamos actualizar del servidor central, obteníamos la última versión del servidor principal, programábamos un rato y volvía a subir al servidor para que todos los demás
pudieran usarlo.

Cual es el problema de este esquema? Que si 2 desarrolladores quieren comparar 2 soluciones para un mismo problema, no lo pueden hacer sin subir al repositorio central y eso esta mal porque no saben cual solución debe ser la mejor para ser compartida.  GIT soluciona este problema utilizando un modelo distribuido, en el cual cada cliente tiene un repositorio y existe uno o varios repositorios remotos. De esta manera podemos subir nuestros cambios al repositorio local, comparar las soluciones y luego subirlas al repositorio compartido. A la vez el repositorio local contiene todo el historial del código, de esta manera es innecesario comunicación con el repositorio remoto para retornar a una versión antigua.

Al empezar con GIT podemos tomar un repositorio remoto o obtar por utilizar nuestro repositorio local. Veamos como podemos tener un proyecto y mantenerlo en el repositorio local:

Inicio el repositorio con init
$ git init
Agrego todos los archivos de esa carpeta
$ git add .
Hago commit es decir subo los archivos al repositorio
$ git commit -m "Mi primer commit"

Si deseamos volver a la version del repositorio:
$ git reset --hard

Si añades nuevos archivos o subdirectorios, deberás decirle a Git:
$ git add ARCHIVOSNUEVOS…

De manera similar, si quieres que Git se olvide de determinados archivos, porque (por ejemplo) los borraste:
$ git rm ARCHIVOSVIEJOS…

Renombrar un archivo es lo mismo que eliminar el nombre anterior y agregar el
nuevo. También puedes usar git mv que tiene la misma sintaxis que el comando
mv de linux. Por ejemplo:
$ git mv ARCHIVOVIEJO ARCHIVONUEVO

Y por este post estuvimos bien... 

Libros gratis de Java Code Geeks

Download IT Guides!   Git Tutorial Git is, without any doubt, the most popular version control system. Ironically, there are other version control systems easier to learn and to use, but, despite that, Git is the favorite...     Spring Framework Cookbook The Spring Framework is an open-source application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application,...     Apache Hadoop Cookbook Apache Hadoop is an open-source software framework written in Java for distributed storage and distributed processing of very large data sets on computer clusters built from commodity...     Selenium Programming Cookbook Selenium is a portable software testing framework for web applications. Selenium provides a record/playback tool for authoring tests without learning a test scripting language (Selenium...