git pullprovavelmente está criando o commit. Se você fizer uma confirmação local e depois executar git pulldepois que outra pessoa enviar uma confirmação para o repositório, o Git fará o download da confirmação do outro desenvolvedor e a mesclará na sua filial local.
Como evitar esses commits de mesclagem no futuro
Você pode usar git pull --rebasepara impedir que isso aconteça no futuro, mas o rebaseamento tem seus perigos, e eu recomendo evitar pullcompletamente .
Em vez disso, recomendamos que você siga este padrão de uso:
# download the latest commits
git remote update -p
# update the local branch
git merge --ff-only @{u}
# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}
Explicação
git remote update -pbaixa todas as confirmações nos repositórios remotos e atualiza as ramificações de rastreamento remoto (por exemplo, origin/master). NÃO toca no diretório de trabalho, índice ou ramificações locais.
As -pameixas do argumento excluíram ramos upstream. Assim, se o fooramo for excluído no originrepositório, git remote update -pele excluirá automaticamente sua origin/fooreferência.
git merge --ff-only @{u}diz ao Git para mesclar a ramificação upstream (o @{u}argumento) em sua ramificação local, mas somente se sua ramificação local puder ser "encaminhada rapidamente" para a ramificação upstream (em outras palavras, se não tiver divergido).
git rebase -p @{u}move efetivamente os commits que você fez, mas ainda não colocou no topo da ramificação upstream, o que elimina a necessidade de criar os commits parvos de mesclagem que você está tentando evitar. Isso melhora a linearidade do histórico de desenvolvimento, facilitando a revisão.
A -popção diz ao Git para preservar mesclagens. Isso evita que o Git linearize os commits sendo rebased. Isso é importante se, por exemplo, você mesclou uma ramificação de recurso master. Sem -p, todo commit no ramo do recurso seria duplicado mastercomo parte da linearização feita por git rebase. Isso dificultaria a revisão do histórico de desenvolvimento, não mais fácil.
Cuidado : git rebasepode não fazer o que você espera, então revise os resultados antes de pressionar. Por exemplo:
git log --graph --oneline --decorate --date-order --color --boundary @{u}..
Prefiro essa abordagem git pull --rebasepelos seguintes motivos:
- Ele permite que você veja os commits upstream recebidos antes de modificar seu histórico para incorporá-los.
- Ele permite que você passe a opção
-p( --preserve-merges) para o git rebasecaso de precisar refazer uma mesclagem intencional (por exemplo, mesclagem de uma ramificação de recurso já enviada para master).
Taquigrafia: em git upvez degit pull
Para facilitar o procedimento acima, recomendo criar um alias chamado up:
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
Agora, tudo o que você precisa fazer para atualizar sua filial é executar:
git up
em vez de git pull. Se você receber um erro porque sua filial local divergiu da filial upstream, essa é sua sugestão para refazer a ação.
Por que não git pull --rebase?
Corrida git pull --rebaseé equivalente a corrida git fetchseguida por git rebase. Isso tenta avançar rapidamente para as novas confirmações upstream, mas se isso não for possível, ele rebase suas confirmações locais para as novas confirmações upstream. Isso geralmente é bom, mas tenha cuidado:
- Rebase é um tópico avançado e você deve entender as implicações antes de rebasear.
git pull --rebasenão lhe dá a oportunidade de examinar os commits antes de incorporá-los. Dependendo do que a montante mudou, é bem possível que rebase é a operação de um erro rebase --onto, merge, resetou push -fpode ser mais apropriado do que uma planície rebase.- Não é (atualmente) possível passar
--preserve-mergespara a operação de rebase, portanto, qualquer mesclagem intencional de uma ramificação de recurso será linearizada, reproduzindo (e, portanto, duplicando) todas as confirmações de ramificação de característica.
"Corrigindo" uma consolidação de mesclagem existente criada por git pull
Se você ainda não enviou uma confirmação de mesclagem criada por git pull, é possível recuperar novamente a confirmação de mesclagem. Supondo que você não tenha feito nenhuma fusão intencional (por exemplo, mesclando uma ramificação de recurso já enviada à sua ramificação atual), faça o seguinte:
git rebase @{u}
O comando acima informa ao Git para selecionar todos os commits de não mesclagem alcançáveis HEAD(o commit atual), menos todos os commits alcançáveis @{u}(que é uma abreviação de "o ramo upstream", isto é, origin/masterse HEADhouver master), reproduzir novamente (cherry-pick ) na parte superior da ramificação upstream e, em seguida, mova a referência da ramificação atual para apontar para o resultado da reprodução das confirmações. Isso efetivamente move as confirmações de não mesclagem para a confirmação upstream mais recente, o que elimina a mesclagem criada por git pull.
Se você tem uma consolidação intencional de mesclagem, não deseja executar, git rebase @{u}porque ela reproduzirá tudo da outra ramificação. Lidar com esse caso é substancialmente mais complicado, e é por isso que é bom usar git upe evitar git pullcompletamente. Você provavelmente precisará usar resetpara desfazer a mesclagem criada por pulle depois fazer git rebase -p @{u}. O -pargumento git rebasenão funcionou de maneira confiável para mim; portanto, você pode acabar tendo que resetdesfazer a mesclagem intencional, atualizar sua ramificação local @{u}e depois refazer a mesclagem intencional (que é uma dor se houver muitas mesclagens peludas conflitos).