Requête GitHub montrant les commits déjà dans la branche cible
J'essaie de passer en revue une demande d'extraction sur GitHub auprès d'une branche qui n'est pas maîtresse. La branche cible était derrière le maître et la demande d'extraction indiquait les commits du maître. J'ai donc fusionné le maître et l'a transféré vers GitHub, mais les commits et les diff pour eux apparaissent toujours dans la demande d'extraction après l'actualisation. J'ai doublé vérifié que la branche sur GitHub a les commits du maître. Pourquoi apparaissent-ils toujours dans la demande d'extraction?
J'ai également vérifié la demande d'extraction localement et elle n'affiche que les commits non fusionnés.
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 reçu une réponse le 18 novembre 2014 indiquant que cela est voulu par la 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
Remplacez githuburl, org, repo, targetbranch et currentbranch au besoin.
Ou, comme hexsprite l’a souligné dans sa réponse, vous pouvez également le forcer à se mettre à jour en cliquant sur Edit sur le PR et changer temporairement la base dans une autre branche et inversement. Cela produit l'avertissement:
Etes-vous sûr de vouloir changer de 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 va laisser deux entrées de journal dans le PR:
Voici une bonne solution de contournement. Utilisez le bouton Edit lorsque vous affichez le PR dans GitHub pour modifier la branche de base en un autre élément que master. Puis revenez à master et il ne montrera désormais correctement que les modifications des dernières mises à jour.
Pour résumer, GitHub ne rebase pas automatiquement l'historique de validation dans les requêtes d'extraction. Les solutions les plus simples sont:
Solution 1: Rebase
Supposons que vous souhaitiez fusionner dans master à partir de feature-01:
git fetch Origin
git checkout feature-01
git rebase Origin/master
git Push --force
Si vous travaillez sur un fork, vous devrez peut-être remplacer Origin ci-dessus par upstream. Voir Comment mettre à jour un référentiel 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 master de feature-01:
git checkout feature-01
git checkout -b feature-01-rebased
git Push -u Origin feature-01-rebased
Ouvrez maintenant une demande de tirage pour feature-01-rebased et fermez celui pour feature-01.
Une façon de résoudre ce problème consiste à git rebase targetbranch dans ce PR. Ensuite git Push --force targetbranch, alors Github affichera les bons commits et diff. Soyez prudent avec cela si vous ne savez pas ce que vous faites. Peut-être que vous allez commencer par vérifier une branche de test pour faire le rebase puis git diff targetbranch pour vous assurer que c'est toujours ce que vous voulez.
Pour tous ceux qui découvrent cela et sont déroutés par le comportement de la requête d'extraction GitHub, la cause première est qu'un PR est un diff de la pointe de la branche source par rapport à l'ancêtre commun de la branche source et de la branche cible. Il affichera donc toutes les modifications sur la branche source jusqu'à l'ancêtre commun et ne tiendra pas compte des modifications éventuelles sur la branche cible.
Plus d'informations disponibles ici: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/
Les différences communes basées sur les ancêtres semblent dangereuses. J'aimerais que GitHub ait la possibilité de créer un PR basé sur la fusion à trois voies plus standard.
Vous devez ajouter ce qui suit à votre ~/.gitconfig fichier:
[rebase]
autosquash = true
Cela donnera automatiquement le même résultat que cette réponse .
Je l'ai eu de ici .
Cela se produit avec GitHub lorsque vous supprimez les commits fusionnés à partir de la branche cible.
J'avais utilisé squash et fusionné avec Github comme stratégie de fusion par défaut, y compris les fusions à partir de la branche cible. Ceci introduit un nouveau commit et GitHub ne reconnaît pas que ce commit écrasé est le même que ceux déjà en master (mais avec des hachages différents). Git le gère correctement mais vous voyez à nouveau tous les changements dans GitHub, ce qui rend la révision fastidieuse. La solution consiste à effectuer une fusion régulière de ces commits entrés en amont au lieu d'une fusion et d'une fusion. Lorsque vous souhaitez fusionner une autre branche dans la vôtre en tant que dépendance, git merge --squash et annulez ce simple commit avant de tirer du maître une fois que cette autre branche l’a réellement fait.
Je ne suis pas tout à fait sûr de la théorie derrière tout ça. Mais je l'ai eu plusieurs fois et capable de résoudre ce problème en procédant comme suit.
git pull --rebase
Ceci récupérera et fusionnera les modifications de votre branche principale de référentiel d'origine (si vous pointez dessus)
Ensuite, vous transmettez vos modifications avec force à votre référentiel cloné github (cible)
git Push -f Origin master
Cela garantira que votre clone github et votre référant parent sont au même niveau de validation github et que vous ne verrez aucune modification inutile dans les branches.