Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Sobre merges de pull request

Você pode fazer merge de pull requests retendo todos os commits em um branch de recurso, combinando por squash todos os commits em um único commit ou fazendo rebase de commits individuais do branch 'head' no branch 'base'.

Neste artigo

Ao clicar na opção-padrão Fazer merge de pull request em um pull request no your GitHub Enterprise Server instance, todos os commits do branch de recurso serão adicionados ao branch de base em um commit de merge. O pull request é mesclado utilizando a opção --no-ff.

Para fazer merge de pull requests, você precisa ter permissões de gravação no repositório.

standard-merge-commit-diagram

Combinar por squash e fazer merge de commits da pull request

Ao selecionar a opção Combinação por squash e merge em um pull request no your GitHub Enterprise Server instance, os commits do pull request são combinados em um único 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. Os pull requests com commits combinados são mesclados usando a opção fast-forward.

Para realizar a combinação por squash e mesclar pull requests, você deve ter permissões de gravação no repositório e o repositório deve permitir o merge por combinação por squash.

commit-squashing-diagram

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 merge, o GitHub gera uma mensagem de commit que você pode mudar se quiser. O padrão da mensagem depende se a pull request contém vários commits ou apenas um.

Número de commitsSumárioDescriçã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

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

Se você planeja continuar trabalhando no branch head de uma pull request depois que a pull request for mesclada, recomendamos que você não combine por squash nem faça o merge da pull request.

Quando você cria uma pull request, o GitHub identifica o commit mais recente que existe tanto no branch head quanto no branch base: o commit de 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.

Fazer rebase e merge dos commits da sua pull request

Ao selecionar a opção Rebase e merge em um pull request no your GitHub Enterprise Server instance, todos os commits do branch de tópico (ou branch de cabeçalho) serão adicionados ao branch base individualmente sem um commit do merge . Pull requests com commits de rebase em commits são mesclados usando a opção de fast-forward.

Para fazer rebase e merge de pull requests, você deve ter permissões de gravação no repositório, e o repositório deve permitir o merge de rebase.

O comportamento de rebase e merge em GitHub Enterprise Server é ligeiramente diferente do rebase do git. O rebase e o merge em GitHub sempre atualizará as informações do autor do commit e criará novos SHAs, enquanto rebase do git fora do GitHub não altera a informação do committer quando a rebase acontece em cima de um commit de ancestral. Para obter mais informações sobre rebase do git, consulte o capítulo "Rebase do Git" no livro Pro Git.

Para obter uma representação visual do rebase do git, consulte o capítulo "Branches do Git - Rebase" do livro Pro Git.

Você não pode fazer rebase e merge automaticamente no your GitHub Enterprise Server instance 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 ainda quiser fazer rebase dos commits, mas não puder fazer rebase e merge automaticamente no your GitHub Enterprise Server instance, você deverá:

Qualquer pessoa com permissões de gravação no repositório pode fazer merge das alterações usando o botão de rebase e merge no your GitHub Enterprise Server instance.

Leia mais

Esse documento ajudou você?

Privacy policy

Ajude-nos a tornar esses documentos ótimos!

Todos os documentos do GitHub são de código aberto. Você percebeu que algo que está errado ou não está claro? Envie um pull request.

Faça uma contribuição

Ou, aprenda como contribuir.