Git: un enfoque práctico
-
Upload
francisco-gortazar -
Category
Technology
-
view
710 -
download
5
description
Transcript of Git: un enfoque práctico
Objetivos
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
Who am I?
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...
Introducción
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
Introducción
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
Introducción
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
Introducción
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
Introducción
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
Introducción
Características: La identidad (y 2) ~/.gitconfig:
patxi@patxi-PORTEGE-R830:~$ cat .gitconfig [user]
name = patxigortazaremail = [email protected]
> git config --global user.name “patxigortazar”> git config --global user.email “[email protected]”
Follow The Yellow Brick Road:http://git-scm.com/book/en/Customizing-Git-Git-Configuration
gitrepo> git config user.name “patxigortazar”gitrepo> git config user.email “[email protected]”
Introducción
Características: La identidad (y 3) Who am I?
patxi@patxi-PORTEGE-R830:~$ git config [email protected]
Introducción
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/
El proceso de desarrollo
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▪ …
El proceso de desarrollo
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
Git en práctica
Prerequisitos STS 3.3.0▪ http://www.springsource.org/downloads/sts-gg
ts▪ 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)
Git en práctica
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
Git en práctica
Paso 2: clonar el repositorio El administrador del proyecto ha creado
un repositorio en Gerrit con dos ramas:▪ master▪ develop
Git en práctica
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
Git en práctica
Paso 2: clonar el repositorio Clonar el repositorio remoto▪ Eclipse▪ Perspectiva Git repository exploring▪ Clone a git repository URI▪ ssh://[email protected]:29418/patxitraining▪ Branch selection: dejar ambas seleccionadas▪ Initial branch: seleccionar development
Git en práctica
Paso 2: clonar el repositorio Clonar el repositorio remoto▪ CLI:▪ git clone ssh://[email protected]:29418/patxitraining
▪ Git hace checkout de la rama master por defecto (porque es donde se encuentra el HEAD posicionado en el repositorio remoto)
▪ La rama develop local queda asociada a la rama develop remota
> git checkout developBranch development set up to track remote branch development from origin.Switched to a new branch 'development'
Git en práctica
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
Git en práctica
Paso 3: compartir el proyecto en git Añadirlo al repositorio git del proyecto
filetransfer▪ Team > Share project… > Git▪ Repository: patxitraining
Git en práctica
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>
Git en práctica
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
Git en práctica
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 en práctica
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
Git en práctica
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
Git en práctica
Paso 5: subir cambios al repositorio remoto (push) En este momento el repositorio local se
encuentra “a 2 commits” del repositorio remoto
Git en práctica
Paso 5: subir cambios al repositorio remoto (push) En este momento el repositorio local se
encuentra “a 2 commits” del repositorio remoto
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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…
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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
Git en práctica
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-el-historico-en-git/