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)