As solicitações de pull podem ser mescladas de maneiras diferentes. A melhor estratégia depende de como sua equipe quer que o histórico do repositório fique e de quanto detalhe você deseja preservar do branch da solicitação de pull.
| Strategy | Result | Escolher quando |
|---|---|---|
| Confirmação de mesclagem | Preserva cada confirmação do branch de solicitação de pull e adiciona um ponto de mesclagem explícito. | Sua equipe valoriza o histórico completo, ou os commits individuais fazem sentido por si só. |
| Squash e mesclagem | Combina todas as confirmações na solicitação de pull em uma única confirmação no branch base. | Um pull request representa uma única alteração lógica, especialmente quando há muitos commits pequenos de correção. |
| Rebasear e mesclar | Adiciona cada commit ao ramo base sem um commit de merge, criando um histórico linear. | Sua equipe quer um histórico linear e os commits já estão organizados com clareza. |
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.
Uma confirmação de mesclagem preserva o histórico de confirmação completo do branch de solicitação de pull. Isso facilita a visualização de cada commit que levou à alteração final, incluindo correções feitas na revisão e trabalho intermediário. 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ó.
Agrupe e mescle seus 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.
Fazer squash transforma todos os commits do pull request em um único commit no branch base. Isso mantém o histórico de branch padrão conciso e pode facilitar a verificação posterior. A desvantagem é que os commits intermediários do pull request não são preservados como commits separados na branch base.
Escolha essa estratégia quando uma solicitação de pull representar uma alteração lógica, especialmente se o branch incluir muitas confirmações de correção pequenas.
Mesclar mensagem para uma mesclagem por squash
Quando você faz squash e mescla, 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.
Mantenedores e administradores podem configurar a mensagem padrão para commits esmagados. 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 mesclagem de squash funciona melhor para ramificações de curta duração. Se você continuar trabalhando no mesmo branch de origem após um merge squash, pull requests futuras poderão incluir commits que já foram condensados no branch 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 branches de longa duração, considere usar um commit de merge ou fazer rebase da branch antes de abrir o próximo pull request.
Troca de base e mesclagem de commits
Quando você seleciona a opção Troca de base e mesclagem em uma solicitação de pull, todos os commits da ramificação do tópico (ou da ramificação principal) são adicionados à ramificação base individualmente, sem um commit de mesclagem. Dessa forma, o comportamento de rebase e mesclagem se assemelha a uma mesclagem fast-forward, mantendo um histórico linear do projeto. No entanto, o rebase faz isso reescrevendo o histórico de commits no ramo base por meio de novos commits.
O comportamento de rebase e mesclagem em GitHub desvia ligeiramente de git rebase fora de GitHub. Basear novamente e mesclar em GitHub:
- Sempre atualiza as informações do responsável pelo commit e cria novos SHAs de commit, enquanto
git rebasenão altera as informações do responsável pelo commit quando o rebase é feito sobre um commit 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.
A rebasing adiciona cada confirmação do branch de solicitação de pull ao branch base sem criar uma confirmação de mesclagem. Isso produz um histórico linear, preservando os commits individuais do pull request.
Escolha essa estratégia quando sua equipe quiser um histórico linear e os commits do pull request já estiverem claramente organizados. Se GitHub não conseguir fazer o rebase automático da pull request com segurança, você pode fazer o rebase localmente, resolver os conflitos e enviar a branch atualizada. Confira Resolving a merge conflict using the command line e Merging a pull request.
Fusões indiretas
Uma pull request pode ser marcada como mesclada se os commits da sua branch de origem ficarem acessíveis a partir da branch 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. As solicitações de pull mescladas indiretamente são marcadas como merged mesmo se as regras de proteção de branch nessa solicitação de pull não fossem atendidas.