![GIT COMMIT
$ git commit
[master (root-commit) 9108af0] Main function
1 files changed, 8 insertions(+), 0 deletions(-)
create mode 100644 main.m
$](https://image.slidesharecdn.com/git-para-principiantes-110925061335-phpapp01/85/Git-para-principiantes-31-320.jpg)
Git para-principiantes
- 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.
- 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.