En utilisant gitk log
, je n'ai pas pu voir de différence entre les deux. Comment puis-je observer la différence (avec une commande git ou un outil)?
En utilisant gitk log
, je n'ai pas pu voir de différence entre les deux. Comment puis-je observer la différence (avec une commande git ou un outil)?
Réponses:
L' --no-ff
indicateur empêche git merge
d'exécuter une "avance rapide" s'il détecte que votre courant HEAD
est un ancêtre de la validation que vous essayez de fusionner. Une avance rapide est lorsque, au lieu de construire une validation de fusion, git déplace simplement votre pointeur de branche pour pointer vers la validation entrante. Cela se produit généralement lorsque vous effectuez un git pull
sans aucun changement local.
Cependant, vous souhaitez parfois empêcher ce problème de se produire, généralement parce que vous souhaitez conserver une topologie de branche spécifique (par exemple, vous fusionnez dans une branche de rubrique et vous voulez vous assurer qu'elle ressemble à cela lors de la lecture de l'historique). Pour ce faire, vous pouvez passer le --no-ff
drapeau et git merge
sera toujours construire une fusion au lieu de l' avance rapide.
De même, si vous souhaitez exécuter un git pull
ou utiliser git merge
afin d'avancer explicitement rapidement, et que vous souhaitez renflouer s'il ne peut pas avancer rapidement, vous pouvez utiliser l' --ff-only
indicateur. De cette façon, vous pouvez régulièrement faire quelque chose comme git pull --ff-only
sans réfléchir, puis en cas d'erreur, vous pouvez revenir en arrière et décider si vous souhaitez fusionner ou rebaser.
gitk
ou git log --graph
que la fusion à avance rapide n'a pas créé de validation de fusion, tandis que celle à avance rapide ne l'a pas fait.
--no-ff
d'une fonctionnalité à développer ou développer à maîtriser est similaire à la fusion d'une demande de pull?
--no-ff
.
Voici un site avec une explication claire et une illustration graphique de l'utilisation git merge --no-ff
:
Jusqu'à ce que je voie cela, j'étais complètement perdu avec Git. L'utilisation --no-ff
permet à une personne qui examine l'historique de voir clairement la branche sur laquelle vous avez travaillé. (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 bien la première avec plus de concentration sur ceux qui connaissent moins git.
Si vous êtes comme moi et pas un Git-gourou, ma réponse décrit ici la gestion de la suppression de fichiers du suivi de git sans les supprimer du système de fichiers local, ce qui semble mal documenté mais souvent survenu. Une autre situation nouvelle consiste à obtenir le code actuel , qui parvient toujours à m'échapper.
J'ai mis à jour un package sur mon site Web et j'ai dû revenir à mes notes pour voir mon flux de travail; J'ai pensé qu'il était utile d'ajouter un exemple à cette réponse.
Mon workflow de 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
Ci-dessous: utilisation réelle, y compris les explications.
Remarque: la sortie ci-dessous est coupée; git est assez bavard.
$ 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
Remarquez 3 choses ci-dessus:
1) Dans la sortie, vous pouvez voir les modifications de la mise à niveau du package ECC, y compris l'ajout de nouveaux fichiers.
2) Notez également qu'il y a deux fichiers (pas dans le /ecc
dossier) que j'ai supprimés indépendamment de ce changement. Au lieu de confondre ces suppressions de fichiers ecc
, je créerai une cleanup
branche différente plus tard pour refléter la suppression de ces fichiers.
3) Je n'ai pas suivi mon workflow! J'ai oublié git pendant que j'essayais de faire fonctionner ecc à nouveau.
Ci-dessous: plutôt que de faire le tout compris, 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 des miens 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
Ayant utilisé ce processus plus de 10 fois par jour, je me suis mis à écrire des scripts batch pour exécuter les commandes, j'ai donc fait un git_update.sh <branch> <"commit message">
script presque approprié pour effectuer les étapes ci-dessus. Voici la source Gist pour ce script.
Au lieu de git commit -am
sélectionner des fichiers dans la liste "modifiée" produite via git status
puis les coller dans ce script. Cela est dû au fait que j'ai effectué des dizaines de modifications mais que je voulais des noms de branche variés pour aider à regrouper les changements.
--no-ff
option?
Fusion explicite : crée une nouvelle validation de fusion. (C'est ce que vous obtiendrez si vous l'utilisiez --no-ff
.)
Fast Forward Merge: avancer rapidement, sans créer de nouveau commit:
Rebase : Établir un nouveau niveau de base:
Courge: écraser ou presser (quelque chose) avec force pour qu'elle devienne plate:
L' --no-ff
option garantit qu'aucune fusion d'avance rapide ne se produira et qu'un nouvel objet de validation sera toujours créé . Cela peut être souhaitable si vous souhaitez que git conserve un historique des branches de fonctionnalités.
Dans l'image ci-dessus, le côté gauche est un exemple de l'historique git après utilisation git merge --no-ff
et le côté droit est un exemple d'utilisation git merge
où une fusion ff était possible.
EDIT : une version précédente de cette image indiquait un seul parent pour la validation de fusion. Les validations de fusion ont plusieurs validations parentales que git utilise pour conserver un historique de la "branche de fonctionnalité" et de la branche d'origine. Les multiples liens parents sont surlignés en vert.
C'est une vieille question, et elle est quelque peu subtilement mentionnée dans les autres articles, mais l'explication qui a fait ce déclic pour moi est que les fusions non rapides nécessiteront un commit séparé .
git merge --no-ff ecc
vous aurez simplement un commit de fusion supplémentaire dans le git log
maître de branche. Cela n'est techniquement pas nécessaire dans le cas où maître pointe vers un ancêtre direct de la validation ecc est activé, mais en spécifiant l'option --no-ff, vous forcez la création de cette validation de fusion. Il aura le titre:Merge branch 'ecc'
L'indicateur --no-ff fait que la fusion crée toujours un nouvel objet de validation, même si la fusion peut être effectuée avec une avance rapide. Cela évite de perdre des informations sur l'existence historique d'une branche de fonctionnalité et regroupe tous les validations qui ont ajouté la fonctionnalité ensemble.