Sobre métodos de merge no GitHub

É possível configurar as opções de mesclagem de solicitações de pull para atender às suas necessidades e preferências de fluxo de trabalho para o 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.

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.

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 saber mais, confira Sobre branches protegidos.

Combinar por squash os commits de merge

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ê 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 saber mais, 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 saber mais, 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, 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.

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

• Os colaboradores do repositório podem precisar trocar a base novamente na linha de comando, resolver os conflitos e forçar por push as alterações para a ramificação do tópico da pull request (ou para a ramificação principal remota) para usar a opção Troca de base e mesclagem do GitHub. 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 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 saber mais, confira Configurar rebase do commit para pull requests.