Git para principiantes, creada por Daniel Rodríguez Troitiño y presentada el 21 de septiembre de 2011 en el Hub de Madrid

1. ---
+++

2. ¿QUÉ ES GIT?
Lo primero que nos preguntamos es qué es exactamente Git.

3. Git es un sistema de control de
versiones distribuido de código
abierto diseñado para ser
rápido y eficiente
- Un sistema de control de versiones permite a sus usuarios almacenar revisiones diferentes
de un mismo archivo y compararlas, restaurarlas y, a veces, mezclarlas.

4. ¿POR QUÉ GIT?

5. No es Subversion
(o CVS, o RCS, o copiar directorios)
- Subversion fue creado hace más de diez años como evolución de CVS (que era una
evolución de RCS), pero al intentar ser una evolución, era un simple “parche” de su padre.

6. Garantiza la integridad de los datos
Git utiliza hashes SHA1 y en ocasiones criptografía para garantizar que todo el mundo tiene
los mismos datos y que estos no han sido modificados sin el conocimiento de los usuarios.
Quizá para un desarrollo personal esto no tenga sentido, pero para proyectos open source y
empresas sí lo tiene.

7. Sin repositorio central
Frente a SCM antiguos Git no necesita de un repositorio central o canónico, aunque tampoco
impide designar uno de los clones del repositorio como canónico. Esto permite una
flexibilidad imposible con otros sistemas, y muchas ventajas.

8. Cada usuario tiene un backup
completo del repositorio
Los repositorios de cada usuario son un clon completo, y no una copia parcial de la última
versión. En el caso de fallo catastrófico de un supuesto repositorio central, no es necesario
más que clonar un repositorio de uno de los usuarios.

9. Se puede trabajar offline
El disponer de un repositorio completo, un usuario puede realizar todas las operaciones que
desee con su copia local, y sincronizarla con otras copias cuando vuelva a estar conectado.

10. ¡Es rápido!
Al realizar todas las operaciones en local, no es necesario esperar al servidor para ver un log
de cambios, comparar con una versión anterior y otras operaciones.

11. PRIMEROS PASOS

12. Si habéis instalado Xcode 4 ya disponéis de un Git suficiente moderno para utilizar, y no hay
que hacer mucho más.
Personalmente el soporte de Xcode 4 me parece de broma. La vista de comparar versiones es
la única que posiblemente se salva, y no es tan buena. Ni siquiera es capaz de manejar muy
bien conflictos en el archivo de proyecto, lo que hace que el 50% de la veces casque.

13. GITX (L)
http://gitx.laullon.com
Mi recomendación es utilizar la Terminal y GitX. GitX es un cliente gráfico para Git, muy bien
enfocado y sencillo. No puede hacer todas las cosas, pero las que hace, las hace muy bien.
Hay muchas versiones de GitX. La original está más o menos abandonada. Luego apareció la
de brotherbard, y la que utilizo últimamente es la de Laullón.

14. Esta es la vista de para hacer commits. Cuando trabajo con Xcode siempre mantengo una
terminal en el directorio por si necesito teclear algún comando y GitX con el proyecto abierto.

15. INSTALACIÓN
http://git-scm.com
Si queréis una versión más moderna podeis instalar Git desde el código fuente o un sistema
de paquetes como Homebrew.

16. $ git config --global user.name "Juan Pérez"
$ git config --global user.email juan.perez@example.com
Algo que no he encontrado como hacer en Xcode. Esto toca hacerlo en el Terminal. Sólo es
necesario hacerlo una vez.

17. $ git config --global core.editor "mate -w"
# o "nano -w"
# o "emacs"
# o "vim"
Otras configuraciones globales si os gusta trabajar en la terminal es elegir el editor que Git
invocará cuando necesite que editeis algún mensaje de commit o similares…

18. $ git config --global merge.tool opendiff
Y la herramienta que utilizará para mostrar las mezclas conflictivas (opendiff es una
herramienta gráfica que se instala con Xcode)

19. $ git config --global color.ui auto
Y finalmente para darle un toque de color a esa triste terminal.

20. UN WORKFLOW
Hay muchos posibles workflows con Git. Cada uno adecuando a un modo de desarrollar y a
un tipo de equipo. El kernel de Linux no utiliza repositorio centrales y forma una especie de
pirámide de responsables y utiliza “pull requests” mediante el correo electrónico. En
empresas lo normal es un repositorio central. Y hay muchas más. Git te da la libertad de
diseñar tu propio workflow.

21. GIT INIT
$ mkdir PajaritosCabreados; cd PajaritosCabreados
$ git init
Initialized empty Git repository in /Users/daniel/
PajaritosCabreados/.git/
$
Desde la terminal crear un repositorio es tan sencillo como crear un directorio y ejecutar “git
init” dentro de él. Git creará un directorio oculto dónde almacenará toda la información que él
necesite.

22. Desde Xcode, cuando se crea un nuevo proyecto y vamos a elegir un directorio para
almacenarlo se puede elegir crear un repositorio para el proyecto. A menos de que tengáis
una razón muy buena, todos los nuevos proyectos deberían estar bajo control de versiones,
aunque simplemente sea local.

23. Vamos a crear nuestro primer archivo, en el que incluiremos algún contenido.

24. GIT STATUS
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# main.m
nothing added to commit but untracked files present
(use "git add" to track)
$
Desde la terminal, en cualquier momento podemos ejecutar “git status” para comprobar en
que estado están nuestros archivos. Git incluye mucha información en él: la rama en la que
estamos, el número de commits por delante o por detrás de la rama del repositorio remoto,…
pero sobre todo el estado de los archivos. En este momento lo que nos dice es que hay un
archivo main.m del que no sabe nada.

25. GIT ADD
$ git add main.m
$
La primera orden a aprender es “git add”. Git no incluye ningún contenido al repositorio al
que no hayamos hecho un “git add”. La forma más normal es “git add nombre.archivo”, que
añade todos los cambios del archivo al “staging area” de Git.

26. $ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: main.m
#
$
Si ejecutamos “git status” a continuación veremos que Git lo marca como “new file”.

27. Pero me he dado cuenta de que me faltaba una pequeña cosa, así que voy a editar de nuevo
el archivo y añadir una línea más.

28. $ git status
# On branch master
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: main.m
#
# Changed but not updated:
# (use "git add <file>..." to update what will be
committed)
# (use "git checkout -- <file>..." to discard changes
in working directory)
#
# modified: main.m
#
$
En este momento si ejecutamos “git status” veremos algo curioso: un archivo está en dos
estados para Git: nuevo y modificado. Esta es una de las principales diferencias de Git, y una
de sus mejores características. Git no sigue a los archivos, sino a los contenidos; y el archivo
main.m tiene un contenido que hemos añadido al “staging area”, pero otro contenido (la línea
de la anterior diapositiva) que no, así que considera que el archivo está modificado. Podemos
añadir esa línea haciendo otro “git add”.

29. GIT COMMIT
$ git commit
Finalmente, para crear una nueva revisión se ejecutará “git commit”, que toma todos los
cambios del “staging area” y crea una revisión con ellos. Ningún cambio en el directorio de
trabajo que no esté en el “staging area” se incluirá en la revisión.

30. Git nos abrirá nuestro editor de texto dónde podremos escribir una pequeña descripción del
cambio realizado y sus motivos.

31. GIT COMMIT
$ git commit
[master (root-commit) 9108af0] Main function
1 files changed, 8 insertions(+), 0 deletions(-)
create mode 100644 main.m
$

32. …RINSE AND REPEAT
Ya solo queda repetir el proceso de modificar los archivos, añadir los cambios al “staging
area” y crear las nuevas revisiones.

33. ¡AYUDA!
Git es muy amplio, esto es el proceso más sencillo y habitual, pero falta mucho por explicar
como los remotos, las ramas y muchas otras cosas.
Si necesitáis ayuda tenéis varios recursos a vuestra disposición.

34. $ git help <orden>
$ git <orden> --help
El primero es la ayuda en línea de Git. Con “git help” o “git --help” se pueden leer las páginas
de manual de Git. Las páginas de los mandatos básicos están muy bien redactadas e incluyen
ejemplos en la parte final.

35. DOCUMENTACIÓN
http://git-scm.com/documentation
Si preferís Internet el sitio de Git incluye mucha documentación y enlaces a tutoriales propios
y externos.

36. PRO GIT
http://progit.org
Finalmente existe Pro Git, un libro gratuito que trata Git desde novato a experto. Existe una
versión en ePub muy bien preparada para el iPad.