Git 🌙
Chapters â–Ÿ 2nd Edition

3.1 Les branches avec Git - Les branches en bref

Presque tous les VCS proposent une certaine forme de gestion de branches. CrĂ©er une branche signifie diverger de la ligne principale de dĂ©veloppement et continuer Ă  travailler sans impacter cette ligne. Pour de nombreux VCS, il s’agit d’un processus coĂ»teux qui nĂ©cessite souvent la crĂ©ation d’une nouvelle copie du rĂ©pertoire de travail, ce qui peut prendre longtemps dans le cas de gros projets.

Certaines personnes considĂšrent le modĂšle de gestion de branches de Git comme ce qu’il a de plus remarquable et il offre sĂ»rement Ă  Git une place Ă  part au sein de la communautĂ© des VCS. En quoi est-il si spĂ©cial ? La maniĂšre dont Git gĂšre les branches est incroyablement lĂ©gĂšre et permet de rĂ©aliser les opĂ©rations sur les branches de maniĂšre quasi instantanĂ©e et, gĂ©nĂ©ralement, de basculer entre les branches aussi rapidement. À la diffĂ©rence de nombreux autres VCS, Git encourage des mĂ©thodes qui privilĂ©gient la crĂ©ation et la fusion frĂ©quentes de branches, jusqu’à plusieurs fois par jour. Bien comprendre et maĂźtriser cette fonctionnalitĂ© vous permettra de faire de Git un outil puissant et unique et peut totalement changer votre maniĂšre de dĂ©velopper.

Les branches en bref

Pour réellement comprendre la maniÚre dont Git gÚre les branches, nous devons revenir en arriÚre et examiner de plus prÚs comment Git stocke ses données.

Si vous vous souvenez bien du chapitre DĂ©marrage rapide, Git ne stocke pas ses donnĂ©es comme une sĂ©rie de modifications ou de diffĂ©rences successives mais plutĂŽt comme une sĂ©rie d’instantanĂ©s (appelĂ©s snapshots).

Lorsque vous faites un commit, Git stocke un objet commit qui contient un pointeur vers l’instantanĂ© (snapshot) du contenu que vous avez indexĂ©. Cet objet contient Ă©galement les noms et prĂ©noms de l’auteur, le message que vous avez renseignĂ© ainsi que des pointeurs vers le ou les commits qui prĂ©cĂšdent directement ce commit : aucun parent pour le commit initial, un parent pour un commit normal et de multiples parents pour un commit qui rĂ©sulte de la fusion d’une ou plusieurs branches.

Pour visualiser ce concept, supposons que vous avez un rĂ©pertoire contenant trois fichiers que vous indexez puis validez. L’indexation des fichiers calcule une empreinte (checksum) pour chacun (via la fonction de hachage SHA-1 mentionnĂ©e au chapitre DĂ©marrage rapide), stocke cette version du fichier dans le dĂ©pĂŽt Git (Git les nomme blobs) et ajoute cette empreinte Ă  la zone d’index (staging area) :

$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'

Lorsque vous crĂ©ez le commit en lançant la commande git commit, Git calcule l’empreinte de chaque sous-rĂ©pertoire (ici, seulement pour le rĂ©pertoire racine) et stocke ces objets de type arbre dans le dĂ©pĂŽt Git. Git crĂ©e alors un objet commit qui contient les mĂ©ta-donnĂ©es et un pointeur vers l’arbre de la racine du projet de maniĂšre Ă  pouvoir recrĂ©er l’instantanĂ© Ă  tout moment.

Votre dĂ©pĂŽt Git contient Ă  prĂ©sent cinq objets : un blob pour le contenu de chacun de vos trois fichiers, un arbre (tree) qui liste le contenu du rĂ©pertoire et spĂ©cifie quels noms de fichiers sont attachĂ©s Ă  quels blobs et enfin un objet commit portant le pointeur vers l’arbre de la racine ainsi que toutes les mĂ©ta-donnĂ©es attachĂ©es au commit.

Un commit et son arbre
Figure 9. Un commit et son arbre

Si vous faites des modifications et validez à nouveau, le prochain commit stocke un pointeur vers le commit le précédant immédiatement.

Commits et leurs parents
Figure 10. Commits et leurs parents

Une branche dans Git est simplement un pointeur lĂ©ger et dĂ©plaçable vers un de ces commits. La branche par dĂ©faut dans Git s’appelle master. Au fur et Ă  mesure des validations, la branche master pointe vers le dernier des commits rĂ©alisĂ©s. À chaque validation, le pointeur de la branche master avance automatiquement.

Note

La branche master n’est pas une branche spĂ©ciale. Elle est identique Ă  toutes les autres branches. La seule raison pour laquelle chaque dĂ©pĂŽt en a une est que la commande git init la crĂ©e par dĂ©faut et que la plupart des gens ne s’embĂȘtent pas Ă  la changer.
Une branche et l’historique de ses _commits_
Figure 11. Une branche et l’historique de ses commits

Créer une nouvelle branche

Que se passe-t-il si vous créez une nouvelle branche ? Eh bien, cela crée un nouveau pointeur pour vous. Supposons que vous créez une nouvelle branche nommée test. Vous utilisez pour cela la commande git branch : 

$ git branch testing

Cela crée un nouveau pointeur vers le commit courant.

Deux branches pointant vers la mĂȘme sĂ©rie de _commits_
Figure 12. Deux branches pointant vers la mĂȘme sĂ©rie de commits

Comment Git connaĂźt-il alors la branche sur laquelle vous vous trouvez ? Il conserve Ă  cet effet un pointeur spĂ©cial appelĂ© HEAD. Vous remarquez que sous cette appellation se cache un concept trĂšs diffĂ©rent de celui utilisĂ© dans les autres VCS tels que Subversion ou CVS. Dans Git, il s’agit simplement d’un pointeur sur la branche locale oĂč vous vous trouvez. Dans ce cas, vous vous trouvez toujours sur master. En effet, la commande git branch n’a fait que crĂ©er une nouvelle branche — elle n’a pas fait basculer la copie de travail vers cette branche.

HEAD pointant vers une branche
Figure 13. HEAD pointant vers une branche

Vous pouvez vĂ©rifier cela facilement grĂące Ă  la commande git log qui vous montre vers quoi les branches pointent. Il s’agit de l’option --decorate.

$ git log --oneline --decorate
f30ab (HEAD, master, test) add feature #32 - ability to add new
34ac2 fixed bug #ch1328 - stack overflow under certain conditions
98ca9 initial commit of my project

Vous pouvez voir les branches master et test qui se situent au niveau du commit f30ab.

Basculer entre les branches

Pour basculer sur une branche existante, il suffit de lancer la commande git checkout. Basculons sur la nouvelle branche testing :

$ git checkout testing

Cela déplace HEAD pour le faire pointer vers la branche testing.

HEAD pointe vers la branche courante
Figure 14. HEAD pointe vers la branche courante

Qu’est-ce que cela signifie ? Et bien, faisons une autre validation :

$ vim test.rb
$ git commit -a -m 'made a change'
La branche HEAD avance Ă  chaque _commit_
Figure 15. La branche HEAD avance Ă  chaque commit

C’est intĂ©ressant parce qu’à prĂ©sent, votre branche testing a avancĂ© tandis que la branche master pointe toujours sur le commit sur lequel vous Ă©tiez lorsque vous avez lancĂ© la commande git checkout pour changer de branche. Retournons sur la branche master :

$ git checkout master
Note
git log ne montre pas toutes les branches tout le temps

Si vous alliez lancer git log maintenant, vous pourriez vous demander oĂč se trouve la branche « testing » que vous avez tout juste crĂ©Ă©e, car elle n’apparaĂźt pas dans la sortie.

La branche n’a pas disparu ; Git ne sait juste pas que cette branche vous intĂ©resse et il essaie de vous montrer ce qu’il pense ĂȘtre le plus pertinent. Autrement dit, par dĂ©faut, git log ne montre que l’historique des commits sous la branche qui est extraite.

Pour montrer l’historique des commites de la branche dĂ©sirĂ©e, vous devez la spĂ©cifier explicitement : git log testing. Pour afficher toutes les branches, ajoutez l’option --all Ă  la commande git log.
HEAD est dĂ©placĂ© lors d’un _checkout_
Figure 16. HEAD est dĂ©placĂ© lors d’un checkout

Cette commande a rĂ©alisĂ© deux actions. Elle a remis le pointeur HEAD sur la branche master et elle a replacĂ© les fichiers de votre rĂ©pertoire de travail dans l’état du snapshot pointĂ© par master. Cela signifie aussi que les modifications que vous rĂ©alisez Ă  partir de ce point divergeront de l’ancienne version du projet. Cette commande annule les modifications rĂ©alisĂ©es dans la branche testing pour vous permettre de repartir dans une autre direction.

Note
Changer de branche modifie les fichiers dans votre répertoire de travail

Il est important de noter que lorsque vous changez de branche avec Git, les fichiers de votre rĂ©pertoire de travail sont modifiĂ©s. Si vous basculez vers une branche plus ancienne, votre rĂ©pertoire de travail sera remis dans l’état dans lequel il Ă©tait lors du dernier commit sur cette branche. Si git n’est pas en mesure d’effectuer cette action proprement, il ne vous laissera pas changer de branche.

Réalisons quelques autres modifications et validons à nouveau :

$ vim test.rb
$ git commit -a -m 'made other changes'

Maintenant, l’historique du projet a divergĂ© (voir Divergence d’historique). Vous avez crĂ©Ă© une branche et basculĂ© dessus, y avez rĂ©alisĂ© des modifications, puis vous avez rebasculĂ© sur la branche principale et rĂ©alisĂ© d’autres modifications. Ces deux modifications sont isolĂ©es dans des branches sĂ©parĂ©es : vous pouvez basculer d’une branche Ă  l’autre et les fusionner quand vous ĂȘtes prĂȘt. Et vous avez fait tout ceci avec de simples commandes : branch, checkout et commit.

Divergence d’historique
Figure 17. Divergence d’historique

Vous pouvez Ă©galement voir ceci grĂące Ă  la commande git log. La commande git log --oneline --decorate --graph --all va afficher l’historique de vos commits, affichant les endroits oĂč sont positionnĂ©s vos pointeurs de branche ainsi que la maniĂšre dont votre historique a divergĂ©.

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (test) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #ch1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

Parce qu’une branche Git n’est en fait qu’un simple fichier contenant les 40 caractĂšres de l’empreinte SHA-1 du commit sur lequel elle pointe, les branches ne coĂ»tent quasiment rien Ă  crĂ©er et Ă  dĂ©truire. CrĂ©er une branche est aussi simple et rapide qu’écrire 41 caractĂšres dans un fichier (40 caractĂšres plus un retour chariot).

C’est une diffĂ©rence de taille avec la maniĂšre dont la plupart des VCS gĂšrent les branches, qui implique de copier tous les fichiers du projet dans un second rĂ©pertoire. Cela peut durer plusieurs secondes ou mĂȘme quelques minutes selon la taille du projet, alors que pour Git, le processus est toujours instantanĂ©. De plus, comme nous enregistrons les parents quand nous validons les modifications, la dĂ©termination de l’ancĂȘtre commun appropriĂ© pour la fusion est rĂ©alisĂ©e automatiquement pour nous et est gĂ©nĂ©ralement une opĂ©ration trĂšs facile. Ces fonctionnalitĂ©s encouragent naturellement les dĂ©veloppeurs Ă  crĂ©er et utiliser souvent des branches.

Voyons pourquoi vous devriez en faire autant.

Note
CrĂ©er une branche et basculer dessus en mĂȘme temps

Il est habituel de crĂ©er une nouvelle branche et de vouloir basculer sur cette nouvelle branche en mĂȘme temps — ça peut ĂȘtre rĂ©alisĂ© en une seule opĂ©ration avec git checkout -b <nouvelle-branche>.
Note

Depuis Git version 2.23, on peut utiliser git switch au lieu de git checkout pour :

  • basculer sur une branche existante : git switch testing-branch,

  • crĂ©er une branche et basculer dessus ; git switch -c nouvelle-branche; le drapeau -c signifie crĂ©er, vous pouvez aussi utiliser le drapeau complet --create,

  • revenir sur votre branche prĂ©cĂ©demment extraite : git switch -.
scroll-to-top