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.
Squash and merge your pull request 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.
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.
Merge message for a squash merge
When you squash and merge, GitHub generates a default commit message, which you can edit. The default message depends on the number of commits in the pull request, not including merge commits.
| Number of commits | Summary | Description |
|---|---|---|
| One commit | The title of the commit message for the single commit, followed by the pull request number | The body text of the commit message for the single commit |
| More than one commit | The pull request title, followed by the pull request number | A list of the commit messages for all of the squashed commits, in date order |
Squashing and merging a long-running branch
If you plan to continue work on the head branch of a pull request after the pull request is merged, we recommend you don't squash and merge the pull request.
When you create a pull request, GitHub identifies the most recent commit that is on both the head branch and the base branch: the common ancestor commit. When you squash and merge the pull request, GitHub creates a commit on the base branch that contains all of the changes you made on the head branch since the common ancestor commit.
Because this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request. If there are no conflicts, you can safely merge these commits. However, this workflow makes merge conflicts more likely. If you continue to squash and merge pull requests for a long-running head branch, you will have to resolve the same conflicts repeatedly.
Rebase and merge your pull request 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.
You aren't able to automatically rebase and merge on tu instancia de GitHub Enterprise Server when:
- The pull request has merge conflicts.
- Rebasing the commits from the base branch into the head branch runs into conflicts.
- Rebasing the commits is considered "unsafe," such as when a rebase is possible without merge conflicts but would produce a different result than a merge would.
If you still want to rebase the commits but can't rebase and merge automatically on tu instancia de GitHub Enterprise Server you must:
- Rebase the topic branch (or head branch) onto the base branch locally on the command line
- Resolve any merge conflicts on the command line.
- Force-push the rebased commits to the pull request's topic branch (or remote head branch).
Anyone with write permissions in the repository, can then merge the changes using the rebase and merge button on tu instancia de GitHub Enterprise Server.