Ce qui ' la différence entre ' git merge ' et ' git rebase ' ?

Question

Je suis en train de comprendre... Quelle est la différence entre et ?

Answer 1

Supposons qu'à l'origine il y avait 3 s'engage, A,B,C:

Puis développeur Dan créé commettre D, et le développeur Ed créé commettre E:

Évidemment, ce conflit devrait être résolu d'une certaine manière. Pour cela, il existe 2 façons:

FUSION:

Les deux s'engage D et E sont toujours là, mais nous créons de fusion s'engager M qui hérite changements des deux D et E. Cependant, cela crée de diamant de forme, qui beaucoup de gens trouvent très déroutant.

REBASE:

Nous créons commettre R, laquelle le contenu du fichier est identique à celle de fusion de commettre M - dessus. Mais, nous nous débarrassons de commettre E, comme il n'a jamais existé (indiqué par des points - ligne de fuite). En raison de cet effacement, E devraient être locale développeur Ed et n'aurait jamais été poussé à un autre référentiel. L'avantage de cela est que le diamant de forme est évitée, et l'histoire reste belle ligne droite, la plupart des développeurs de l'amour!

Answer 2

Personnellement, je ne trouve pas que la norme de création de diagrammes technique très utile - les flèches semblent toujours point le mauvais sens pour moi. (Généralement, ils pointent en direction de la "mère" de chaque commit, qui finit par se reculer dans le temps, ce qui est bizarre).

Pour l'expliquer en mots:

• Lorsque vous rebase votre direction sur leur branche, vous indiquer à Git pour le faire paraître comme si vous avez vérifié leur branche proprement, puis fait tout votre travail à partir de là. Cela fait un nettoyage, d'un concept simple paquet de changements que quelqu'un peut l'examen. Vous pouvez répéter ce processus à nouveau quand il y a de nouveaux changements sur leur branche, et vous vous retrouvez toujours avec un ensemble de modifications "à la pointe" de leur branche.
• Lorsque vous fusionnez leur branche dans votre branche, vous attachez les deux direction de leurs histoires à ce point. Si vous faites cela plus tard avec plus de changements, de commencer à créer un entrelacé fil de l'histoire: certains de leurs changements, certains de mes changements, certains de leurs changements. Certaines personnes trouvent cette malpropre ou indésirables.

Pour des raisons que je ne comprends pas, d'outils graphiques pour Git n'ont jamais fait beaucoup d'efforts pour présenter une fusion des histoires plus proprement, dans l'abstraction de l'individu se confond. Donc, si vous voulez un "nettoyage" de l'histoire, vous devez utiliser rebase.

Je me souviens avoir lu des messages de blog à partir de programmeurs qui seulement utiliser rebase et d'autres qui ne jamais utiliser de rebase.

(Disclaimer: je suis l'auteur de "10 choses que je déteste au sujet de Git" post appelé dans une autre réponse)

Answer 3

J'aime vraiment ce à l'exception de 10 Choses que je déteste au sujet de git (il donne une courte explication pour rebase dans sa deuxième exemple):

3. Merde documentation

Les pages man sont un tout-puissant "fuck you". Ils décrivent les commandes à partir du point de vue d'un chercheur en informatique, et non à un utilisateur. Affaire au point:

git-push – Update remote refs along with associated objects

Voici une description de l'homme:

git-push – Upload changes from your local repository into a remote repository

Mise à jour, un 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

ce qui est une bonne description.