MergeyRebaseson dos técnicas comunes en Git que se utilizan para integrar cambios de una rama en otra. Ambas técnicas puedencumplir el mismo finpero tienen importantes diferencias que debes tener en cuenta al decidir cuál usar. Las diferencias Mergeimplica fusionar dos ramas en una sola, creando un nuevo punto de unión en el historial del repositorio. Esto significa que al hacer unmergese unen dos ramas. Si el historial de commits está alineado, elmergeno crea un nuevo commit y usa el fast-forwardpara avanzar la rama a la que se le están incorporando los cambios. Si no es posible, se crea un nuevo commit de tipomergepara incorporar los cambios de la rama.
Imagina una rama “feature” como el de la imagen. Queremos incorporar los cambios de “main” a “feature”. Al ejecutar “git merge feature main”, nos crearía un commit (el de asterísco) en la rama donde queremos incorporar los cambios de la otra.
Rebaseimplica reordenar los cambios, lo que significa que se replican los cambios de la rama en la que se está trabajando sobre la otra. Esto resulta en una sola línea de commitsen el historial, que muestra una secuencia lineal de cambios.
Imagina una rama “feature”. Al ejecutar “git rebase main feature” se moverían los commits de la rama “feature” a la rama “main”.
mergeempuja el historial hacia adelante, mientras querebasereordena el historial de commits sin necesidad de crear nuevos commits (simplemente aplica los que ya existen).
¿Qué ventajas y desventajas tienen?
Antes de elegir entremergey rebase, debes tener en cuenta las ventajas y desventajas de cada uno. Ventajas de merge
- Es más fácil de entender para los nuevos usuarios de Git. - Aunque hace que el historial este más sucio de commits de merge, te da una visión real de lo que ha ido ocurriendo en la rama. - No existe ningún peligro ya que no reescribe el historial de commits. Lo peor que puede pasar es que tengas que resolver conflictos.
Desventajas demerge- Si usasmergecon frecuencia de una rama muy activa, tu historial de commits se llenará constantemente de commits demergeque no aportan valor. - Al generar commits de merge, añades carga al historial y en repositorios grandes puede ralentizar el proceso de clonado.
Ventajas derebase- El historial de commits queda más limpio y es más fácil de seguir la evolución del código ya que no se generan commits demergeinnecesarios.
Desventajas derebase- Es más difícil de entender para los nuevos usuarios de Git. - Reescribir el historial de commits es peligroso. Puedes causar problemas muy graves si no tienes cuidado. - Pierdes información sobre cuando se han incorporado los cambios en la rama.
¿Cuándo usar cada uno?
Ahora que ya conoces las ventajas y desventajas de cada uno, es hora de elegir cuál usar. Y, para mi, la respuesta es simple:usamergepara integrar cambios en una rama principalyusarebasepara integrar cambios en una rama de desarrollo.
O, dicho de otro modo: nunca usaríarebaseen una rama principal. Nitampoco en una rama pública donde más personas están trabajando.
Otra regla, bastante acertada, es usarrebasesólo en código que todavía no has compartido en un repositorio remoto. Nunca, nunca, nunca hagas rebase de algo que has compartido, ya que eso reescribiría el historial de commits y causaría problemas para los demás.
Este punto está basado en mi experiencia personal. Otras personas consideran que lo correcto es usar siemprerebaseen lugar de merge, ya que así el historial de commits queda más limpio. Sin embargo, yo prefiero usarmergepara integrar cambios en una rama pública, ya que así puedo ver fácilmente cuándo se han incorporado los cambios en la rama y evito problemas de reescritura del historial de commits al trabajar en equipo. Además, considero queun historial de commits limpio es menos importante que tener un historial de commits que refleje la realidad.