Your SlideShare is downloading. ×
0
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Git: un enfoque práctico
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Git: un enfoque práctico

705

Published on

En muchos tutoriales de git se ignoran cuestiones importantes. Por ejemplo, la configuración de claves e identidad del usuario son cosas cruciales para una buena experiencia con git. …

En muchos tutoriales de git se ignoran cuestiones importantes. Por ejemplo, la configuración de claves e identidad del usuario son cosas cruciales para una buena experiencia con git.
En esta presentación se explica el proceso desde cero, orientado tanto a quienes quieren usarlo desde consola, como a desarrolladores que deseen emplearlo desde Eclipse.
Los ejemplos tratan de emular un proceso de desarrollo real basado en ramas, con conflictos entre diferentes desarrolladores.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
705
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
38
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Patxi Gortázar (@fgortazar)
  • 2.  Aprender a configurar Git en Windows y Linux  Comprender el funcionamiento de Git mediante ejercicios en un hipotético proceso de desarrollo  Sólo  En pareja  Adquirir destrezas para utilizar Git tanto desde consola como desde Eclipse
  • 3.  PhD ciencias de la computación  Investigo en resolución heurística de problemas de optimización  + 15 años de experiencia en el desarrollo sw  Pasión por mejorar y hacer más eficiente el proceso de desarrollo  Java expert (~15 años), Spring, Maven, TDD, Jenkins...  Definiendo el proceso de desarrollo  Pasión por comunicar y discutir...  Cursos profesionales de Maven, Java, Optimización de la JVM, Git, Jenkins, Sonar...  En la universidad... Programación funcional, concurrente, desarrollo de aplicaciones distribuidas, compiladores...
  • 4.  Introducción  El proceso de desarrollo  Git en práctica
  • 5.  Git es un SCM distribuido (DSCM)  Cada desarrollador tiene una copia del repositorio  No hay concepto de repositorio centralizado ▪ Ya… pero al final suele haberlo
  • 6.  Características:  Snapshots  Integridad  Los 3 estados  Las 3 áreas  La identidad
  • 7.  Características: Snapshots  No se guardan diferencias… se guardan snapshots
  • 8.  Características: Integridad  Los commits se identifican por un hash sha1 ▪ Svn: rev 33 ▪ Git: d025a7b3217f05110ebbf48065b8d02a0ad22ae3 ▪ O más amigablemente: d025a7b  Los ficheros también se identifican por su sha1 ▪ Si un fichero se corrompe durante la transmisión por la red se detecta inmediatamente
  • 9.  Características: Los 3 estados  Los ficheros en git pueden estar en tres estados: ▪ Modificado: el fichero ha cambiado desde el último checkout ▪ Staged: un fichero modificado ha sido marcado para ser añadido en el próximo commit ▪ Committed: el fichero se encuentra en la base de datos de git  Hay un 4º estado: untracked
  • 10.  Características: Las 3 áreas de un proyecto git  El directorio git (git directory) ▪ Contiene los metadatos y la base de datos de git ▪ Es lo que se copia cuando se clona un repositorio ▪ Normalmente es una carpeta .git en algún directorio  La carpeta de trabajo (working directory) ▪ Es un checkout de una versión específica del proyecto ▪ Se extrae del directorio git ▪ Es el espacio donde modificamos los ficheros  Staging area ▪ Fichero en el directorio .git que indica qué cambios van en el próximo commit
  • 11.  Características: La identidad  Git necesita conocer algunos datos del desarrollador (aparecen en los commits para identificar al autor) ▪ Nombre ▪ Email  Si no están correctamente configurados… atente a las consecuencias ▪ Los commits fallan porque el usuario no está autorizado ▪ Commits del mismo usuario “físico” no son considerados como del mismo usuario porque el nombre “lógico” cambia
  • 12.  Características: La identidad (y 2)  ~/.gitconfig: patxi@patxi-PORTEGE-R830:~$ cat .gitconfig [user] name = patxigortazar email = patxi.gortazar@gmail.com > git config --global user.name “patxigortazar” > git config --global user.email “patxi.gortazar@gmail.com” gitrepo> git config user.name “patxigortazar” gitrepo> git config user.email “patxi.gortazar@gmail.com” Follow The Yellow Brick Road: http://git-scm.com/book/en/Customizing-Git-Git-Configuration
  • 13.  Características: La identidad (y 3)  Who am I? patxi@patxi-PORTEGE-R830:~$ git config --list user.name=patxigortazar user.email=patxi.gortazar@gmail.com
  • 14.  Clientes git  En Eclipse ▪ Egit (viene por defecto en las últimas versiones)  CLI Linux client ▪ sudo apt-get install git  Windows ▪ Msysgit: http://code.google.com/p/msysgit/downloads/ ▪ Tortoise Git (requiere msysgit): http://code.google.com/p/tortoisegit/wiki/Download  Mac ▪ SourceTree: http://www.sourcetreeapp.com/ ▪ Gitbox (simple): http://www.gitboxapp.com/
  • 15.  Introducción  El proceso de desarrollo  Git en práctica
  • 16.  Desarrollo en canales  2 ramas de forma continua ▪ master: limpio, sólo versiones estables ▪ develop  el desarrollo inicial de la versión actual tiene lugar aquí  Ramas para estabilización ▪ release-1.0 una rama de estabilización cada vez ▪ release-1.1 ▪…
  • 17.  Ramas de estabilización  Estabilizar código (release candidates)  Arreglar bugs (hotfixes)  Cuando la versión se considera estable ▪ Tag ▪ Mezclar con development ▪ Mezclar con master  Si surgen nuevos bugs ▪ Se arreglan en la misma rama (release-0.1) ▪ Nuevo tag y mezcla
  • 18.  Releasing…  Checkout del tag  Build (Jenkins)  Deploy (Jenkins)
  • 19. El tiempo fluye hacia arriba Este es el commit inicial
  • 20. Cada commit conoce a su padre
  • 21. …o a sus padres Cada commit conoce a su padre
  • 22.  Introducción  El proceso de desarrollo  Git en práctica
  • 23.  Prerequisitos  STS 3.3.0 ▪ http://www.springsource.org/downloads/sts-ggts ▪ Escoger la opción basada en Eclipse 4.3 ▪ Incluye Egit y Maven  Para usar los ejemplos de la línea de comandos… ▪ Cliente git (ver clientes git en la introducción)
  • 24.  Paso 1: generación de claves  Generar claves para el acceso al repositorio remoto ▪ Ubuntu ▪ ssh-keygen -t rsa ▪ Copiar el contenido del fichero ~/.ssh/id_rsa.pub en el depósito de claves de la cuenta personal de Gerrit ▪ Windows ▪ Git bash ▪ ssh-keygen.exe ▪ Copiar el contenido del fichero c:/documents and settings/<usuario>/.ssh/id_rsa.pub
  • 25.  Paso 2: clonar el repositorio  El administrador del proyecto ha creado un repositorio en Gerrit con dos ramas: ▪ master ▪ develop
  • 26.  Paso 2: clonar el repositorio  Clonar el repositorio remoto tiene consecuencias: ▪ El repositorio local guarda localmente información sobre el repositorio remoto (llamado por defecto “origin”) ▪ Esto permite subir/bajar cambios al/desde repositorio remoto ▪ Las ramas refs/heads/* del repositorio remoto se almacenan en el repositorio local como refs/remotes/origin/* ▪ Ver .git/config
  • 27.  Paso 2: clonar el repositorio  Clonar el repositorio remoto ▪ Eclipse ▪ ▪ ▪ ▪ ▪ Perspectiva Git repository exploring Clone a git repository  URI ssh://patxi@code.sidelab.es:29418/patxitraining Branch selection: dejar ambas seleccionadas Initial branch: seleccionar development
  • 28.  Paso 2: clonar el repositorio  Clonar el repositorio remoto ▪ CLI: ▪ git clone ssh://patxi@code.sidelab.es:29418/patxitraining ▪ Git hace checkout de la rama master por defecto (porque es donde se encuentra el HEAD posicionado en el repositorio remoto) > git checkout develop Branch development set up to track remote branch development from origin. Switched to a new branch 'development' ▪ La rama develop local queda asociada a la rama develop remota
  • 29.  Paso 3: crear el proyecto  Crear un proyecto Java ▪ org.filetransfer ▪ Crear un fichero de versión en la raíz ▪ Version.txt  0.1 ▪ Crear un fichero SFTPTransfer en el paquete org.filetransfer
  • 30.  Paso 3: compartir el proyecto en git  Añadirlo al repositorio git del proyecto filetransfer ▪ Team > Share project… > Git ▪ Repository: patxitraining
  • 31.  Paso 3: compartir el proyecto en git  Añadir los ficheros para que Eclipse haga tracking de los mismos ▪ Team > Add to index  CLI: ▪ git status ▪ git add <file>
  • 32.  Paso 3: compartir el proyecto en git  Commit! ▪ Sobre el proyecto > Team > Commit… ▪ El comentario es obligatorio ▪ Chequear ▪ Que el autor es el correcto ▪ Que están marcados los ficheros adecuados ▪ Que no está marcada la casilla “Push the changes to upstream”  CLI: ▪ git commit
  • 33.  Paso 4: desarrollo de la versión actual  Añadir algún método más a la clase ▪ git status ▪ Hay ficheros no añadidos al staging area  no se hará commit de ellos
  • 34.  Paso 4: desarrollo de la versión actual  Añadir algún método más a la clase ▪ git status ▪ Hay ficheros no añadidos al staging area  no se hará commit de ellos ▪ git add <fichero> ▪ Para añadirlos al staging area y que vayan en el próximo commit ▪ git status
  • 35.  Paso 4: desarrollo de la versión actual  Añadir algún método más a la clase ▪ git status ▪ Hay ficheros no añadidos al staging area  no se hará commit de ellos ▪ git add <fichero> ▪ Para añadirlos al staging area y que vayan en el próximo commit ▪ git status ▪ En Eclipse esto se hace automáticamente al hacer commit ▪ En consola se puede forzar con ▪ git commit -a  Commit
  • 36.  Paso 5: subir cambios al repositorio remoto (push)  En este momento el repositorio local se encuentra “a 2 commits” del repositorio remoto
  • 37.  Paso 5: subir cambios al repositorio remoto (push)  En este momento el repositorio local se encuentra “a 2 commits” del repositorio remoto
  • 38.  Paso 5: subir cambios al repositorio remoto (push)  Subir lo que hay a la rama develop de origin (el repositorio remoto) ▪ Sobre el proyecto > Team > Push to upstream ▪ git push origin
  • 39.  Paso 6: estabilización de la versión 0.1  Crear un branch para la versión ▪ Sobre el proyecto > Team > Switch to > New branch… ▪ From: refs/heads/development ▪ Branch name: release-0.1 ▪ Asegurarse de que checkout new branch está activado ▪ git checkout -b release-0.1 --track ▪ git push -u origin release-0.1  El código del workspace señala ahora la versión release-0.1 ▪ Hacer algún cambio ▪ Commit
  • 40.  Paso 6: estabilización de la versión 0.1  Cambiar en la rama develop la versión a 0.2 ▪ Sobre el proyecto > Team > Switch to > develop ▪ Modificar el fichero version.txt ▪ Commit ▪ Push to upstream
  • 41.  Paso 7: Hacer un tag  Tag en la rama release-0.1 ▪ Eclipse ▪ Team > Advanced > Tag > 0.1.0-RC1 ▪ Team > Remote > Push… > Next > Add all tags spec ▪ CLI ▪ git tag -a 0.1.0-RC1 -m “Release 0.1.0-RC1” ▪ git push origin 0.1.0-RC1  Build/test/deploy…
  • 42.  Paso 8: Merge: integrar los cambios en develop  Team > Switch to > develop  Team > Merge > Tags > 0.1.0-RC1  Conflictos en el fichero version.txt!! ▪ Abrir el fichero version.txt ▪ Dejar la versión 0.2 y quitar todo lo demás ▪ Para indicar que los conflictos han sido resueltos: ▪ Sobre el fichero > Team > Add to index ▪ git add <fichero> ▪ Commit
  • 43.  Paso 9: Panic mode!  Si todo va mal en un merge… Reset ▪ Resetea el repositorio al estado en el que estaba en un commit anterior ▪ Actualiza el indice (base de datos de git), el HEAD y la carpeta de trabajo con la versión que le digamos ▪ git reset --hard <commit hash> ▪ Team > Reset… > elegir un branch > Marcar HARD
  • 44.  Paso 10: obtener cambios del repositorio remoto (pull)  En pareja  ▪ Rol A: el propietario del repo ▪ Se situa en la rama develop ▪ Rol B ▪ se clona el repo de A ▪ Hace checkout de la rama develop  A ▪ modifica el fichero java ▪ hace commit ▪ y después push
  • 45.  Paso 10: obtener cambios del repositorio remoto (pull)  B obtiene los cambios ▪ Sobre el proyecto > Team > Fetch from upstream ▪ Obtiene el índice de cambios ▪ Sobre el proyecto > Team > Pull
  • 46.  Paso 10: obtener cambios del repositorio remoto (pull)  ¿Qué pasa si otro desarrollador subió cambios que entran en conflicto con los míos? ▪ A modifica el constructor ▪ B modifica el constructor de otra manera diferente ▪ A y B hacen push del repositorio ▪ El último que llega está obligado a hacer un pull y resolver los conflictos
  • 47.  Paso 10: obtener cambios del repositorio remoto (pull)  ¿Qué pasa si otro desarrollador subió cambios que entran en conflicto con los míos? ▪ Obtener los cambios ▪ Team > Fetch from upstream ▪ Team > Pull ▪ Los cambios se mezclan y git marca los conflictos
  • 48.  Paso 10: obtener cambios del repositorio remoto (pull)  ¿Qué pasa si otro desarrollador subió cambios que entran en conflicto con los míos? ▪ Corregir (mezclar) ▪ Añadir la mezcla ▪ git add ▪ git commit ▪ git push
  • 49.  Comandos útiles  git log ▪ Información de los commits  git log -p -2 ▪ Información de lo que ha cambiado en los últimos dos commits  git log --graph
  • 50.  Deshacer acciones  git commit --amend ▪ Sustituir el último commit por uno nuevo ▪ Un amend pueda cambiar: ▪ El mensaje del commit ▪ Los ficheros del commit (añadiendo nuevos ficheros al staging area antes de hacer git commit --amend)  Para deshacer acciones en el pasado: ▪ http://sidelab.wordpress.com/2013/10/26/arreglando-elhistorico-en-git/
  • 51. Patxi Gortázar (@fgortazar)

×