Skip to main content

Enterprise Server 3.15 está disponível no momento como versão release candidate.

Sobre merges de pull request

Você pode mesclar solicitações de pull mantendo todos os commits em um branch de recurso, combinando todos os commits em um único commit ou realocando commits individuais do branch head no branch base.

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.

Diagrama de um fluxo de mesclagem e commit padrão, em que os commits de um branch de recurso e um commit de mesclagem adicional são adicionados a main.

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.

Diagrama do squash de commit, em que vários commits de um branch de recurso são combinados em um só commit adicionado a main.

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ê fizer a combinação por squash desses commits em um commit enquanto faz merge com o branch-padrão, você certamente poderá manter as alterações originais com um histórico Git.

Mesclar mensagem para uma mesclagem por squash

Quando você faz combinação por squash e mesclagem, o GitHub gera uma mensagem de commit padrão, que você pode editar. Dependendo de como o repositório está configurado e do número de commits na solicitação de pull, não incluindo commits de mesclagem, essa mensagem pode incluir o título ou a descrição da solicitação de pull ou informações sobre os commits.

Número de commitsResumoDescrição
Um commitO título da mensagem de commit do único commit, seguido do número de pull requestO texto da mensagem de commit para o único commit
Mais de um commitTítulo da pull request, seguido do número da pull requestUma lista das mensagens de commit para todos os commits combinados por squash, por ordem de data

Pessoas com acesso de mantenedor ou administrador a um repositório podem configurar a mensagem de mesclagem padrão de seu repositório para todos os commits com combinação por squash de modo a usar o título da solicitação de pull, o título do solicitação de pull e os detalhes do commit, ou o título e a descrição da solicitação de pull. Para obter mais informações, confira "Configurar a combinação de commits por squash em pull requests".

Fazendo combinação por squash e merge com um branch de longa duração

Se você pretende continuar o trabalho no branch principal de uma solicitação de pull depois que a solicitação de pull for mesclada, recomendamos que você não use a mesclagem squash nem mescle a solicitação de pull.

Quando você cria uma solicitação de pull, o GitHub identifica o commit mais recente que está no branch principal e no branch base: o commit 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.

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 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 no GitHub Enterprise Server se desvia ligeiramente de git rebase. A troca de base e a mesclagem no GitHub sempre atualizará as informações do autor de commit e criará novos SHAs de commit, enquanto o git rebase fora do GitHub não altera as informações do autor de commit quando a troca de base acontece com base em um commit ancestral. 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.

Você não pode trocar a base e mesclar automaticamente 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 você ainda quiser trocar a base dos commits, mas não puder fazer isso e mesclar automaticamente, você deverá:

Qualquer pessoa com permissões de gravação no repositório pode mesclar as alterações usando o botão Trocar base e mesclar.

Mesclagens indiretas

Uma solicitação de pull pode ser mesclada automaticamente quando o branch principal dela é mesclado direta ou indiretamente com o branch base de maneira externa. Em outras palavras, se o commit da dica do branch principal se tornar acessível por meio da dica do branch de destino. Por exemplo:

  • O branch main está no commit C.
  • O branch feature foi ramificado de main e está atualmente no commit D. Ele tem uma solicitação de pull direcionada a main.
  • O branch feature_2 foi derivado de feature e está atualmente no commit E. Ele também tem uma solicitação de pull direcionada a main.

Se a solicitação de pull E --> main for mesclada primeiro, a solicitação de pull D --> main será marcada como mesclada automaticamente porque todos os commits de feature agora poderão ser acessados por meio de main. Mesclar feature_2 em main e enviar main por push para o servidor por meio da linha de comando marcará ambas as solicitações de pull como mescladas.

As mesclagens indiretas só podem ocorrer quando os commits no branch head da solicitação de pull são enviados diretamente para o branch padrão do repositório ou quando os commits no branch head da solicitação de pull estão presentes em outra solicitação de pull e foram mesclados no branch padrão do repositório usando a opção Criar uma confirmação de mesclagem.

Se uma solicitação de pull que contém commits presentes no branch head de outra solicitação de pull for mesclada usando as opções Squash e mesclar ou Trocar base e mesclar, uma nova confirmação será criada no branch base e a outra solicitação de pull não será mesclada automaticamente.

As solicitações de pull mescladas indiretamente são marcadas como merged mesmo se as regras de proteção de branch não forem atendidas.

Leitura adicional