Puedes configurar las opciones de fusión para una solicitud de extracción en tu instancia de GitHub Enterprise Server para que éstas satisfagan las necesidades de tu flujo de trabajo y tus preferencias para administrar el historial de Git. Para obtener más información, consulta la sección "Configurar las fusiones de solicitudes de extracción". Puedes implementar un tipo de método de fusión, como el cambio de base o la combinación de confirmaciones, con solo activar el método deseado para tu repositorio.
Cuando haces clic en la opción predeterminada Merge pull request (Fusionar solicitud de extracción) en una solicitud de extracción de tu instancia de GitHub Enterprise Server, todas las confirmaciones de la rama de característica se agregan a la rama de base en una confirmación de fusión. La solicitud de extracción se fusiona usando la opción --no-ff.
Para fusionar solicitudes de extracción, debes tener permisos de escritura sobre el repositorio.
El método de fusión predeterminado crea una confirmación de fusión. Puedes impedir que cualquiera suba confirmaciones de fusión en una rama protegida imponiendo un historiar de confirmaciones linear. Para obtener más información, consulta la sección "Acerca de las ramas protegidas".
Combinar tus confirmaciones de fusión
Cuando seleccionas la opción Squash and merge (Combinar y fusionar) en una solicitud de extracción en la tu instancia de GitHub Enterprise Server, las confirmaciones de la solicitud de extracción se combinan en una única confirmación. En lugar de ver todas las confirmaciones individuales de un contribuyente de una rama de tema, las confirmaciones se combinan en una confirmación y se fusionan en la rama predeterminada. Las solicitudes de extracción con confirmaciones combinadas se fusionan usando la fast-forward option (opción de avance rápido).
Para combinar y fusionar solicitudes de extracción, debes tener permisos de escritura en el repositorio, y el repositorio debe permitir la fusión de combinaciones.
Puedes combinar y fusionar para crear un historial Git más optimizado en tu repositorio. Los compromisos de trabajo en curso son útiles cuando se trabaja en una rama de característica, pero no son tan importantes para retenerlos en el historial Git. Si combinas estas confirmaciones en una única confirmación al fusionar con la rama predeterminada, puedes conservar los cambios originales usando un historial Git claro.
Antes de activar combinar confirmaciones, considera estas desventajas:
- Se pierde información acerca de cuándo se hicieron originalmente los cambios específicos y quién es el autor de las confirmaciones combinadas.
- Si sigues trabajando en la rama principal de una solicitud de extracción después de combinar y fusionar, y luego creas una solicitud de extracción nueva entre las mismas ramas, las confirmaciones que ya hayas combinado y fusionado se listarán en la solicitud de extracción nueva. También podrías tener conflictos que tienes que resolver constantemente en cada solicitud de extracción sucesiva. Para obtener más información, consulta "Acerca de las fusiones de las solicitudes de extracción".
- Es posible que sea más difícil usar algunos comandos de Git que usan el ID "SHA" o "hash", ya que se pierde el ID SHA para las confirmaciones originales. Por ejemplo, es posible que no sea tan efectivo usar
git rerere.
Para obtener más información, consulta "Configurar la combinación de confirmaciones para las solicitudes de extracción".
Cambiar de base y fusionar tus confirmaciones
Cuando seleccionas la opción Rebase and merge (Cambiar de base y fusionar) en la tu instancia de GitHub Enterprise Server, todas las confirmaciones de la rama de tema (o rama de encabezado) se agregan a la rama de base por separado sin una confirmación de fusión. De esta forma, el comportamiento de fusión y rebase asemeja a una fusión rápida manteniendo un historial linear del proyecto. Sin embargo, el rebase lo logra al rescribir el historial de confirmaciones en la rama base con confirmaciones nuevas.
El comportamiento de cambio de base y de fusión en GitHub Enterprise Server varía levemente con respecto a git rebase. El cambio de base y la fusión en GitHub siempre actualizarán la información de la persona que confirma el cambio y crearán nuevas SHA de confirmación, mientras que el git rebase externo a GitHub no cambia la información de la persona que confirma el cambio cuando ocurre el cambio de base superponiendo un compromiso de antepasado. Para obtener más información sobre git rebase, consulta git-rebase en la documentación de Git.
Para cambiar de base y fusionar solicitudes de extracción, debes tener permisos de escritura en el repositorio, y el repositorio debe permitir la fusión de cambio de base.
Para obtener una representación visual de git rebase, consulta el capítulo "Ramas de Git - Cambio de base" del libro Pro Git.
Antes de activar cambiar de base las confirmaciones, considera estas desventajas:
-
Es posible que los colaboradores del repositorio tengan que cambiar de base en la línea de comandos, resolver cualquier conflicto y realizar un empuje forzado de sus cambios a la rama de tema de la solicitud de extracción (o rama de encabezado remota) antes de poder usar la opción cambiar de base y fusionar en tu instancia de GitHub Enterprise Server. El empuje forzado se debe realizar cuidadosamente para que los colaboradores no sobreescriban un trabajo en el que otros se hayan basado. Para conocer más sobre cuando la opción Cambiar de base y fusionar está desactivada en tu instancia de GitHub Enterprise Server y el flujo de trabajo para volver a activarlo, consulta "Acerca de las fusiones de solicitudes de extracción".
-
When using the Rebase and Merge option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification. When you use this option, GitHub creates a modified commit, using the data and content of the original commit. This means that GitHub didn't truly create this commit, and can't therefore sign it as a generic system user. GitHub doesn't have access to the committer's private signing keys, so it can't sign the commit on the user's behalf.
A workaround for this is to rebase and merge locally, and then push the changes to the pull request's base branch.
Para obtener más información, consulta Configurar el cambio de base de las solicitudes de extracción".