Demande d'extraction GitHub montrant les commits qui sont déjà dans la branche cible


136

J'essaye de passer en revue une pull request sur GitHub vers une branche qui n'est pas master. La branche cible était derrière master et la demande d'extraction montrait les commits de master, j'ai donc fusionné master et l'ai poussé vers GitHub, mais les commits et les différences pour eux apparaissent toujours dans la demande d'extraction après l'actualisation. J'ai vérifié deux fois que la branche sur GitHub a les commits de master. Pourquoi apparaissent-ils toujours dans la pull request?

J'ai également vérifié la demande d'extraction localement et elle ne montre que les commits non fusionnés.


Cela affecte-t-il le comportement de fusion du PR?
Nathan Hinchey

Non, juste le diff sur Github.
lobati

Est-ce que quelqu'un sait si Gitlab auto-hébergé souffre du même comportement?
Jeff Welling

2
Je suggère que nous contactions tous GitHub pour exprimer notre intérêt à ce que ce comportement soit modifié ( support.github.com/contact ). S'ils n'entendent pas de nous, ils ne sauront pas à quel point c'est important et ce sera ainsi pour toujours.
steinybot le

Réponses:


107

Il semble que la demande d'extraction ne garde pas trace des modifications apportées à la branche cible (j'ai contacté le support GitHub et j'ai reçu une réponse le 18 novembre 2014 indiquant que c'était par conception).

Cependant, vous pouvez l'obtenir pour vous montrer les modifications mises à jour en procédant comme suit:

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

Remplacer githuburl, org, repo, targetbranchet currentbranchselon les besoins.

Ou comme hexsprite l'a souligné dans sa réponse, vous pouvez également le forcer à se mettre à jour en cliquant Editsur le PR et en changeant temporairement la base en une autre branche et vice-versa . Cela produit l'avertissement:

Voulez-vous vraiment changer la base?

Certains commits de l'ancienne branche de base peuvent être supprimés de la chronologie et les anciens commentaires de révision peuvent devenir obsolètes.

Et laissera deux entrées de journal dans le PR:

entrez la description de l'image ici


4
Oui, j'ai contacté le support il y a quelque temps et j'ai eu la même réponse. Ils n'optimisent pas pour cette situation. C'est un peu frustrant. Notre façon de le contourner est simplement de rebaser et de forcer la poussée vers le haut, ou de fermer la traction et d'en créer une nouvelle.
lobati

4
Cette réponse ne résout pas le problème, mais permet simplement à l'utilisateur de voir la vraie différence.
FearlessFuture

4
La question était "Pourquoi apparaissent-ils toujours dans la pull request?". Cela répond à cette question.
Adam Millerchip

3
Consultez mon commentaire pour une bonne solution de contournement. Vous pouvez simplement utiliser le bouton d'édition PR pour passer à une autre branche, puis revenir à la branche de base d'origine et il recalculera le diff.
hexsprite

11
Y a-t-il une demande Dear-Github pour que cela change?
vossad01

89

Voici une bonne solution de contournement. Utilisez le Editbouton lors de l'affichage du PR dans GitHub pour changer la branche de base en autre chose que master. Revenez ensuite à masteret il affichera désormais correctement uniquement les modifications des commits les plus récents.


4
Je suis surpris que plus de gens ne reconnaissent pas cette solution. Je soupçonne que la demande d'extraction originale obsolète serait très bien, mais je n'aimais pas que GitHub montre tous les fichiers obsolètes, alors je l'ai utilisé et il conserve à la fois le commentaire et ne montre que les changements réels sur le point d'être fusionnés . Merci!
taranaki le

2
N'a pas travaillé pour moi.
Shashank le

Bon sang, ça marche!
Anurag Hazra le

Trois ans plus tard et c'est toujours une excellente solution. Et regardez quelqu'un qui vient de commenter il y a quelques heures aussi ^^^
Ricardo Saporta

32

Pour résumer, GitHub ne rebase pas automatiquement l'historique des validations dans les pull requests. Les solutions les plus simples sont:

Solution 1: Rebase

Supposons que vous souhaitiez fusionner à masterpartir de feature-01:

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

Si vous travaillez sur une fourche, vous devrez peut-être remplacer originci-dessus par upstream. Consultez Comment mettre à jour un référentiel fourchu GitHub? pour en savoir plus sur le suivi des branches distantes du référentiel d'origine.

Solution 2: créer une nouvelle demande d'extraction

Supposons que vous souhaitiez fusionner l'intro masterde feature-01:

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

Ouvrez maintenant une pull request pour feature-01-rebasedet fermez celle pour feature-01.


4
Un rebase modifie les hachages de validation, alors finirait-il par mettre à la poubelle les commentaires de révision existants?
haridsv

@haridsv Probablement oui.
Mateusz Piotrowski

Y a-t-il quelque chose à surveiller lorsque vous faites du push -force?
Paul Bendevis

1
@haridsv ce n'est pas mon expérience. Je rebase fréquemment à mi-parcours et les commentaires ne sont pas perdus. Bien que je perde l'historique des changements dans les relations publiques
joel

@JoelBerkeley J'ai en fait vécu quelques critiques entre-temps dans lesquelles l'auteur a rebasé et observé que les commentaires sont intacts. Cependant, nous perdons la capacité de réviser progressivement et pour les révisions importantes, c'est une pénalité énorme pour les réviseurs. Nous avons maintenant quelques directives pour nos PR et l'une de celles-ci est de ne jamais rebaser après l'ouverture de la révision (à moins que l'on ne soit sûr que personne n'a encore commencé à réviser). La fusion est bien, mais notre ligne directrice est de ne pas mélanger le changement de fusion avec d'autres changements autres que les résolutions de conflit.
haridsv

17

Vous devez ajouter les éléments suivants à votre ~/.gitconfigfichier:

[rebase]
    autosquash = true

Cela obtiendra automatiquement la même chose que ce que montre cette réponse .

J'ai eu ça d' ici .


2
putain, j'ai cliqué sur voter par accident. cette réponse m'a aidé. laissez-moi le changer s'il vous plaît.
Hector

@hosein Allez-y. Vous devriez pouvoir le faire maintenant.
Mateusz Piotrowski

1
Je pense que cela devrait être soit la réponse acceptée, soit incluse dans la réponse acceptée. Cela donne le résultat que je recherchais!
Ronald Rey

1
@RonaldRey git rebasing n'est pas une solution universelle, car il implique l'édition de l'historique. Si tout le monde travaille sur des forks privés qui ne sont jamais clonés par d'autres, c'est bien, mais dès que quelqu'un clone votre référentiel et que vous modifiez ensuite l'historique, vous vous retrouvez avec des historiques différents.
Adam Millerchip

14

Pour quiconque rencontre cela et confondu par le comportement de la demande d'extraction de GitHub, la cause première est qu'un PR est un diff de l'extrémité de la branche source par rapport à l'ancêtre commun de la branche source et de la branche cible. Il affichera donc tous les changements sur la branche source jusqu'à l'ancêtre commun et ne prendra pas en compte les changements qui auraient pu survenir sur la branche cible.

Plus d'informations disponibles ici: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Les différences basées sur les ancêtres communs semblent dangereuses. J'aimerais que GitHub ait la possibilité de créer un PR basé sur la fusion à 3 voies plus standard.


1
La raison que vous avez mentionnée semble correcte, mais je suis confus car généralement chaque fois que le maître est mis à jour, je fusionne en arrière les modifications apportées à ma branche ... git checkout my-branch -> git merge master . La demande d'extraction est actualisée immédiatement. L'ancêtre commun est-il également mis à jour?
G.One

2
Ce problème semble se produire lors du rebase au lieu de la fusion
G.One

1
@ G.One, réponse très tardive, mais oui - si vous fusionnez de cette branche principale vers votre branche source, vous avez par définition mis à jour l'ancêtre commun. C'est le commit sur le maître à partir duquel vous avez fusionné.
David K.Hess

13

Une façon de résoudre ce problème est git rebase targetbranchdans ce PR. Ensuite git push --force targetbranch, Github affichera les bons commits et diff. Soyez prudent avec cela si vous ne savez pas ce que vous faites. Peut-être vérifiez d'abord une branche de test pour faire le rebase puis git diff targetbranchpour vous assurer que c'est toujours ce que vous voulez.


10

Cela se produit avec GitHub lorsque vous écrasez des commits fusionnés à partir de la branche cible.

J'avais utilisé squash et fusionner avec Github comme stratégie de fusion par défaut, y compris les fusions de la branche cible. Cela introduit un nouveau commit et GitHub ne reconnaît pas que ce commit écrasé est le même que ceux déjà dans master (mais avec des hachages différents). Git le gère correctement, mais vous voyez à nouveau toutes les modifications dans GitHub, ce qui rend la révision ennuyeuse. La solution est de faire une fusion régulière de ces commits en amont au lieu d'un squash et d'une fusion. Lorsque vous souhaitez fusionner une autre branche dans la vôtre en tant que dépendance, git merge --squashet revenir sur cette seule validation avant de retirer du master une fois que cette autre branche l'a effectivement fait pour master.

EDIT: une autre solution consiste à rebaser et à forcer la poussée. Histoire propre mais réécrite


1
Merci @achille, c'était vraiment le problème de mon côté. Après avoir désactivé la fusion de squash, il est résolu.
Ashvin777

0

Je ne suis pas vraiment sûr de la théorie derrière cela. Mais j'ai eu cela plusieurs fois et j'ai pu résoudre ce problème en procédant comme suit.

git pull --rebase

Cela récupérera et fusionnera les modifications de votre branche principale du référentiel d'origine (si vous avez pointé dessus)

Ensuite, vous poussez vos modifications avec force dans votre référentiel cloné github (cible)

git push -f origin master

Cela garantira que votre clone github et votre dépôt parent sont au même niveau de validation github et que vous ne voyez pas de changements inutiles entre les branches.


0

Essayez les commandes ci-dessous, une par une.

git pull "latest

git reset --hard master

-1

Approche sans échec si vous êtes trop inquiet de gâcher les choses: accédez au fichier et supprimez manuellement les modifications, puis écrasez avec votre dernier commit en utilisant

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})"

I il n'y a pas de conflits, vous êtes prêt à partir

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.