Para fusionar una rama de desarrollo en la rama actual, use «git merge dev-branch-name». Si recibe advertencias de conflicto sobre una combinación, use «git merge –abort» para salir de ella, o edite los archivos afectados y luego confírmelos.
Git usa ramas para aislar flujos de desarrollo, para evitar que la rama de lanzamiento estable se contamine. Llevar el trabajo de una sucursal al flujo principal significa fusionar las sucursales. Así es como lo haces.
¿Qué es una fusión en Git?
Git fue diseñado para hacer que la bifurcación sea simple y rápida. A diferencia de otros sistemas de control de versiones, ramificarse en Git es un asunto trivial. Especialmente en proyectos de múltiples desarrolladores, la ramificación es una de las principales herramientas organizativas de Git.
Las ramas prueban nuevos esfuerzos de desarrollo para que el código se pueda modificar o agregar sin afectar el código en otras ramas, especialmente la rama principal o principal. Esto generalmente contiene la versión estable de su base de código.
Aislar estos cambios de su versión de código estable tiene mucho sentido. Pero tarde o temprano, el nuevo código se probará, revisará y aprobará para incorporarlo a la rama principal. En ese momento, debe fusionar su rama con la rama principal.
En realidad, las sucursales pueden tener sub-sucursales, por lo que podría estar fusionando su sucursal con alguna otra sucursal en lugar de la sucursal principal. Solo recuerda que las fusiones siempre toman una rama y la fusionan en una objetivo rama, cualquiera que sea esa rama. Si desea fusionar su rama maestra en otra rama, incluso puede hacerlo también.
Como la mayoría de las acciones en Git, realiza fusiones en su repositorio local y las envía a su repositorio remoto.
Preparándose para fusionar una rama en Git
Tenemos un pequeño proyecto de desarrollo con un repositorio Git local y un repositorio Git remoto. Creamos una rama llamada «bugfix14» de la rama «maestra» y trabajamos en una solución a un error.
Ese trabajo está completo y hemos probado nuestro código. Todo funciona como se esperaba. Queremos implementar esos cambios en la rama maestra para que nuestra solución sea parte de la próxima versión del software.
Hay que hacer un poco de preparación antes de realizar la fusión. Necesitamos asegurarnos de que la rama de destino (en este caso, la rama «maestra») y la rama que vamos a fusionar con ella estén actualizadas.
Para ello utilizaremos el git status dominio.
git status
- En la rama bugfix14: Esta es nuestra sucursal actual.
- Su rama está actualizada con ‘origen/corrección de errores’: La rama en nuestro repositorio local tiene el mismo historial de confirmaciones que la rama en el repositorio remoto. Eso significa que son idénticos.
- nada que cometer No hay cambios en el área de preparación que no se hayan confirmado.
- árbol de trabajo limpio: No hay cambios no preparados en el directorio de trabajo.
Todo eso indica que la rama está actualizada y que podemos continuar. Si alguno de estos indicara que existieron cambios, necesitaríamos organizarlos, confirmarlos y enviarlos al control remoto. Si alguien más ha trabajado en estos archivos, es posible que debamos extraer sus cambios del repositorio remoto.
Revisar la rama en la que nos vamos a fusionar simplifica el proceso de fusión. También nos permite verificar que está actualizado. Echemos un vistazo a la rama maestra.
git checkout master
git status
Obtenemos las mismas confirmaciones de que la rama «maestra» está actualizada.
RELACIONADO: Cómo elegir el modelo de ramificación y flujo de trabajo de Git adecuado para su equipo
Realizar una fusión
Antes de fusionarnos, nuestras confirmaciones se ven así.
La rama «bugfix14» se bifurcó de la rama «maestra». Hubo un compromiso con la rama «maestra» después de que se creó la rama «bugfix14». Ha habido un par de confirmaciones en la rama «bugfix14».
Nos hemos asegurado de que nuestras dos sucursales estén actualizadas y hemos verificado la sucursal «maestra». Podemos emitir el comando para fusionar la rama «bugfix14» en la rama «maestra».
git merge bugfix14
Se produce la fusión. La rama «bugfix14» aún existe, pero ahora los cambios que se realizaron en esa rama se fusionaron en la rama «maestra».
En este caso, el comando merge realiza una fusión de tres vías. Solo hay dos ramas, pero hay tres compromisos involucrados. Son el encabezado de cualquiera de las ramas y una tercera confirmación que representa la acción de fusión en sí.
Para actualizar nuestro repositorio remoto, podemos usar el empujar git dominio.
git push
Algunas personas prefieren eliminar las ramas laterales una vez que las han fusionado. Otros se encargan de preservarlos como un registro de la verdadera historia de desarrollo del proyecto.
Si desea eliminar la sucursal, puede hacerlo mediante el git branch comando con el -d (eliminar) opción.
git branch -d bugfix14
Para eliminar la rama en el repositorio remoto, use este comando:
git push origin --delete bugfix14
Tendrás un historial de confirmación lineal, pero no será el verdadero historial.
RELACIONADO: Cómo eliminar ramas de Git en repositorios locales y remotos
Realizar una combinación de avance rápido en Git
Si no ha realizado ninguna confirmación en la rama «maestra», su historial se verá así. También tendrá este aspecto si ha modificado la base de su rama de desarrollo para que se adjunte al final de la rama «maestra».
Debido a que no hay confirmaciones en la rama «maestra», para fusionar la rama «bugfix15», todo lo que Git tiene que hacer es apuntar el puntero principal «maestro» a la última confirmación de la rama «bugfix15».
Podemos usar lo habitual git merge dominio:
git merge bugfix15
Eso nos da este resultado.
Que es lo mismo que esto:
Que es lo mismo que esto:
Git realizará una fusión de avance rápido siempre que puede. Si las confirmaciones en la rama «maestra» significan que no es posible una fusión de avance rápido, Git usará un fusión de tres vías.
no puedes fuerza una combinación de avance rápido, después de todo, puede que no sea posible, pero puede declarar que será una combinación de avance rápido o nada. Hay una opción que le indica a Git que use una combinación de avance rápido si puede, pero que no haga una combinación de tres vías si no puede. la opción es --ff-only (solo combinación de avance rápido).
Esto fusiona la rama «bugfix15» en la rama «maestra», pero solo si es posible una fusión de avance rápido.
git merge --ff-only bugfix15
Git se quejará y saldrá si no es posible.
git merge --ff-only bugfix16
En este caso, ha habido compromisos con la rama «maestra», por lo que no es posible una fusión de avance rápido.
Cómo resolver conflictos de fusión en Git
Si se han cambiado las mismas partes del mismo archivo en ambas ramas, las ramas no se pueden fusionar. Se requiere interacción humana para resolver las ediciones conflictivas.
Aquí, hemos realizado cambios en un archivo llamado «rot.c» en una rama llamada «bugfix17» que queremos fusionar con la rama «maestra». Pero «rot.c» también se ha cambiado en la rama «maestra».
git merge bugfix17
Cuando intentamos fusionarlo, recibimos una advertencia de que hay conflictos. Git enumera los archivos en conflicto y nos dice que la fusión falló. Podríamos retroceder completamente usando el --abort opción:
git merge --abort
Pero resolver fusiones no es tan aterrador como parece. Git ha hecho algo de trabajo para ayudarnos. Si editamos uno de los archivos en conflicto, en nuestro caso, solo tenemos uno, encontraremos las secciones de código en conflicto resaltadas para nosotros.
Cada conflicto está delimitado por siete caracteres menores que “<<<<<<<” y siete caracteres mayores que “>>>>>>>“, con siete signos de igual”=======» entre ellos.
- El código sobre los signos de igual es de la rama que estás fusionando en.
- El código debajo del signo igual es el código de la sucursal que está intentando unir.
Puede buscar fácilmente uno de los conjuntos de siete caracteres y pasar de un conflicto a otro a través de su archivo. Para cada conflicto, debe elegir qué conjunto de ediciones va a conservar. Debe editar el código que está rechazando y las líneas de siete caracteres que ha agregado Git.
Vamos a mantener el código de la rama «bugfix17». Después de editar, nuestro archivo se ve así.
Ahora podemos continuar con la fusión. Pero tenga en cuenta que usamos el commit comando para hacerlo, no el merge dominio.
Confirmamos el cambio preparando el archivo y confirmándolo como de costumbre. Comprobaremos el estado antes de realizar la confirmación final.
git add rot.c
git status
git commit -m "Merged bugfix17"
La fusión está completa. Ahora podemos enviar esto a nuestro repositorio remoto.
RELACIONADO: Cómo corregir, editar o deshacer confirmaciones de Git (cambio del historial de Git)
Todo se fusiona eventualmente
Todas las ramas deben fusionarse, eventualmente, para que los cambios en ellas no queden huérfanos y olvidados.
Fusionar sucursales es fácil, pero lidiar con conflictos puede complicarse en equipos ocupados y más grandes. La resolución de conflictos puede requerir el aporte de cada desarrollador solo para explicar qué hace su código y por qué hicieron los cambios. Debe comprender eso, antes de que pueda tomar una decisión informada sobre qué ediciones conservar.
Lamentablemente, Git no puede ayudar con eso.
RELACIONADO: ¿Debería usar un cliente GUI Git?