Quelle est la différence entre git merge
et git rebase
?
Supposons à l’origine qu’il y ait 3 commits, A
, B
, C
:
Ensuite, le développeur Dan a créé commit D
, et le développeur Ed a créé E
:
De toute évidence, ce conflit devrait être résolu d’une manière ou d’une autre. Pour cela, il y a 2 façons:
FUSION :
Les deux commits D
et E
sont toujours là, mais nous créons un commit de fusion M
qui hérite des changements de D
et E
Cependant, cela crée une forme de diamant , que beaucoup de gens trouvent très déroutant.
REBASE :
Nous créons commit R
, dont le contenu réel est identique à celui de merge commit M
ci-dessus. Mais, nous nous débarrassons du commit E
, comme il n’a jamais existé (désigné par des points – ligne de fuite). A cause de cette oblitération, E
devrait être local pour le développeur Ed et ne devrait jamais avoir été poussé vers un autre référentiel. L’avantage de rebase est que la forme du diamant est évitée et que l’histoire rest en ligne droite – la plupart des développeurs aiment ça!
J’aime vraiment cet extrait de 10 choses que je déteste à propos de git (cela donne une brève explication de rebase dans son deuxième exemple):
3. Documentation délirante
Les pages de manuel en sont une toute puissante “f *** you” 1 . Ils décrivent les commandes du sharepoint vue d’un informaticien et non d’un utilisateur. Par exemple:
git-push – Update remote refs along with associated objects
Voici une description pour les humains:
git-push – Upload changes from your local repository into a remote repository
Mise à jour, autre exemple: (merci cgd)
git-rebase – Forward-port local commits to the updated upstream head
Traduction:
git-rebase – Sequentially regenerate a series of commits so they can be applied directly to the head node
Et puis nous avons
git-merge - Join two or more development histories together
qui est une bonne description.
1. non censuré dans l’original
Personnellement, je ne trouve pas la technique de création de diagrammes standard très utile – les flèches semblent toujours me tromper. (Ils pointent généralement vers le “parent” de chaque commit, ce qui finit par être un retour en arrière, ce qui est étrange).
Pour l’expliquer en mots:
Pour des raisons que je ne comprends pas, les outils d’interface graphique pour Git n’ont jamais fait beaucoup d’efforts pour présenter les historiques de fusion plus proprement, en faisant abstraction des fusions individuelles. Donc, si vous voulez un “historique propre”, vous devez utiliser rebase.
Il me semble avoir lu des articles de blog de programmeurs qui n’utilisent que rebase et d’autres qui n’utilisent jamais de rebase.
Je vais essayer d’expliquer cela avec un exemple de mots justes. Disons que d’autres personnes de votre projet travaillent sur l’interface utilisateur et que vous écrivez de la documentation. Sans rebase, votre historique pourrait ressembler à ceci:
Write tutorial Merge remote-tracking branch 'origin/master' into fixdocs Bigger buttons Drop down list Extend README Merge remote-tracking branch 'origin/master' into fixdocs Make window larger Fix a mistake in howto.md
C’est-à-dire que les fusions et l’interface utilisateur sont validées au milieu de vos validations de documentation.
Si vous rebasiez votre code sur master au lieu de le fusionner, cela ressemblerait à ceci:
Write tutorial Extend README Fix a mistake in howto.md Bigger buttons Drop down list Make window larger
Tous vos commits sont en haut (les plus récents), suivis du rest de la twig principale.
( Déni de responsabilité: je suis l’auteur du message “10 choses que je déteste à propos de Git” mentionné dans une autre réponse )
Bien que la réponse acceptée et la plus votée soit excellente, je trouve également utile d’essayer d’expliquer la différence uniquement par des mots:
fusionner
rebase
résumé: Si possible, rebase est presque toujours meilleur. Faciliter la réintégration dans la twig principale.
Car? Work votre travail de fonctionnalité peut être présenté sous la forme d’ un gros «fichier de patch» (aka diff) par rapport à la twig principale, sans avoir à «expliquer» plusieurs parents: au moins deux, provenant d’une fusion, mais probablement beaucoup plus, s’il y en a étaient plusieurs fusions. Contrairement aux fusions, les rebases multiples ne s’additionnent pas. (un autre gros plus)
Git rebase est plus proche d’une fusion. La différence de rebase est la suivante:
Cela signifie donc que tous vos commits locaux sont déplacés à la fin, après tous les commits à distance. Si vous avez un conflit de fusion, vous devez également le résoudre.
Pour comprendre facilement peut voir ma figure.
Rebase va changer le hash de commit, donc si vous voulez éviter beaucoup de conflits, utilisez simplement rebase lorsque cette twig est terminée / complète en tant que stable.