Sobre métodos de merge no GitHub

You can configure pull request merge options on sua instância do GitHub Enterprise Server to meet your workflow needs and preferences for managing Git history. For more information, see "Configuring pull request merges." É possível aplicar um tipo de método de merge, como combinação por squash ou rebase de commit, apena habilitando o método desejado para o repositório.

When you click the default Merge pull request option on a pull request on sua instância do GitHub Enterprise Server, all commits from the feature branch are added to the base branch in a merge commit. The pull request is merged using the --no-ff option.

To merge pull requests, you must have write permissions in the repository.

Combinar por squash os commits de merge

When you select the Squash and merge option on a pull request on sua instância do GitHub Enterprise Server, the pull request's commits are squashed into a single commit. Instead of seeing all of a contributor's individual commits from a topic branch, the commits are combined into one commit and merged into the default branch. Pull requests with squashed commits are merged using the fast-forward option.

To squash and merge pull requests, you must have write permissions in the repository, and the repository must allow squash merging.

You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history.

Antes de habilitar a combinação de commits por squash, considere estas desvantagens:

• Você perde informações sobre quando alterações específicas foram originalmente feitas e quem criou os commits combinados por squash.
• Alguns comandos Git que usam a ID "SHA" ou "hash" podem ser mais difíceis de usar, pois a ID SHA para os commits originais é perdida. Por exemplo, usar git rerere pode não ser tão eficaz.

Para obter mais informações, consulte "Configurar combinação de commits por squash para pull requests".

Fazer rebase e merge de seus commits

When you select the Rebase and merge option on a pull request on sua instância do GitHub Enterprise Server, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. Pull requests with rebased commits are merged using the fast-forward option.

To rebase and merge pull requests, you must have write permissions in the repository, and the repository must allow rebase merging.

The rebase and merge behavior on GitHub Enterprise deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit. For more information about git rebase, see the "Git rebase" chapter from the Pro Git book.

For a visual representation of git rebase, see The "Git Branching - Rebasing" chapter from the Pro Git book.

Antes de habilitar o rebase de commit, leve em consideração estas desvantagens:

• Os contribuidores do repositório podem ter que fazer rebase na linha de comando, resolver conflitos e forçar push de suas alterações no branch de tópico da pull request (ou branch de head remoto) para que possam usar a opção rebase and merge (fazer rebase e merge) no sua instância do GitHub Enterprise Server. O push forçado deve ser feito com cuidado para que os contribuidores não substituam o trabalho que outras pessoas usaram como base para o respectivo trabalho. Para saber mais sobre quando a opção Rebase and merge (Fazer rebase e merge) é desabilitada no sua instância do GitHub Enterprise Server e sobre o fluxo de trabalho para reabilitá-la, consulte "Sobre merges de pull request".

Para obter mais informações, consulte "Configurar rebase de commit para pull requests".