Comment prévisualiser une fusion dans git?

J'ai une branche git (la ligne principale, par exemple) et je veux fusionner dans une autre branche de développement. Ou alors?

Afin de décider si je veux vraiment fusionner cette branche, je voudrais 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 appliqués.

Jusqu'à présent, le mieux que je puisse trouver est merge --no-ff --no-commit, et puis diff HEAD.

J'ai trouvé que la solution qui me convenait le mieux était de simplement effectuer la fusion et de l'annuler en cas de conflit . Cette syntaxe particulière me semble propre et simple. Il s'agit de la stratégie 2 ci-dessous.

Cependant, si vous voulez vous assurer de ne pas gâcher votre branche actuelle, ou si vous n'êtes tout simplement pas prêt à fusionner indépendamment de l'existence de conflits, créez simplement une nouvelle sous-branche et fusionnez-la:

Stratégie 1: La manière sûre - fusionner une branche temporaire:

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

De cette façon, vous pouvez simplement supprimer la branche temporaire si vous voulez simplement voir quels sont les conflits. Vous n'avez pas à vous soucier d '«abandonner» la fusion, et vous pouvez retourner à votre travail - il vous suffit de retirer à nouveau «mybranch» et vous n'aurez aucun code fusionné ni conflit de fusion dans votre branche.

Il s'agit essentiellement d'un essai à sec.

Stratégie 2: quand vous voulez vraiment fusionner, mais seulement s'il n'y a pas de conflits

git checkout mybranch
git merge some-other-branch

Si git signale des conflits (et UNIQUEMENT EN CAS DE CONFLIT ), vous pouvez alors:

git merge --abort

Si la fusion réussit, vous ne pouvez pas l'annuler (seulement réinitialiser).

Si vous n'êtes pas prêt à fusionner, utilisez la méthode plus sûre ci-dessus.

[EDIT: 2016-Nov - J'ai échangé la stratégie 1 pour 2, car il semble que la plupart des gens recherchent «la manière sûre». La stratégie 2 est désormais plus une note que vous pouvez simplement annuler la fusion si la fusion a des conflits que vous n'êtes pas prêt à traiter. Gardez à l'esprit si vous lisez des commentaires!]

• git log ..otherbranch
  • liste des modifications qui seront fusionnées dans la branche actuelle.
• 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 à deux points (voir ci-dessous).
• gitk ...otherbranch
  • représentation graphique des branches depuis leur dernière fusion.

Une chaîne vide implique HEAD, c'est pourquoi juste ..otherbranchau lieu de HEAD..otherbranch.

Les deux contre 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 autres, deux points ( a..b) signifient tout ce qui est dans bmais pas aet trois points ( a...b) signifient tout ce qui est dans un seul aou b. Mais diff fonctionne avec deux révisions et là le cas le plus simple représenté par deux points ( a..b) est la différence simple de aà bet trois points ( a...b) différence moyenne entre ancêtre commun et b( git diff $(git merge-base a b)..b).

Si vous êtes comme moi, vous cherchez l'équivalent de svn update -n. Ce qui suit semble faire l'affaire. Notez que assurez-vous de faire une git fetchpremière afin que votre référentiel local dispose des mises à jour appropriées pour comparer.

$ 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 un diff de votre tête à la télécommande:

$ git fetch origin
$ git diff origin/master

IMO cette solution est beaucoup plus facile et moins sujette aux erreurs (et donc beaucoup moins risquée) que la solution haut de gamme qui propose de "fusionner puis abandonner".

La plupart des réponses ici nécessitent soit un répertoire de travail propre et plusieurs étapes interactives (mauvaises pour les scripts), soit ne fonctionnent pas dans tous les cas, par exemple les fusions passées qui apportent déjà certaines des modifications en suspens dans votre branche cible, ou des sélections faisant le même.

Pour vraiment voir ce qui changerait dans la masterbranche si vous y fusionniez, developen ce moment:

git merge-tree $(git merge-base master develop) master develop

Comme c'est une commande de plomberie, elle ne devine pas ce que vous voulez dire, vous devez être explicite. Il ne colore pas non plus la sortie ni n'utilise votre pager, donc la commande complète serait:

git merge-tree $(git merge-base master develop) master develop | colordiff | less -R

- https://git.seveas.net/previewing-a-merge-result.html

(merci à David Normington pour le lien)

PS:

Si vous obtenez des conflits de fusion, ils s'afficheront avec les marqueurs de conflit habituels dans la sortie, par exemple:

$ git merge-tree $(git merge-base a b ) a b 
added in both
  our    100644 78981922613b2afb6025042ff6bd878ac1994e85 a
  their  100644 61780798228d17af2d34fce4cfbdf35556832472 a
@@ -1 +1,5 @@
+<<<<<<< .our
 a
+=======
+b
+>>>>>>> .their

L'utilisateur @dreftymac fait valoir un bon argument: cela le rend impropre à l'écriture de scripts, car vous ne pouvez pas facilement saisir cela dans le code d'état. Les marqueurs de conflit peuvent être très différents selon les circonstances (supprimés vs modifiés, etc.), ce qui rend également difficile la grep. Il faut se méfier.

Si vous avez déjà récupéré les modifications, mon préféré est:

git log ...@{u}

Cela nécessite cependant git 1.7.x. La @{u}notation est un "raccourci" pour la branche en amont, donc c'est un peu plus polyvalent que git log ...origin/master.

Remarque: Si vous utilisez zsh et la fonction glog étendue, vous devrez probablement faire quelque chose comme:

git log ...@\{u\}

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

Donc, en vous appuyant sur " git log ..otherbranch", vous pouvez ajouter ce qui suit à ~/.gitconfig:

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

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

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

Et puis vous pouvez exécuter " git incoming" pour afficher un grand nombre de modifications, ou " git incoming -p" pour afficher le correctif (c'est-à-dire le "diff"), " git incoming --pretty=oneline", pour un résumé concis, etc. Vous pouvez ensuite (facultativement) exécuter " git pull" pour fusionnent réellement. (Cependant, puisque vous avez déjà récupéré, la fusion peut être effectuée directement.)

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

git log currentbranch..otherbranchvous donnera la liste des commits qui iront dans la branche courante si vous faites une fusion. Les arguments habituels pour vous connecter qui donnent des détails sur les commits vous donneront plus d'informations.

git diff currentbranch otherbranchvous donnera la différence entre les deux commits qui deviendront un. Ce sera un diff qui vous donnera tout ce qui sera fusionné.

Est-ce que cela aiderait?

Pull Request - J'ai utilisé la plupart des idées déjà soumises, mais celle que j'utilise aussi souvent est (surtout si elle provient d'un autre développeur) de faire une Pull Request qui donne un moyen pratique de revoir toutes les modifications d'une fusion avant qu'elle ne prenne endroit. Je sais que GitHub n'est pas git, mais c'est certainement pratique.

À moins d'effectuer réellement la fusion de manière jetable (voir la réponse de Kasapo), il ne semble pas y avoir de moyen fiable de voir cela.

Cela dit, voici une méthode qui se rapproche légèrement:

git log TARGET_BRANCH...SOURCE_BRANCH --cherry

Cela donne une indication juste des validations qui feront la fusion. Pour voir les différences, ajoutez -p. Pour voir les noms de fichiers, ajouter l' un --raw, --stat, --name-only, --name-status.

Le problème avec l' git diff TARGET_BRANCH...SOURCE_BRANCHapproche (voir la réponse de Jan Hudec) est que vous verrez des différences pour les changements déjà dans votre branche cible si votre branche source contient des fusions croisées.

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

Je ne veux pas utiliser la commande git merge comme précurseur de l'examen des fichiers en conflit. Je ne veux pas faire de fusion, je veux identifier les problèmes potentiels avant de fusionner - des problèmes que la fusion automatique pourrait me cacher. La solution que je cherchais est de savoir comment avoir git cracher une liste de fichiers qui ont été modifiés dans les deux branches qui seront fusionnés à l'avenir, par rapport à un ancêtre commun. Une fois que j'ai cette liste, je peux utiliser d'autres outils de comparaison de fichiers pour explorer plus loin les choses. J'ai cherché plusieurs fois et je n'ai toujours pas trouvé ce que je veux dans une commande native git.

Voici ma solution de contournement, au cas où cela aiderait quelqu'un d'autre là-bas:

Dans ce scénario, j'ai une branche appelée QA qui comporte de nombreux changements depuis la dernière version de production. Notre dernière version de production est étiquetée "15.20.1". J'ai une autre branche de développement appelée new_stuff que je veux fusionner avec la branche QA. QA et new_stuff pointent tous les deux sur les commits qui "suivent" (comme rapporté par gitk) la balise 15.20.1.

git checkout QA
git pull
git diff 15.20.1 --name-only > QA_files
git checkout new_stuff
git pull
git diff 15.20.1 --name-only > new_stuff_files
comm -12 QA_files new_stuff_files

Voici quelques discussions qui expliquent pourquoi je souhaite cibler ces fichiers spécifiques:

Comment puis-je faire confiance à Git Merge?

/software/199780/how-far-do-you-trust-automerge