Estou tentando revisar uma solicitação de recebimento no GitHub para um ramo que não é mestre. O ramo de destino estava por trás do mestre e a solicitação de recebimento mostrava confirmações do mestre, então eu mesclei o mestre e o enviei ao GitHub, mas as confirmações e diferenças para eles ainda aparecem na solicitação de recebimento após a atualização. Eu dupliquei se o ramo no GitHub tem os commits do master. Por que eles ainda estão aparecendo na solicitação de recebimento?

Também verifiquei a solicitação pull localmente e ela mostra apenas os commits não mesclados.

Parece que a solicitação de recebimento não acompanha as alterações na ramificação de destino (entrei em contato com o suporte do GitHub e recebi uma resposta em 18 de novembro de 2014 informando que isso é por design).

No entanto, você pode mostrar as alterações atualizadas, fazendo o seguinte:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Substituir githuburl, org, repo, targetbranch, e currentbranch, conforme necessário.

Ou como o hexsprite apontou em sua resposta, você também pode forçá-lo a atualizar clicando Editno PR e alterando temporariamente a base para um ramo diferente e vice-versa. Isso produz o aviso:

Tem certeza de que deseja alterar a base?

Algumas confirmações da ramificação base antiga podem ser removidas da linha do tempo e os comentários antigos da revisão podem ficar desatualizados.

E deixará duas entradas de log no PR:

Aqui está uma boa solução alternativa. Use o Editbotão ao visualizar o PR no GitHub para alterar a ramificação base para algo diferente de master. Em seguida, mude novamente para mastere agora ele mostrará corretamente apenas as alterações das confirmações mais recentes.

Para resumir, o GitHub não rebase o histórico de confirmação automaticamente em solicitações pull. As soluções mais simples são:

Solução 1: Rebase

Suponha que você deseja mesclar a masterpartir de feature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force

Se você estiver trabalhando em um garfo, pode ser necessário substituí-lo originacima upstream. Consulte Como atualizo um repositório bifurcado do GitHub?para saber mais sobre como rastrear ramificações remotas do repositório original.

Solução 2: Crie uma nova solicitação de recebimento

Suponha que você queira mesclar a introdução masterde feature-01:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

Agora abra uma solicitação pull feature-01-rebasede feche a solicitação feature-01.

Você precisa adicionar o seguinte ao seu ~/.gitconfigarquivo:

[rebase]
    autosquash = true

Isso alcançará automaticamente o mesmo que o mostrado nesta resposta .

Eu peguei isso daqui .

Para qualquer outra pessoa que se depare com isso e confunda com o comportamento de solicitação de solicitação do GitHub, a causa principal é que um PR é uma diferença da dica do ramo de origem em relação ao ancestral comum do ramo de origem e do ramo de destino. Portanto, ele mostrará todas as alterações no ramo de origem até o ancestral comum e não levará em consideração as alterações que possam ter ocorrido no ramo de destino.

Mais informações disponíveis aqui: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

As diferenças comuns baseadas em ancestrais parecem perigosas. Eu gostaria que o GitHub tivesse a opção de criar um PR de 3 vias mais padrão, baseado em mesclagem.

Uma maneira de corrigir isso é git rebase targetbranchnesse PR. Então git push --force targetbranch, o Github mostrará os commit e diff certos. Tenha cuidado com isso se você não souber o que está fazendo. Talvez faça o checkout de um ramo de teste primeiro para fazer a rebase e depois git diff targetbranchpara garantir que ainda seja o que você deseja.

Isso acontece com o GitHub quando você confirma o squash mesclado no ramo de destino.

Eu estava usando squash e mesclagem com o Github como estratégia de mesclagem padrão, incluindo mesclagens do ramo de destino. Isso introduz um novo commit e o GitHub não reconhece que esse commit compactado é o mesmo que já existe no master (mas com hashes diferentes). O Git lida com isso corretamente, mas você vê todas as alterações novamente no GitHub, tornando a revisão irritante. A solução é fazer uma mesclagem regular desses commits a montante, em vez de uma squash e mesclagem. Quando você deseja mesclar outro ramo ao seu como uma dependência, git merge --squashe reverta esse único commit antes de sair do master, uma vez que o outro branch realmente tenha conseguido dominar.

EDIT: outra solução é rebase e forçar push. História limpa, mas reescrita

Não tenho muita certeza da teoria por trás disso. Mas eu consegui isso várias vezes e consegui corrigir isso fazendo o seguinte.

git pull --rebase

Isso buscará e mesclará as alterações do ramo principal de repositórios original (se você apontou para isso)

Em seguida, você envia suas alterações com força para o repositório clonado do github (destino)

git push -f origin master

Isso garantirá que o clone do github e o repositório principal estejam no mesmo nível de confirmação do github e que você não veja alterações desnecessárias nas ramificações.

Experimente os comandos abaixo, um por um.

git pull "latest

git reset --hard master

Abordagem à prova de falhas, se você estiver preocupado demais com a bagunça: vá para o arquivo e remova manualmente as alterações, depois faça uma squash com sua última confirmação usando

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

Eu não há conflitos, você está pronto para ir!