Git with gifs
Click here to load reader
-
Upload
betabeers -
Category
Technology
-
view
398 -
download
4
description
Transcript of Git with gifs
with gifs
Sistemas de
control de versiones
Gestionan los cambios realizados
sobre diversos elementos a lo
largo del tiempo.
Git
• Diseñado por Linus Torvalds para
Linux.
• Git: distribuido, rápido y
eficiente.
• Branches: ramas del repositorio.
• Commits: guardado de cambios.
• Merge: mezcla de los commits de
distintas ramas.
• Push/Pull: sincronización con el
repositorio remoto.
Conceptos básicos
No tenemos nada
en contra de SVN
pero...
...cuando un nuevo
empleado dice que
prefiere usar SVN
antes que Git...
Workflow ideal
• Desarrollo en ramas de largo recorrido
(master/develop).
• Rama master para versiones estables.
• Ramas puntuales:
o features: nuevas funcionalidades.
o releases: para congelar una versión.
o fixes: corrección de bugs.
• Nunca commits directos
sobre master.
• Develop estable
=> merge a master.
Desarrollo
• Nuevas features siempre
nacen de develop.
• Features finalizadas siempre
vuelven a develop y se borran.
Features
• Nuevas releases siempre nacen de develop.
• Releases finalizadassiempre vuelven a
master y develop.
• Se congela la release
en un tag.
Releases
• Fixes siempre nacen
de master.
• Fixes vuelven amaster y develop.
• Se genera unanueva versión.
Fixes
Siguiendo esto...
...pero no siempre
es aplicable.
Una mañana
cualquiera en
Simplelógica...
Tenemos marrones
Muchas veces nos
gustaría...
Pero es nuestro
trabajo...
• Periodo de desarrollo menos
prolongado.
• Cambios imprevistos.
• Entorno de pre-producción para el
cliente.
Con clientes
Nuestro workflow
• Desarrollo en ramas de largo recorrido
(master/staging).
• Rama master para entorno en producción.
• Rama staging para pre-producción.
• Ramas puntuales:
o features: nuevas funcionalidades.
o fixes: corrección de bugs.
• Nuevas features nacen de master.
• Features finalizadas se pasan a staging
para que las pruebe el cliente.
• Fixes vuelven a master y staging.
• Nunca commits directos en staging.
• Staging totalmente desechable.
Diferencias
Buenas prácticas
• Almacena los cambios actuales en
una pila independiente.
• Te deja en el último commit.
• Puede recuperarse más tarde.
git stash
Cuando lo
descubres...
Cuando lo
controlas...
Y para lo que lo
acabas usando...
• Cuando tenemos algo a medias y
hay que hacer un cambio urgente.
• Cuando no estamos trabajando en
la rama adecuada.
• Para desechar rápido las últimas
modificaciones.
Es útil
• Crea siempre ramas puntuales para hacer
commits ¡Son gratis!
• Haz commits pequeños que abarquen lógica
común ¡También son gratis!
• Configura los merges con --no-ff,
aportan estructura, +info y salud.
Organiza tu trabajo
Evitarás
cosas como...
• Indica el último autor de un
cambio en una línea de código.
• Permite culpar a otro cuando el
código apesta.
git blame
Cuando alguien
va a hacer un
git blame...
...si el autor es un
compañero...
...pero la mayoría de
las veces...
También permite mezclar ramas,
pero reescribe la historia.
git rebase
Mola pero...
No hagas rebase a commits que ya
estén distribuidos.
Podríamos crear una paradoja
espacio-temporal y que el
universo se plegara sobre sí
mismo.
el problema de rebase
Haz caso a Doc,
sabe mucho
del tiempo
• Configura el rebase por defectode
pull (por una historia más
bonita).
• Haz pull siempre antes de push.
pull y push
Evitarás
cosas como...
Y siempre puedes
cagarla...
• git reflog: rebusca
• git reset: reinicia
• git revert: deshaz
Cuando todo se rompe
Seguramente
tenga solución
¡GRACIAS!
¿Preguntas?
https://twitter.com/maguilag
https://github.com/rsierra
http://goo.gl/49vdf (Presentación)