Quelle est la différence entre `git merge` et `git merge --no-ff` ?

Question

Utilisation de gitk log Je n'ai pas pu faire la différence entre les deux. Comment puis-je observer la différence (avec une commande git ou un outil quelconque) ?

Answer 1

Le site --no-ff le drapeau empêche git merge d'exécuter un "fast-forward" s'il détecte que votre actuel HEAD est un ancêtre du commit que vous essayez de fusionner. Un fast-forward est le cas où, au lieu de construire un commit de fusion, git déplace simplement votre pointeur de branche pour pointer sur le commit entrant. Cela se produit généralement lors de l'exécution d'un git pull sans aucune modification locale.

Cependant, il arrive que vous vouliez empêcher ce comportement de se produire, typiquement parce que vous voulez maintenir une topologie de branche spécifique (par exemple, vous fusionnez dans une branche de sujet et vous voulez vous assurer qu'il en soit ainsi lors de la lecture de l'historique). Pour ce faire, vous pouvez passer l'option --no-ff et git merge sera toujours construire une fusion au lieu de faire une avance rapide.

De même, si vous voulez exécuter un git pull ou utiliser git merge afin d'effectuer une avance rapide explicite, et que vous souhaitez vous désister si l'avance rapide ne peut pas être effectuée, vous pouvez alors utiliser la fonction --ff-only drapeau. De cette façon, vous pouvez régulièrement faire quelque chose comme git pull --ff-only sans réfléchir, et ensuite, s'il y a des erreurs, vous pouvez revenir en arrière et décider si vous voulez fusionner ou rebaser.

Answer 2

Réponse graphique à cette question

Voici un site avec une explication claire et une illustration graphique de l'utilisation de la git merge --no-ff :

Jusqu'à ce que je voie ça, j'étais complètement perdu avec git. Utilisation de --no-ff permet à quelqu'un qui revoit l'histoire de clairement voir la branche que vous avez vérifiée pour travailler. (ce lien pointe vers l'outil de visualisation "réseau" de github) Et voici une autre grande référence avec des illustrations. Cette référence complète agréablement la première en se concentrant davantage sur les personnes moins familiarisées avec git.

---

Informations de base pour les novices comme moi

Si vous êtes comme moi, et pas un gourou de Git, ma réponse ici décrit la gestion de la suppression des fichiers du suivi de git sans les supprimer du système de fichiers local, ce qui semble peu documenté mais se produit souvent. Une autre situation pour les débutants est obtention du code actuel qui m'échappe encore.

---

Exemple de flux de travail

J'ai mis à jour un paquet sur mon site Web et j'ai dû retourner à mes notes pour voir mon flux de travail ; j'ai pensé qu'il était utile d'ajouter un exemple à cette réponse.

Mon flux de travail des commandes git :

git checkout -b contact-form
(do your work on "contact-form")
git status
git commit -am  "updated form in contact module"
git checkout master
git merge --no-ff contact-form
git branch -d contact-form
git push origin master

En dessous : l'usage réel, y compris les explications.
Note : la sortie ci-dessous est un extrait ; git est assez verbeux.

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   ecc/Desktop.php
#       modified:   ecc/Mobile.php
#       deleted:    ecc/ecc-config.php
#       modified:   ecc/readme.txt
#       modified:   ecc/test.php
#       deleted:    passthru-adapter.igs
#       deleted:    shop/mickey/index.php
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       ecc/upgrade.php
#       ecc/webgility-config.php
#       ecc/webgility-config.php.bak
#       ecc/webgility-magento.php

Notez 3 choses d'en haut :
1) Dans la sortie, vous pouvez voir les modifications apportées par la mise à niveau du paquet ECC, y compris l'ajout de nouveaux fichiers.
2) Remarquez également qu'il y a deux fichiers (pas dans le fichier /ecc dossier) que j'ai supprimé indépendamment de ce changement. Au lieu de confondre ces suppressions de fichiers avec ecc je vais faire une autre cleanup plus tard pour refléter la suppression de ces fichiers.
3) Je n'ai pas suivi mon flux de travail ! J'ai oublié git pendant que j'essayais de faire fonctionner ecc à nouveau.

En dessous : plutôt que de faire le tout-inclus git commit -am "updated ecc package" Je le ferais normalement, je voulais seulement ajouter les fichiers dans le /ecc dossier. Ces fichiers supprimés ne faisaient pas spécifiquement partie de mon git add mais comme ils étaient déjà suivis dans git, je dois les supprimer du commit de cette branche :

$ git checkout -b ecc
$ git add ecc/*
$ git reset HEAD passthru-adapter.igs
$ git reset HEAD shop/mickey/index.php
Unstaged changes after reset:
M       passthru-adapter.igs
M       shop/mickey/index.php

$ git commit -m "Webgility ecc desktop connector files; integrates with Quickbooks"

$ git checkout master
D       passthru-adapter.igs
D       shop/mickey/index.php
Switched to branch 'master'
$ git merge --no-ff ecc
$ git branch -d ecc
Deleted branch ecc (was 98269a2).
$ git push origin master
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 59.00 KiB, done.
Total 14 (delta 10), reused 0 (delta 0)
To git@github.com:me/mywebsite.git
   8a0d9ec..333eff5  master -> master

---

script pour automatiser ce qui précède.

Après avoir utilisé ce processus plus de 10 fois par jour, j'ai pris l'habitude d'écrire des scripts de traitement par lots pour exécuter les commandes, et j'ai donc créé un script presque parfait. git_update.sh <branch> <"commit message"> script pour effectuer les étapes ci-dessus. Voici la source du Gist pour ce script.

Au lieu de git commit -am Je sélectionne les fichiers à partir de la liste "modifiée" produite via git status puis les coller dans ce script. Cela s'est produit parce que j'ai fait des dizaines d'éditions mais je voulais des noms de branches variés pour aider à regrouper les changements.

Answer 3

Fusionner les stratégies

Fusion explicite (c'est-à-dire sans avance rapide) : Crée un nouveau commit de fusion. (C'est ce que vous obtiendrez si vous utilisez --no-ff .)

Fusion en avance rapide : Avancer rapidement, sans créer un nouveau commit :

Rebasement : Établir un nouveau niveau de base :

Courge : Écraser ou presser (quelque chose) avec force pour qu'il devienne plat :

Answer 4

Le site --no-ff L'option garantit qu'une fusion en avance rapide ne se produira pas, et que un nouvel objet commit sera toujours créé . Cela peut être souhaitable si vous voulez que git maintienne un historique des branches de fonctionnalités.              Dans l'image ci-dessus, le côté gauche est un exemple de l'historique de git après avoir utilisé git merge --no-ff et le côté droit est un exemple d'utilisation de git merge où une fusion ff était possible.

EDIT : Une version précédente de cette image n'indiquait qu'un seul parent pour le commit de fusion. Les commits de fusion ont plusieurs commits parents que git utilise pour maintenir un historique de la "feature branch" et de la branche d'origine. Les liens parentaux multiples sont surlignés en vert.

Answer 5

Il s'agit d'une vieille question, qui est mentionnée de manière quelque peu subtile dans les autres messages, mais l'explication qui m'a fait cliquer est que les fusions non rapides nécessiteront une validation séparée. .