Les commits et les branches

Comme nous l’avons vu à la partie 2 et à la partie 3, Git enregistre les modifications qui surviennent au code dans le dépôt sous forme de commits.

Au fil des commits, nous construisons donc un historique des nos modifications. Git nous permet de naviguer entre ces modifications et donc de retrouver les états antérieurs des sources dans notre dépôt. Nous allons aujourd’hui détailler les possibilités offertes par cette organisation des commits.

Nous nous positionnons dans un dépôt Git contenant actuellement deux fichiers.

Le dépôt Git a connu 4 commits, comme nous l’indique la commande git log.

La commande git status nous précise quant à elle qu’aucun travail n’est en cours.

Affichons le dernier fichier modifié pour la suite de l’article.

Nous allons maintenant tenter de retrouver un état antérieur de notre dépôt, à savoir l’état de notre dépôt au précédent commit.

La commande git checkout va nous permettre de revenir à l’état de notre dépôt à un certain commit. Nous pouvons utiliser pour ça un nombre de commits antérieurs, par exemple juste 1 commit avant :

Nous pouvons également utiliser l’identifiant du commit.

La sortie de Git est un peu difficile à comprendre tout de suite, mais le fait est que nous sommes revenus à l’état du dépôt à l’avant-dernier commit.

Affichons le dernier fichier que nous avons modifié.

Son contenu a bien changé, nous sommes donc bien revenus en arrière dans l’histoire des modifications de notre dépôt.

Un composant important de la commande git précédente reste assez obscure : que signifie HEAD ? Et pourquoi ~1 ?

Il s’agit tout simplement d’un pointeur de position parmi les commits de notre dépôt. Un pointeur est ici un repère logique, un petit drapeau au sein de Git, qui indique un commit et que l’on peut déplacer pour indiquer un autre commit.

Un schéma va nous aider à comprendre. Nous identifions les commits par les 4 derniers caractères de leurs identifiants.

Avant notre checkout, HEAD pointait sur le dernier commit réalisé. Après le git checkout HEAD~1, nous avons positionné HEAD sur l’avant-dernier commit.

Nous entrons dans un mode spécial de Git (detached head ou tête détachée), qui nous permet de retrouver les données du dépôt telles qu’elles étaient au moment de ce commit. À partir de cet état du dépôt, nous pourrons évoluer vers un autre état sans modifier les commits déjà existants.

Nous allons maintenant observer les différences entre le commit sur lequel nous sommes positionnés et le commit le plus avancé que nous avons écrit, à l’aide de la commande git diff.

Nous voyons bien la ligne ajoutée au fichier file2 lors du dernier commit.

Remarquons que nous avons utilisé dans notre commande master, avec HEAD. Ici HEAD point sur l’avant-dernier commit de notre liste. Nous voyons les différences entre l’avant-dernier et le dernier commit. Or le dernier argument de notre ligne de commande était master. Il s’agit donc aussi, comme HEAD, d’un pointeur, mais sur le dernier commit réalisé. Nous y reviendrons.

Cette commande git diff marche bien sûr avec n’importe quel identifiant de commit, par exemple voici la différence entre le premier et le second commit, en utilisant ici leur identifiant unique.

Les différences entre le premier et le second commit apparaissent bien.

Nous sommes donc positionnés sur l’avant-dernier commit. Nous nous apercevons que nous aimerions continuer avec un contenu différent que celui enregistré dans le dernier commit, sans toutefois effacer ce dernier commit. Pour résumer nous voulons créer un embranchement dans l’histoire de nos commits pour créer une suite différente. Nous allons donc créer notre première branche.

Pour cela il suffit de relire le dernier message affichée lors de notre commande git checkout HEAD~1 :

Nous allons donc passer la commande suivante afin de créer une nouvelle branche dans laquelle nous écrirons la nouvelle suite des modifications que nous souhaitons.

Remarquons la première ligne On branch new-file alors que jusqu’ici nous avions On branch master. Nous avons donc bien créé une nouvelle branche nommée new-file.

Nous créons maintenant un nouveau commit contenant un nouveau fichier et l’ajoutons au dépôt.

Où en sommes-nous ? Un schéma vaut mieux qu’un long discours.

Ce schéma nous apprend beaucoup de choses :

Une branche est donc définie par une série de commits et un pointeur du nom de cette branche sur le dernier commit de cette branche.

Arrêtons-nous là pour l’instant. Nous avons vu une notion fondamentale, à savoir ce qu’est rééllement une branche Git et les principes sous-jacents à une branche, le lien entre les commits et les pointeurs. Il était malheureusement difficile de parler des branches précisément (ce que nous avions fait dans notre première partie) sans toutes ces notions.

Dans un dépôt Git, l’unité est le commit, qui est un ensemble de modifications survenus sur le code dans ce dépôt. Un commit et ses prédecesseurs représentent une branche. On positionne sur certains commits des pointeurs, ayant chacun un rôle distinct :

Nous verrons dans une prochaine partie comment les branches interagissent entre elles et comment les utiliser pour multiplier les différentes versions d’un travail en cours.