As solicitações de pull podem ser mescladas de maneiras diferentes. A melhor estratégia depende de como sua equipe deseja que o histórico do repositório seja visualizado e de quantos detalhes você deseja preservar da ramificação do pull request.
| Strategy | Result | Escolher quando |
|---|---|---|
| Confirmação de mesclagem | Preserva todos os commits da ramificação do pull request e adiciona um ponto de merge explícito. | Sua equipe valoriza um histórico completo ou os commits individuais são significativos por si só. |
| Squash e merge | Combina todos os commits do pull request em um único commit na ramificação base. | Um pull request representa uma única alteração lógica, especialmente com muitos commits de correção pequenos. |
| Rebase e merge | Adiciona cada commit à ramificação base sem um commit de merge, para um histórico linear. | Sua equipe deseja um histórico linear e os commits já estão organizados de forma clara. |
Mesclar seus commits
Quando você clica na opção padrão Mesclar solicitação de pull em uma solicitação de pull, todos os commits da ramificação de recursos são adicionados à ramificação base em um commit de mesclagem. A solicitação de pull é mesclada por meio da opção --no-ff.
Para mesclar as solicitações de pull, você precisa ter permissões de gravação no repositório.
Um commit de merge preserva todo o histórico de commits da ramificação do pull request. Isso facilita a visualização de cada commit que levou à alteração final, incluindo correções de revisão e trabalhos intermediários. Ele também cria um ponto de mesclagem explícito no histórico do branch base.
Escolha esta estratégia quando sua equipe valoriza o histórico completo ou quando os commits individuais em um pull request são significativos por si só.
Combinação por squash e mesclagem de commits
Quando você seleciona a opção Combinar por squash e mesclar em uma solicitação de pull, os commits da solicitação de pull são combinados por squash em um só commit. Em vez de ver todos os commits individuais de um contribuidor de um branch de tópico, os commits são combinados em um commit e mesclados no branch-padrão. As solicitações de pull com commits mesclados por squash são mescladas com a opção de avanço rápido.
Para mesclar por squash e mesclar solicitações de pull, você precisa ter permissões de gravação no repositório, e o repositório precisa permitir a mesclagem squash.
Você pode usar combinação por squash e merge para criar um histórico de Git mais simplificado no seu repositório. Os commits de trabalho em andamento são úteis ao trabalhar em um branch de recurso, mas não são necessariamente importantes para manter no histórico do Git. Se você combinar esses commits por squash em um só commit ao mesclá-los com o branch padrão, as alterações serão consolidadas, resultando em um histórico limpo do Git.
O squash transforma todos os commits do pull request em um único commit na ramificação base. Isso mantém o histórico da ramificação padrão conciso e pode facilitar a análise posterior. A desvantagem é que os commits intermediários do pull request não são preservados como commits separados na ramificação base.
Escolha esta estratégia quando um pull request representa uma única alteração lógica, especialmente se a ramificação incluir muitos commits de correção pequenos.
Mesclar mensagem para uma mesclagem por squash
Ao usar squash e merge, GitHub gera uma mensagem de commit padrão que você pode editar. A mensagem padrão pode incluir o título da solicitação pull, a descrição da solicitação de pull ou as informações de confirmação, dependendo das configurações do repositório e do número de confirmações na solicitação de pull.
Os mantenedores e administradores podem configurar a mensagem padrão para commits consolidados. Consulte Configurar a combinação de confirmações por squash em solicitações de pull.
Fazendo combinação por squash e merge com um branch de longa duração
A consolidação funciona melhor para ramificações de curta duração. Se você continuar trabalhando na mesma ramificação principal após uma consolidação, as pull requests subsequentes poderão incluir commits que já foram consolidados na ramificação base. Isso pode tornar os conflitos de mesclagem mais prováveis e pode forçar você a resolver os mesmos conflitos mais de uma vez.
Para ramificações de longa duração, considere usar um commit de merge ou fazer um rebase da ramificação antes de abrir a próxima pull request.
Troca de base e mesclagem de commits
Quando você seleciona a opção Troca de base e mesclagem em uma pull request, todos os commits da ramificação de tópico (ou da ramificação principal) são adicionados à ramificação base individualmente, sem um commit de mesclagem. Dessa forma, o comportamento de troca de base e mesclagem se assemelha a uma mesclagem de avanço rápida mantendo um histórico de projeto linear. No entanto, a troca de base faz isso reescrevendo o histórico de commit no branch base com novos commits.
O comportamento de troca de base e mesclagem em GitHub se desvia ligeiramente de git rebase fora de GitHub. Troca de base e mesclagem em GitHub:
- Sempre atualiza as informações de committer e cria novos SHAs de commit, e
git rebasenão altera as informações de committer quando acontece a troca de base após o commit de um elemento ancestral. - Descarta confirmações que estavam vazias para começar, como aquelas criadas com
git commit --allow-empty, enquantogit rebasemantém confirmações originalmente vazias por padrão.
Para obter mais informações sobre git rebase, confira git-rebase na documentação do Git.
Para troca de base e mesclagem das solicitações de pull, você precisa ter permissões de gravação no repositório e o repositório precisa permitir a troca de base e a mesclagem.
Para ver uma representação visual de git rebase, confira o capítulo "Ramificação do Git – Troca de base " do livro Pro Git.
O rebase adiciona cada commit da ramificação da pull request à ramificação base sem criar um commit de merge. Isso produz um histórico linear, preservando os commits individuais da pull request.
Escolha esta estratégia quando sua equipe desejar um histórico linear e os commits da pull request já estiverem organizados de forma clara. Se GitHub não puder fazer o rebase da pull request automaticamente com segurança, você pode fazer o rebase localmente, resolver conflitos e enviar a ramificação atualizada. Confira Resolving a merge conflict using the command line e Mesclar uma solicitação de pull.
Fusões indiretas
Uma pull request pode ser marcada como mesclada se os commits de seu ramificação principal se tornarem alcançáveis a partir da ramificação base fora dessa pull request. Isso pode acontecer quando as mesmas confirmações são mescladas por meio de outra solicitação de pull ou enviadas diretamente para o branch padrão.
Mesclagens indiretas são incomuns, mas podem afetar as expectativas de automação e proteção de ramificação. Solicitações de pull mescladas indiretamente são marcadas como merged mesmo que as regras de proteção de ramificação nessa pull request não tenham sido satisfeitas.