Usando Merge y Rebase en Conjunto para Ordenar Commits

La idea de este primer ayudamemoria para mi, y tutorial para quien este buscando resolver el mismo problema que yo encontré, que es como dejar lo mas prolijo y consistente la historia de commits una vez que deseamos mergear branches, en general el escenario entre una nueva funcionalidad a desarrollar y el master. Esto implica el uso de los comandos Merge y Rebase en su conjunto. NO me voy a ir por las ramas de que significan cada uno ; hay mucho en google. La idea es un ejemplo simple y practico de cómo:

1.- Entender como se resuelven dudas de uso con git , es decir con Sandbox y jugando , como cualquier cosa en desarrollo
2.- Con el mismo ejemplo evidenciar el problema la solución propuesta y el alcance del mismo

Atención ! los de svn se sentirán afuera un poco , esto es para los que usamos git, pero en fin, mi recomendación , aun con lo dificil que puede parecer al principio, traten de aprender esta poderosísima herramienta de versionado. Redunda en una forma de trabajar mas prolija, ordenada, y de hecho al día de hoy pienso que mas standard con el modelo de desarrollo internacional.

Vamos al Ejemplo!

Creo una carpeta y la inicializo como repositorio (esto va a ser nuestro SandBox):

~ user$ mkdir a1

~ user$ cd a1/

~/a1 user$ git init

Initialized empty Git repository in ~/a1/.git/

Ahora creo un archivo , lo adiciono y lo commiteo:

~/a1 user$ touch c1;git add . ;git commit -m "c1"

[master (root-commit) 1eb77d0] c1

0 files changed

create mode 100644 c1

Vemos que se creo nuestro primer commit, para este ejercicio no importan los push, es simplemente ver como ordenamos los commits

~/a1 user$git log --oneline

1eb77d0 c1

Creamos un nuevo branch, donde vamos a implementar nuestras nuevas funcionalidades

~/a1 user$ git checkout -b otro

Switched to a new branch 'otro'

Creamos un archivo en este nuevo branch, pueden ser los n commits necesarios

~/a1 user$ touch c2;git add . ;git commit -m "c2"

[otro aacf167] c2

0 files changed

create mode 100644 c2

Ok ,volvamos al master

~/a1 user$ git checkout master

Switched to branch 'master'

Ahora , estoy creando algo nuevo , pero la idea es la misma que si hiciesemos un pull del repositorio, es decir aparece un commit nuevo que seria el úlitmo del master:

~/a1 user$ touch c3;git add . ;git commit -m "c3"

[master 969be85] c3

0 files changed

create mode 100644 c3

Si vemos el master vemos que tenemos el original, c1 y el nuevo , c3

~/a1 user$ git log --oneline

969be85 c3

1eb77d0 c1

Aca es donde empieza lo que suele confundir; hacemos un merge con nuestro branch de nuevas funcionalidades:

~/a1 user$ git merge otro

Merge made by the 'recursive' strategy.

0 files changed

create mode 100644 c2

Al hacer un merge con lo que teniamos de nuestro branch , genera un commit nuevo de Merge, que lo podemos ver en un editor vim; al guardarlo , veremos esto si pedimos ver los logs:

~/a1 user$ git log --oneline

d2ee2d1 Merge branch 'otro'  → este es el crea la herramienta y nos molesta!

969be85 c3

aacf167 c2

1eb77d0 c1

Como sacamos ese commit molesto de Merge? 

Queremos dejar la historia como debería ser, es decir el commit que vino del 'supuesto' pull (el c3 ) dejarlo atras para sumar nuestra nueva funcionalidad

Bueno aqui es donde hacemos un rebase contra el id de commit que es anterior a los cambios, en este caso el c1, que como podemos ver su Id , reducido ( ver git log , para ver el completo ) es eb77d0

~/a1 user$ git rebase -i 1eb77d0

Al ejecutar el comando anterior nos aparecerá una nueva pantalla de vim ( ó el editor de consola que tengamos seleccionado en su bash ) indicándonos que queremos hacer con los commits en adelante; Aquí surgen varias posibilidades ( squash , borrar , etc ) pero no me quiero meter en eso; no es a lo que apunto, lo importante es que en este caso particular , no hacemos nada ; simplemente guardamos lo que el editor nos propone y aparecerá el siguiente mensaje:

Successfully rebased and updated refs/heads/master.

Si pedimos ver nuevamente como quedo la historia veremos

~/a1 user$ git log --oneline

f8bfa0a c2

969be85 c3

1eb77d0 c1

Notar que c2 ahora posee un nuevo Id, esto es porque squasheo nuestro cambio con el merge, pero dejo la historia como queríamos es decir nuestro cambio como último de la lista.  

y si hay conflictos ? ufff

Bueno en este caso deberemos ir editando a mano para solucionar los conflictos, haremos git add  para agregar los cambios y git rebase --continue; hasta lograr el final de la historia.

Esto ultimo se escapa de la idea del tutorial; pero estimo que con la idea de armar sandbox, podrán ir jugando y practicando hasta emular el escenario que desean resolver .

Gracias por leer hasta acá ! sean pacientes!