Réponses:
Les deux git merge --squash
et git rebase --interactive
peuvent produire un commit "écrasé".
Mais ils servent à des fins différentes.
produira un commit écrasé sur la branche de destination, sans marquer de relation de fusion.
(Remarque: il ne produit pas de commit tout de suite: vous en avez besoin d'un supplémentaire git commit -m "squash branch"
)
Ceci est utile si vous souhaitez supprimer complètement la branche source, en partant de (schéma tiré de la question SO ):
git checkout stable
X stable
/
a---b---c---d---e---f---g tmp
à:
git merge --squash tmp
git commit -m "squash tmp"
X-------------------G stable
/
a---b---c---d---e---f---g tmp
puis en supprimant la tmp
branche.
Remarque: git merge
a une --commit
option , mais ne peut pas être utilisée avec --squash
. Il n'a jamais été possible d'utiliser --commit
et --squash
ensemble.
Depuis Git 2.22.1 (Q3 2019), cette incompatibilité est rendue explicite:
Voir commit 1d14d0c (24 mai 2019) par Vishal Verma ( reloadbrain
) .
(Fusionné par Junio C Hamano - gitster
- en commit 33f2790 , 25 juil.2019 )
merge
: refuser--commit
avec--squash
Auparavant, lorsqu'il
--squash
était fourni, 'option_commit
' était silencieusement abandonné. Cela aurait pu surprendre un utilisateur qui a tenté de remplacer le comportement sans validation de squash en utilisant--commit
explicitement.
git/git
builtin/merge.c#cmd_merge()
comprend désormais:
if (option_commit > 0)
die(_("You cannot combine --squash with --commit."));
rejoue une partie ou la totalité de vos commits sur une nouvelle base, vous permettant de squash (ou plus récemment de "réparer", voir cette question SO ), en allant directement à:
git checkout tmp
git rebase -i stable
stable
X-------------------G tmp
/
a---b
Si vous choisissez d'écraser tous les commits de tmp
(mais, contrairement à merge --squash
, vous pouvez choisir d'en rejouer certains et d'en écraser d'autres).
Les différences sont donc:
squash
ne touche pas à votre branche source ( tmp
ici) et crée un seul commit où vous le souhaitez.rebase
vous permet de continuer sur la même branche source (toujours tmp
) avec:
tmp
commits écrasés ensemble.
G
ne représentera pas le même contenu que g
, en raison des changements introduits par X
.
git merge --no-ff temp
au lieu de git merge --squash temp
, alors vous obtenez un historique plus compliqué, mais vous pouvez également faire des choses comme git revert e
, beaucoup plus facilement. C'est une histoire désordonnée, mais honnête et pragmatique, et la branche principale reste assez propre.
git bisect
ou git blame
lorsqu'il est utilisé trop souvent (comme dans git pull --no-ff
: stackoverflow.com/questions/12798767/… ). Il n'y a pas une approche de toute façon, c'est pourquoi cet article en décrit trois ( stackoverflow.com/questions/9107861/… )
Fusionner les validations: conserve toutes les validations dans votre branche et les entrelace avec les validations sur la branche de base
Fusionner Squash: conserve les modifications mais omet l'individu commet de l'historique
Rebase: Cela déplace la branche d'entité entière pour commencer à l'extrémité de la branche principale, incorporant efficacement toutes les nouvelles validations dans master
Plus ici
Merge squash fusionne un arbre (une séquence de commits) en un seul commit. Autrement dit, il écrase toutes les modifications apportées dans n commits en un seul commit.
La refondation est une nouvelle base, c'est-à-dire le choix d'une nouvelle base (commit parent) pour un arbre. Peut-être que le terme mercuriel pour cela est plus clair: ils l'appellent transplantation parce que c'est juste que: choisir un nouveau terrain (parent commit, root) pour un arbre.
Lorsque vous effectuez un rebase interactif, vous avez la possibilité de supprimer, sélectionner, modifier ou ignorer les commits que vous allez rebaser.
J'espère que c'était clair!
Commençons par l'exemple suivant:
Nous avons maintenant 3 options pour fusionner les modifications de la branche d'entité dans la branche principale :
Fusionner les validations
Gardera tous les historiques des
validations de la branche de fonctionnalité et les déplacera dans la branche principale
Ajoutera une validation factice supplémentaire.
Rebase and merge
Ajoute tous les historiques de
validation de la branche de fonctionnalité à l'avant de la branche master
N'ajoute PAS de validation fictive supplémentaire.
Squash and merge
regroupera toutes les validations de branche de fonctionnalité en une seule validation, puis les ajoutera à l'avant de la branche principale
ajoutera une validation factice supplémentaire.
Vous pouvez voir ci-dessous comment la branche principale s'occupera de chacun d'eux.
Dans tous les cas:
nous pouvons SUPPRIMER en toute sécurité la branche de fonctionnalité .
G
estc--d--e--f--g
écrasé ensemble?