Git merge ou rebase

Bonjour,

La question est intéressante et je vais tenter de faire de mon mieux pour vous donner une bonne réponse.
Donc, au début, vous avez une branche 'B', qui démarre à un point 'P' (normalement, la dernière version du master).
Le merge prend les modifications de la branche 'B' pour les remettre dans le master. Cela veut dire, que chaque commit effectué sur 'B', sera appliqué sur le master. Evidemment, il peut y avoir des conflits et la personne à l'origine de l'action de merge devra les résoudre.

Le rebase ne fait pas de merge à proprement parler. C'est-à-dire que vous allez devoir faire un merge après votre rebase. De plus, le rebase réécrit l'historique de la branche, ce qui pour certain, est le mal.
Donc, toujours le même cas, vous avez fait une branche 'B', qui démarre à un point 'P'. Vous faites vos modifications. Les commits peuvent être un peu "brouillon". Par exemple : commit 1 -> la fonctionnalité en question commit 2 -> fix typo, commit 3 -> oubli d'une virgule ;). Ce n'est pas super propre, dans le sens on se fout de garder les commit 2 et 3 dans l'historique. Ce ne sont que des trucs mineurs. Dans ce cas, vous allez faire un rebase sur les trois derniers commits, pour les fusionner en un seul commit tout beau.
Aussi, un deuxième avantage, c'est que le rebase, peut permettre de déplacer l'origine de votre branche. La branche 'B' démarre du point 'P', mais depuis, il y a eu énormément de modification sur master. Vous faites un rebase pour placer votre branche 'B' à la fin de master (et non plus depuis le point 'P'). Ainsi, c'est vous (l'auteur de la branche) qui doit gérer la fusion. Ensuite, vous pouvez faire le merge vers master et, comme votre branche est à jour, vous (ou l'auteur du dépôt qui fait les merge) n'allez pas avoir de conflit.
Pour ce second avantage, on pourrait me dire : il fallait refaire un merge master -> branche 'B'. C'est une autre solution en effet.