About merge methods on GitHub

You can allow contributors with push access to your repository to merge their pull requests on tu instancia de GitHub Enterprise Server with different merge options or enforce a specific merge method for all of your repository's pull requests.

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". You can enforce one type of merge method, such as commit squashing or rebasing, by only enabling the desired method for your repository.

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.

standard-merge-commit-diagram

The default merge method creates a merge commit. You can prevent anyone from pushing merge commits to a protected branch by enforcing a linear commit history. For more information, see "About protected branches."

Squashing your merge commits

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.

commit-squashing-diagram

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.

Before enabling squashing commits, consider these disadvantages:

  • You lose information about when specific changes were originally made and who authored the squashed commits.
  • If you continue working on the head branch of a pull request after squashing and merging, and then create a new pull request between the same branches, commits that you previously squashed and merged will be listed in the new pull request. You may also have conflicts that you have to repeatedly resolve in each successive pull request. For more information, see "About pull request merges."
  • Some Git commands that use the "SHA" or "hash" ID may be harder to use since the SHA ID for the original commits is lost. For example, using git rerere may not be as effective.

For more information, see "Configuring commit squashing for pull requests."

Rebasing and merging your commits

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.

Before enabling commit rebasing, consider these disadvantages:

  • Repository contributors may have to rebase on the command line, resolve any conflicts, and force push their changes to the pull request's topic branch (or remote head branch) before they can use the rebase and merge option on tu instancia de GitHub Enterprise Server. Force pushing must be done carefully so contributors don't overwrite work that others have based their work on. To learn more about when the Rebase and merge option is disabled on tu instancia de GitHub Enterprise Server and the workflow to re-enable it, see "About pull request merges."

For more information, see "Configuring commit rebasing for pull requests."

¿Te ayudó este documento?

Política de privacidad

¡Ayúdanos a hacer geniales estos documentos!

Todos los documentos de GitHub son de código abierto. ¿Notas algo que esté mal o que no sea claro? Emite una solicitud de cambios.

Haz una contribución

O, aprende cómo contribuir.