Git es un software de control de versiones diseñado para el mantenimiento de código de aplicaciones con muchos archivos. Permite el desarrollo no lineal y la gestión distribuida de proyectos mediante la copia local de repositorios. El documento explica cómo instalar Git, crear y clonar repositorios, realizar commits de cambios locales, trabajar con ramas para desarrollar funcionalidades de forma aislada y fusionarlas, y cómo resolver conflictos y deshacer cambios cuando surgen errores.

1. Intro a GIT
Guía práctica

2. ¿Qué rayos es GIT?
Es un software de control de versiones creado por el
señor Linus Torvalds por allá del 2005.
Pensado para el mantenimiento del código de
aplicaciones con muchos archivos fuente.
Permite el desarrollo no-lineal y una gestión
distribuida del proyecto (cada usuario tiene una
copia local del proyecto).

3. ¿Por qué es importante?
● Control de la versión actual
● El trabajo local de una persona no afecta a
todos los demás
● Permite hacer tracking de cada línea
modificada de los archivos
● Permite conocer quién hizo qué cambios
● El trabajo local permite experimentar
‘diferentes soluciones’

4. ¿Por dónde
comenzamos?
➔ Instalación
➔ Creando un repositorio
➔ Flujo de trabajo
➔ Add & commit
➔ Repositorios remotos
➔ Ramas
➔ Merge
➔ Cuando sale mal
➔ Publicar versión

5. Instalación de GIT
https://git-scm.com/downloads

6. Creando un repositorio
1. Crear uno localmente “desde cero”
$ git init
1. Clonar un repositorio existente
$ git clone <path_to_repo>
Tip
Las formas más comunes de
clonar son vía HTTP y SSH.
Clonar vía SSH solo se
permite si tienes configurada
una key y permisos.
https://help.github.com/enterpr
ise/2.10/user/articles/generatin
g-a-new-ssh-key-and-adding-it-
to-the-ssh-agent/

7. Los repositorios de GIT
tienen 3 estados locales
principales:
workspace,
stage/index y
HEAD
Flujo de trabajo

8. Manos a la obra
¿Cómo añado mis cambios al repositorio?
➔ add
Añade los archivos
modificados/creados a la sección de
stage
➔ rm
Elimina los archivos del tracking de GIT
➔ commit
Añade los cambios que actualmente
están en stage a HEAD. Es necesario
especificar un mensaje que indique los
cambios realizados

9. Add & commit
1. Crea un archivo de texto y añade algunas líneas
2. Revisamos el estado del archivo untracked
$ git status
1. Añadimos el archivo al índice
$ git add file.txt; git add -A
1. Añadimos esa versión a HEAD
$ git commit -m “ ”
Tip
git commit -m <msg>
te permite agregar el
mensaje directamente al
commit. Ej.
git commit -m
“Actualizar el csv
de uniones civiles”

10. ¿Qué guardar y qué no?
Sí:
● Código fuente
● Archivos locales totalmente
necesarios
● Archivos de configuración que no
interfieran entre colaboradores y
sean necesarios para el proyecto
● README.md
Tip
Haz cambios
relacionados em un solo
commit cada vez antes
de continuar el
desarrollo.
Story for illustration purposes only
No:
● Dependencias del proyecto que
puedan ser instaladas desde la
configuración del proyecto.
● Archivos de configuración del IDE.
● Archivos temporales o muy
confidenciales.
● Archivos muy grandes.
● La serie completa de Game of
Thrones.
Todos estos
se añaden a
un archivo
.gitignore

11. Del local al remoto
Cuando se clona un repositorio este traerá por
defecto la info de la URL donde se encuentra el
repositorio remoto.
$ git remote -v
Si se creó de manera local (git init) se puede
agregar la url
$ git remote add origin <url>
Servicios de hosting

12. Subiendo cambios
Existen dos principales acciones que ocurren
de un local a un remoto. TRAER cambios y
SUBIR cambios.
➔ fetch
Trae los cambios existentes en el
HEAD del repositorio (revisa si hay
cambios)
➔ pull
Trae los cambios existentes en el
HEAD del repositorio y los integra al
local
➔ push
Actualiza el HEAD del repositorio con
los cambios del HEAD local.

13. Subir cambios
1. Revisa los cambios existentes en HEAD y en workplace
$ git log
$ git status
1. Sube los cambios que se encuentran
en HEAD local al repositorio remoto
$ git push origin <rama>
Warning!
Si estas trabajando
colaborativamente y te
marca un error de
referencias “ref push” es
porque alguien más ha
subido cambios y debes
actualizar tu local
haciendo pull.

14. Las ramas son utilizadas
para desarrollar
funcionalidades aisladas
unas de otras. La rama
master es la rama "por
defecto".
Múltiples features,
múltiples ramas

15. Creando ramas
➔ branch <nombre>
Crea una nueva rama pero no te
cambia a ésta.
➔ checkout -b <nombre>
Crea una nueva rama y te cambia a
ésta.
➔ checkout <nombre>
Te cambia a la rama solo si ya existe
➔ branch -d <nombre>
Elimina la rama

16. Nueva funcionalidad
1. Crear una nueva rama a partir de la actual
$ git branch <branch_name>
1. Cambiarte a la nueva rama
$ git checkout <branch_name>
1. Agrega la nueva funcionalidad y haz
commit de los cambios
Tip
Crear y cambiarte
2x1
Puedes crear una nueva
rama y cambiarte
usando
git checkout -b
<branch_name>

17. Trabajo en paralelo
1. Cambia de nuevo a master y crea una nueva rama
$ git checkout master
$ git checkout -b <new branch>
1. Agrega la nueva funcionalidad y haz
commit de los cambios
Tip
Se recomienda que el
nombre de la rama esté
relacionado al feature
correspondiente y a
quién lo está trabajando
Revisa las ramas
existentes con
git branch -a

18. Cuando se trabajan con
diferentes funcionalidades
es necesario integrarlas
todas sobre una misma
rama para lanzar una
versión funcional.
Hora de la verdad
integrar features

19. Integrando
funcionalidad
➔ diff
Muestra la diferencia entre dos ramas,
dos commits, o simplemente entre el
workplace y HEAD.
➔ merge
Integra el trabajo de dos historias, es
decir, dos ramas, del local y el remoto,
o de dos commits en particular

20. Integra la primera feature
1. Cambia de nuevo a master y crea una nueva rama
$ git checkout master
$ git checkout -b <rama_integradora>
1. Dentro de esta rama integra el trabajo de
la rama 1
$ git merge <branch_feature1
Tip
Existen diferentes
estrategias de
integración que te
permiten darle prioridad
a cierta historia, intentar
mezclarlas, o
simplemente avanzar si
parten del mismo punto.

21. Integra la segunda feature
Ambas ramas partieron del mismo punto, al integrar la primera se hizo
un merge fast-forward, sin complicaciones. Ahora a ésta, integraremos
la nueva funcionalidad.
1. Estando en la rama de integración
intentaremos ahora añadir la 2a feature
$ git checkout <rama_integradora>
$ git merge <branch_feature2>
Tip
Revisa muy bien que la
funcionalidad sea la
esperada después de
hacer un merge y
resolver conflictos antes
de enviarlo al remoto..

23. No es sorpresa que al haber modificado las
mismas cosas exista un conflicto.
GIT nos ayuda
mucho pero
tampoco lee tu
mente.
Tip
La limpieza y el orden
en el proyecto serán
claves para hacer el
merge menos doloroso.
Siempre debes estar
seguro que las
versiones que intentas
mezclar son funcionales.

24. Cuando se modifican las mismas
líneas GIT no sabe cuál es la buena
y debes resolver el conflicto con tu
editor de texto favorito
Lo que tenía actualmente lo verás
entre las líneas
<<<<<<< HEAD
===========
Lo que vino del merge, lo verás
entre
============
>>>>>>> <rama o commit>
Tip
El comando git diff te
dirá exactamente cuáles
son las líneas diferentes
entre cada versión.

25. Una vez resueltos los problemas, puedes
añadir los cambios a stage y hacer commit
$ git add <files in
conflict>
$ git commit -m “Merge de la
feature 2, se conservaron
ambos trabajos”

26. Oops! You did it again.
Las cosas no siempre
fluyen tan simple y a veces
cometemos errores de
capa 8.
Pero por fortuna, tienes
salvación.
git log
Algo hice mal :(

27. Ctrl+Z de GIT
➔ checkout <file or commit>
Restablece el archivo a lo que se encuentra
en HEAD local.
Si se usa un commit, establece un estado
detached.
➔ stash
Guarda los cambios actuales workplace en
un estado temporal, revierte los cambios
visibles al último estado en HEAD.
➔ revert <commit_mal>
Crea un nuevo commit que deshace todos
los cambios del commit indicado. Es el
modo más seguro de devolver un commit.

28. Otros útiles Ctrl+Z
➔ revert -m <n> <merge_commit_mal>
Deshace un commit de merge que salió
mal. Es necesario especificar en <n> el
‘padre’ al que regresará (1 o 2)
➔ commit --amend -m “Correct msg”
Corrige el mensaje del último commit. Útil
si eres un loco de la ortografía. Solo se
debe usar en local, nunca en un commit
que ya fue publicado.
➔ reset --hard <commit>
Forza a que el repo local esté justo en el
commit indicado,

29. Deshaciendo commits
1. Modifica el archivo y haz un commit intencional
2. Revierte el commit usando revert
$ git revert <hash_commit>
1. Trabaja sobre diferentes ramas y
haz un merge. Revierte el merge.
$ git revert -m <n> <commit_merge>
Warning
Es importante tener
cuidado con este tipo de
comandos, y evitar subir
cambios de manera
forzada.

30. ¡Lo hemos conseguido!
Has trabajado sobre el repositorio y ahora tienes
una versión publicable con todas las
funcionalidades incluidas.
Haz merge request a master ¡y publica una etiqueta
para identificar tu versión 1.0!
$ git tag 1.0.0 <commit>