Sobre métodos de merge no GitHub

Você pode configurar as opções de merge de pull request no your GitHub Enterprise Server instance 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 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.

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 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.

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 rerere pode 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 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 . In that way, the rebase and merge behavior resembles a fast-forward merge by maintaining a linear project history. However, rebasing achieves this by re-writing the commit history on the base branch with new commits.

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. For more information about git rebase, see git-rebase in the Git documentation.

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.

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 your GitHub Enterprise Server instance. 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 your GitHub Enterprise Server instance e sobre o fluxo de trabalho para reabilitá-la, consulte "Sobre merges de pull request".

• When using the Rebase and Merge option on a pull request, it's important to note that the commits in the head branch are added to the base branch without commit signature verification. When you use this option, GitHub creates a modified commit, using the data and content of the original commit. This means that GitHub didn't truly create this commit, and can't therefore sign it as a generic system user. GitHub doesn't have access to the committer's private signing keys, so it can't sign the commit on the user's behalf.

  A workaround for this is to rebase and merge locally, and then push the changes to the pull request's base branch.

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