469 votes

Comment puis-je prévisualiser une fusion dans git ?

J'ai une branche git (la branche principale, par exemple) et je veux fusionner avec une autre branche de développement. Ou dois-je le faire ?

Afin de décider si je veux vraiment fusionner cette branche, j'aimerais voir une sorte d'aperçu de ce que la fusion fera. De préférence avec la possibilité de voir la liste des commits qui sont appliqués.

Jusqu'à présent, le mieux que j'ai pu trouver, c'est merge --no-ff --no-commit et ensuite diff HEAD .

22 votes

J'ai juste git merge y git reset --keep HEAD@{1} si je n'aime pas le résultat.

3 votes

Notez que voir la liste des commits avec leur diff ne raconte pas nécessairement toute l'histoire - si la fusion est non triviale, et surtout s'il y a des conflits, le résultat réel de la fusion peut être un peu intéressant.

0 votes

Le problème est d'essayer de voir facilement quels sont les changements réels qui ont été apportés.

461voto

Jan Hudec Points 27417
  • git log ..otherbranch
    • liste des changements qui seront fusionnés dans la branche courante.
  • git diff ...otherbranch
    • diff de l'ancêtre commun (base de fusion) à la tête de ce qui sera fusionné. Notez les trois points qui ont une signification particulière par rapport aux deux points (voir ci-dessous).
  • gitk ...otherbranch
    • représentation graphique des branches depuis leur dernière fusion.

Une chaîne vide implique HEAD donc c'est pour ça que ..otherbranch au lieu de HEAD..otherbranch .

Les deux ou trois points ont une signification légèrement différente pour diff que pour les commandes qui listent les révisions (log, gitk etc.). Pour log et les autres, deux points ( a..b ) signifie que tout ce qui est dans b mais pas a et trois points ( a...b ) signifie que tout ce qui se trouve dans une seule des a o b . Mais diff fonctionne avec deux révisions et là le cas le plus simple représenté par deux points ( a..b ) est une simple différence par rapport à a a b et trois points ( a...b ) différence moyenne entre l'ancêtre commun et b ( git diff $(git merge-base a b)..b ).

7 votes

Le troisième point était la partie qui me manquait, merci ! L'approche du journal fonctionne bien aussi, log -p --reverse ..otherbranch semble être un bon moyen de voir ce qui serait fusionné.

1 votes

Il me manquait git checkout master avant d'essayer ça. Je me demandais pourquoi il disait que toutes mes modifications allaient être écrasées...

7 votes

git show ..otherbranch affichera une liste des changements et des diff qui seront fusionnés dans la branche courante.

19voto

djschny Points 126

Si vous êtes comme moi, vous cherchez l'équivalent pour svn update -n . Le texte suivant semble faire l'affaire. Notez que vous devez faire un git fetch afin que votre dépôt local dispose des mises à jour appropriées pour la comparaison.

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

ou si vous voulez une différence entre votre tête et la télécommande :

$ git fetch origin
$ git diff origin/master

Cette solution est beaucoup plus facile et moins sujette aux erreurs (et donc beaucoup moins risquée) que la solution supérieure qui propose "fusionner puis abandonner".

1 votes

Devrait être $ git checkout target-branch et ensuite $ git diff --name-status ...branch-to-be-merged (les trois points sont essentiels, il faut donc les taper tels quels)

0 votes

Il manque une chose : il ne vous montre pas quels fichiers auraient un conflit -- ils ont le même marqueur "M" que les fichiers qui ont été modifiés sur la branche mais qui peuvent être fusionnés sans aucun conflit.

0 votes

Peut-être que les choses étaient différentes en 2012, mais de nos jours, l'abandon d'une fusion semble assez fiable, donc je ne pense pas qu'il soit juste de caractériser cela comme "beaucoup plus facile et moins sujet aux erreurs" à l'heure actuelle.

6voto

michael_n Points 980

En complément des réponses existantes, un alias pourrait être créé pour afficher le diff et/ou le log avant une fusion. De nombreuses réponses omettent le fetch avant de "prévisualiser" la fusion ; il s'agit d'un alias qui combine ces deux étapes en une seule (émulant quelque chose de similaire à la fonction de mercurial hg incoming / outgoing )

Ainsi, en s'appuyant sur " git log ..otherbranch "vous pouvez ajouter les éléments suivants à ~/.gitconfig :

...
[alias]
    # fetch and show what would be merged (use option "-p" to see patch)
    incoming = "!git remote update -p; git log ..@{u}"

Pour des raisons de symétrie, l'alias suivant peut être utilisé pour montrer ce qui est commis et serait poussé, avant de le pousser :

    # what would be pushed (currently committed)
    outgoing = log @{u}..

Et ensuite vous pouvez exécuter " git incoming "pour montrer un grand nombre de changements, ou " git incoming -p "pour afficher le patch (c'est-à-dire le "diff"), " git incoming --pretty=oneline "pour un résumé laconique, etc. Vous pouvez ensuite (facultativement) exécuter " git pull "pour fusionner réellement. (Bien que, puisque vous avez déjà récupéré, la fusion pourrait être faite directement).

De même, " git outgoing "montre ce qui serait poussé si vous exécutez " git push ".

0 votes

"De nombreuses réponses omettent le fetch" - C'est parce que la question portait sur l'aperçu de la fusion ; pas sur le pull ou le push. Il n'est pas nécessaire de récupérer les données avant une fusion, sauf dans le cas spécifique du pull (bien que lors de la fusion dans une branche qui existe à distance, c'est généralement une bonne idée de tirer cette branche d'abord, pour s'assurer que vous avez une version à jour de celle-ci).

0 votes

Si vous relisez attentivement votre commentaire, vous verrez que vous confondez "pull" avec "merge" et "fetch", ce qui est courant, mais déroutant lorsque la distinction est importante (comme c'est le cas ici). stackoverflow.com/a/292359/127971

0 votes

\=2, "conflate" - mot cool ! :) En fait, j'aime aussi votre réponse, elle montre un cas d'utilisation de merge-preview que certains pourraient trouver utile. Maintenant, si vous relisez la question, et ensuite mon premier commentaire à votre réponse, vous pouvez remarquer que j'avais l'intention de souligner qu'un pull (qui en essence est juste un fetch suivi d'une fusion) est le seul cas où vous auriez besoin de récupérer avant de prévisualiser ou d'appliquer une fusion. Et le PO a demandé spécifiquement la partie fusion uniquement, qui a de nombreux cas d'utilisation en dehors de la mise à jour d'une branche locale avec des changements sur son homologue distant.

6voto

pablox Points 969

Si vous avez déjà récupéré les modifications, ma préférée est la suivante :

git log ...@{u}

Cela nécessite git 1.7.x je crois. Le site @{u} est un "raccourci" pour la branche amont, il est donc un peu plus polyvalent que la notation git log ...origin/master .

Note : Si vous utilisez zsh et que le glog étendu est activé, vous devrez probablement faire quelque chose comme :

git log ...@\{u\}

1voto

Chugaister Points 118

Peut-être cela peut-il vous aider ? git-diff-tree - Compare le contenu et le mode des blobs trouvés via deux objets d'arbre

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X