Você pode configurar as opções de merge de pull request no sua instância do GitHub Enterprise Server para atender às suas necessidades de fluxo de trabalho e preferências para gerenciar o histórico do Git. Para obter mais informações, consulte "Configurando merges da 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.
Ao clicar na opção-padrão Fazer merge de pull request em um pull request no sua instância do GitHub Enterprise Server, 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.
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, consulte "Sobre branches protegidos."
Combinar por squash os commits de merge
Ao selecionar a opção Combinação por squash e merge em um pull request no sua instância do GitHub Enterprise Server, 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.
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, consulte "Sobre merges da 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, usar
git rererepode não ser tão eficaz.
Para obter mais informações, consulte "Configurar combinação de commits por squash para pull requests".
Fazer rebase e merge de seus commits
Ao selecionar a opção Rebase e merge em um pull request no sua instância do GitHub Enterprise Server, 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 git rebase, consulte a documentação oficial do Git.
Para obter uma representação visual do rebase do git, consulte o capítulo "Branches do Git - Rebase" do livro Pro Git.
Antes de habilitar o rebase de commit, leve em consideração estas desvantagens:
- Os contribuidores do repositório podem ter que fazer rebase na linha de comando, resolver conflitos e forçar push de suas alterações no branch de tópico da pull request (ou branch de head remoto) para que possam usar a opção rebase and merge (fazer rebase e merge) no sua instância do GitHub Enterprise Server. 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 Rebase and merge (Fazer rebase e merge) é desabilitada no sua instância do GitHub Enterprise Server e sobre o fluxo de trabalho para reabilitá-la, consulte "Sobre merges de pull request".
Para obter mais informações, consulte "Configurar rebase de commit para pull requests".