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 e fazer merge de commits da pull request
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.
Mesclar mensagem para uma mesclagem por squash
Quando você faz combinação por squash e merge, o GitHub gera uma mensagem de commit que você pode mudar se quiser. O padrão da mensagem depende se a pull request contém vários commits ou apenas um.
| Número de commits | Sumário | Descrição |
|---|---|---|
| Um commit | O título da mensagem de commit do único commit, seguido do número de pull request | O texto da mensagem de commit para o único commit |
| Mais de um commit | Título da pull request, seguido do número da pull request | Uma lista das mensagens de commit para todos os commits combinados por squash, por ordem de data |
Fazendo combinação por squash e merge com um branch de longa duração
Se você planeja continuar trabalhando no branch head de uma pull request depois que a pull request for mesclada, recomendamos que você não combine por squash nem faça o merge da pull request.
Quando você cria uma pull request, o GitHub identifica o commit mais recente que existe tanto no branch head quanto no branch base: o commit de ancestral comum. Quando você combinar por squash e mesclar a pull request, o GitHub cria um commit no branch base que contém todas as alterações feitas no branch head desde o commit de ancestral comum.
Uma vez que esse commit está apenas no branch base e não no branch head, o ancestral comum dos dois branches permanece inalterado. Se você continuar a trabalhar no branch head e, em seguida, criar uma nova pull request entre os dois branches, a pull request incluirá todos os commits desde o ancestral comum, incluindo commits que você combinou por squash e fez merge na pull request anterior. Se não houver conflitos, você pode mesclar esses commits com segurança. No entanto, este fluxo de trabalho torna os conflitos de mesclagem mais prováveis. Se você continuar a combinar por squash e mesclar pull requests para um branch head de longo prazo, você terá que resolver os mesmos conflitos repetidamente.
Fazer rebase e merge dos commits da sua pull request
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.
Você não pode fazer rebase e merge automaticamente no sua instância do GitHub Enterprise Server quando:
- A pull request tem conflitos de merge.
- O rebase dos commits do branch base no branch head se depara com conflitos.
- O rebase dos commits é considerado "não seguro"; por exemplo, quando é possível fazer rebase sem conflitos de merge, mas que geraria um resultado diferente daquele que um merge geraria.
Se ainda quiser fazer rebase dos commits, mas não puder fazer rebase e merge automaticamente no sua instância do GitHub Enterprise Server, você deverá:
- Fazer rebase do branch de tópico (ou branch head) no branch base localmente na linha de comando
- Resolver qualquer conflito de merge na linha de comando.
- Forçar push dos commits com rebase no branch de tópico da pull request (ou branch head remoto).
Qualquer pessoa com permissões de gravação no repositório pode fazer merge das alterações usando o botão de rebase e merge no sua instância do GitHub Enterprise Server.