Merge Vs Rebase

¡Muy buenas!

Soy Gabi Moreno y te doy la bienvenida al episodio número 52 de Productividad en el Desarrollo Android, el podcast donde hablamos sobre qué puedes hacer para ser una desarrolladora o desarrollador Android más eficaz y eficiente. Te contamos técnicas, hábitos, herramientas, conceptos, tips y todo aquello que te va a hacer crecer, sí o sí, porque hay algo que todos tenemos en común y es que el día dura 24 horas. Como inviertas o gastes este tiempo, es cosa tuya.

Merch o rebase. En este episodio te voy a explicar en qué consiste cada una de estas estrategias para incorporar cambios a las ramas de tu proyecto. Hay una regla de oro y es que no deberías de hacer rebase en una rama pública, es decir, rebase lo deberías de hacer siempre en ramas en las que estás trabajando local. Un ejemplo, imagínate que has hecho una pull request y esta llevaba un único commit.

Ahora, un compañero tuyo te sugiere que hagas unos cambios, los haces, creas un commit y haces push. Pues de nuevo, otro compañero más te sugiere que hagas una nueva modificación, nuevamente haces los cambios que toca, un commit, un push, la rama en remoto de esa PR.

Muy bien, ya ha pasado el sistema de integración continua y es el momento de incorporar los cambios a la rama principal, ya sea esta Master, Develop o la que sea. ¿Ves que hay algo que huele raro? ¿No crees que el histórico de Git se va a quedar un poco sucio? ¿No molaría más empacar estos dos últimos commits que has hecho en el primero de todos? Claro, no es que no estén aportando valor a dejar el historial de Git limpio y elegible, es que están restando literalmente, no son commits con digamos significado. Por lo tanto, este sería un buen ejemplo en el que podríamos hacer Rebase para dejarlo todo…