Il arrive parfois que je pense être sur une branche au moment d’en créer une autre. Dans mon exemple je pensais être sur la branche master lorsque j’ai créé ma branche fix/#42. Bien évidemment je m’aperçois de mon erreur après avoir effectué les commits f1 et f2. Je réalise alors que je dois déplacer ma branche et donc je pense tout de suite à utiliser rebase. Sauf que, rappelle-toi, la syntaxe que je viens de te montrer calcule implicitement un intervalle de commits entre deux branches, ce qui va me poser problème ici, puisque si je fais un git rebase master fix/#42, c’est toute la série de commits d1, d2, f1 et f2 qui serait rejouée sur master, alors que je ne veux que f1 et f2, donc depuis dev exclue.

Je vais donc faire un git rebase --onto master dev fix/#42. master indique la nouvelle base, j'aurais aussi pu utiliser directement c3. Le second argument indique la borne ouvrante exclue, donc dev mais j’aurais aussi pu mettre d2. Et le dernier argument désigne la branche à déplacer, donc fix/#42.

On est d’accord, la syntaxe laisse à désirer. Personnellement j’aimerais des options explicites par argument, par exemple git rebase --onto master --from-excluded dev --to fix/#42. Ça serait long, mais au moins on lèverait l’ambiguïté des bornes incluses ou exclues. 

Pour en revenir à mon exemple, une fois que j’ai saisi ma commande, mon rebase démarre comme à l’accoutumée en plaçant HEAD en tête détachée sur la nouvelle base. Les commits f1 et f2 sont rejoués. L’étiquette de branche est déplacée, ce qui déréférence les commits f1 et f2 initiaux. Et pour finir HEAD est repositionné sur la branche.

Je viens de faire une translation de branche en une ligne, c’est plutôt classe, tu ne trouves pas ?