Publication de la FAQ Git

Hello à tous,

D'abord merci pour cet excellent et considérable travail. La rubrique Git en a bien besoin, car elle est toujours enterrée sous la « hiérarchie » historique des forums et reste peu visible.

Par contre, désolé d'intervenir deux ans après la parution de de cette FAQ mais je tique sur la section consacrée à rebase : « Réécriture de l’historique (rebase) ».

git rebase sert à « rebaser » une branche, c'est-à-dire en changer la base, soit encore : la décrocher de son emplacement courant pour la repositionner ailleurs. La plupart du temps, on s'en sert pour repositionner le travail d'une branche de développement qui a duré un peu trop longtemps vers l'état actuel du produit sur lequel on travaille et poursuivre tranquillement. Par contre, ça ne sert pas du tout à ré-écrire l'historique en soi, surtout qu'il n'est pas du tout recommandé de ré-écrire l'historique sans motif valable (ça l'est, bien sûr, pour préparer une branche propre avant de la soumettre pour intégration définitive).

Il se trouve que rebase est très utile et que rebase -i l'est encore plus : c'est le genre de petite amélioration que l'on apporte à un concept existant et qui en révolutionne tellement l'usage que ça change l'approche de l'outil entier. Il y a beaucoup de gens qui utilisent — à raison — cette fonction pour « rebaser une branche au même endroit », ce qui est conceptuellement un non-sens mais qui est utile uniquement pour les effets de bord du mode interactif : pouvoir à la fois sélectionner les commits qui nous intéressent (dont faire du cherry-picking), en exclure d'autre et amender les dernier, le tout en une seule opération.

Par contre, non seulement ce n'est pas l'objet de la chose et la ré-écriture n'est pas encouragée en dehors de ses propres branches privées, mais il y a des pièges à éviter lorsque l'on utilise rebase, en particulier si la branche concernée contient des merge points : si on le fait sans précaution, Git va essayer de retrouver tous les commits qu'il peut atteindre et les réappliquer linéairement, sur une seule branche, sans préserver la structure initiale ! Et comme cela va pratiquement toujours provoquer des conflits, l'utilisateur va se retrouver avec un dépôt sans dessus-dessous et une opération interrompue avant la fin.

Il existe par ailleurs des commandes dédiées à ce genre d'opération, telles que filter-branch qui, elle, sert officiellement à ça :
Code:

1 2 3 4 $ git --help -a … filter-branch Réécrire les branches …
C'est intéressant également car git rebase est très largement représenté dans les questions des utilisateurs, beaucoup plus que la normale attendue, au point qu'on se demande parfois où ils veulent en venir. Son utilisation pour ré-écrire l'historique est déjà une explication, le fait de le voir officiellement présenté comme servant à cette fin dans une FAQ confirme que la confusion est fréquente (et que donc, cela devrait justement devenir une entrée de FAQ également).

On le trouve parfois utilisé, également, lorsque quelqu'un veut faire officiellement démarrer un nom de branche à un nouvel endroit déjà identifié. Au lieu de faire un branch --force ou un checkout -B, on a vu des solutions utilisant rebase, également. Et je pense que ceci est dû à des habitudes prises dans d'autres SCM qui gèrent les branches différemment et dans lesquels il n'est pas possible de s'en sortir autrement.

Du coup, je serais bien intéressé d'avoir l'opinion de l'entourage à ce sujet en particulier. Pour l'instant, je poste ici pour faire remonter la discussion et la signaler aux personnes directement concernées mais au besoin, on déplacera le fil vers une discussion dédiée.

Merci à tous.