Skip to main content

Sobre métodos de merge no GitHub

Você pode permitir que os contribuidores com acesso de push no seu repositório mesclem as respectivas solicitações de pull no GitHub.com com diferentes opções de mesclagem ou apliquem um método de mesclagem específico a todas as solicitações de pull do repositório.

É possível configurar opções de mesclagem de solicitações de pull no GitHub.com a fim de atender às suas necessidades e preferências de fluxo de trabalho com relação ao gerenciamento do histórico do Git. Para obter mais informações, confira "Configurar merges de pull request". É 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.

Observação: ao usar a fila de mesclagem, você não pode mais escolher o método de mesclagem, pois isso é controlado pela fila. Para obter mais informações sobre filas de mesclagem, confira "Como gerenciar uma fila de mesclagem".

Quando você clica na opção padrão Mesclar solicitação de pull em uma solicitação de pull no GitHub.com, todos os commits do branch de recursos são adicionados ao branch 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.

O método de merge padrão cria um commit de mesclagem. Você pode impedir que uma pessoa faça pushing com commits por merge em um branch protegido aplicando um histórico de commit linear. Para obter mais informações, confira "Sobre branches protegidos".

Combinar por squash os commits de merge

Quando você seleciona a opção Mesclar por squash e mesclar em uma solicitação de pull no GitHub.com, os commits da solicitação de pull são mesclados 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.

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.
  • Se você continuar trabalhando no branch principal de um pull request após a combinação por squash e o merge, e, em seguida, criar um novo pull request entre os mesmos branches, commits que você já tenha combinado por squash e feito merge serão listados no novo pull request. Você também pode ter conflitos que tenha que resolver repetidamente em cada pull request consecutivo. Para obter mais informações, confira "Sobre merges de pull request".
  • 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, o uso de git rerere pode não ser tão eficaz.

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

Fazer rebase e merge de seus commits

Quando você seleciona a opção Troca de base e mesclagem em uma solicitação de pull no GitHub.com, todos os commits do branch do tópico (ou do branch principal) são adicionados ao branch 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 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.

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

  • Os colaboradores do repositório podem precisar trocar a base na linha de comando, resolver os conflitos e forçar as alterações por push para o branch do tópico da solicitação de pull (ou para o branch principal remoto) a fim de usar a opção Troca de base e mesclagem do GitHub.com. 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 Troca de base e mesclagem é desabilitada no GitHub.com e o fluxo de trabalho necessário para habilitá-la novamente, confira "Sobre merges de pull request".

  • Ao usar a opção Trocar base e Mesclar em uma solicitação de pull, é importante observar que os commits no branch principal são adicionados ao branch base sem verificação de assinatura de commit. Quando você usa essa opção, o GitHub cria um commit modificado usando os dados e o conteúdo do commit original. Isso significa que o GitHub não criou de fato esse commit e, portanto, não pode assiná-lo como um usuário genérico do sistema. O GitHub não tem acesso às chaves de assinatura privadas do responsável pelo commit, portanto, não pode assinar o commit em nome do usuário.

    Uma solução alternativa é trocar a base e fazer a mesclagem localmente e depois enviar as alterações por push ao branch base da solicitação de pull.

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