C'est une notion difficile à appréhender. J'ai eu des doutes sur mon explication, je vais voir si je peux faire mieux ;).

Concrètement, avec le schéma sous les yeux, voici cela comme un déplacement du point d'origine de la branche.

Exemple: tu as créé ta branche à partir du commit numéro 5, entre temps un collègue a fait 2 commits, disons les numéros 7 et 8. Tu décides d'intégrer ces changements, avec le git rebase tu dis à git de déplacer l'origine de ta branche du commit 5 au commit 8. Les deux commits de ton collègues apparaissent donc comme antérieur à la branche.

Ces changements sont pris en compte par git dans ton code. S'il y a des conflits, tu dois merger proprement à la main ces derniers.

Merci pour ton retour, je vais tenter d'améliorer ça ce soir!

Ce qui peut-être aider à comprendre, c'est le cas où l'on ne fait pas de rebase. Le rebase permet d'avoir un historique à plat, mais il demande un peu plus de technicité de la part des développeurs. L'alternative au rebase, c'est de faire un merge commit. C'est ce que fait Git par défaut. Après un merge, git crée un merge commit qui indique que deux branches ont fusionnés. Si cela peut-être utile par moment pour montrer qu'on a fusionné deux branches très importantes et que cela doit rester dans l'histoire du projet, néanmoins, et c'est un avis personnel, lorsqu'on utilise souvent des branches pour développer une fonctionnalité, avoir de nombreux merge commit peut brouiller l'historique du projet. Je n'ai pas envie de voir des merge commit tout les 10 commits.

Si tu lis l'anglais, voici un article qui explique bien ce point là : http://www.bitsnbites.eu/?p=221