Git est un logiciel de gestion de versions distribué. Créé par Linus Torvalds pour la gestion des sources de Linux, il s’est imposé face à ses concurrents et est aujourd"hui l’outil de gestion de versions le plus utilisé.

Dans Git, le code source des projets est stocké sur la machine de chaque personne travaillant sur le projet et sur des dépots distants nommés "remote".

Chaque modification est stockée sous la forme d’un "commit", qui correspond à l’état de votre projet à un instant T (vous pouvez retrouver plus d’informations sur le fonctionnement bas niveau de Git dans la documentation).

Poussons maintenant notre travail sur un dépôt distant. Par exemple, créez un projet sur Github (ou Gitlab, bitbucket…​)

Ici, je vais créer par exemple un projet nommé "test1" sur mon compte Github. Une fois le projet créé, je vais l’ajouter en tant que "remote" sur mon projet:

Je crée ici un remote appelé origin. La commande git remote (qui supporte une option -v pour avoir plus d’informations`) vous permet de lister les remotes de votre projet.

Poussons maintenant notre code sur ce remote:

Ici, nous poussons notre état local sur le dépôt "origin" et sur la branche "master". L’option -u nous permet d’indiquer à Git que notre branche "master" locale correspond à notre branche "master" distante.

Mais qu’est ce qu’une branche ?

La commande git branch permet de lister vos branches. Seulement "master" existe pour l’instant.
Créons une nouvelle branche appelée "my-feature" avec git branch my-feature. Votre nouvelle branche est créée.

Les branches permettent de travailler en isolation de la branche principale de votre projet. Vous pouvez, comme sur master, créer des commits, push vos modifications sur une branche distante…​ sans risquer de tout casser. Pour cela, vous devez commencer par vous "déplacer" sur votre branche nouvellement créée.

La comande git checkout permet cela. Ici, git checkout my-feature vous positionnera sur votre nouvelle branche dans votre projet local. Vous pouvez vérifier cela avec git status ou git branch à tout moment si vous avez un doute sur le positionnement de votre projet.

Note: la commande git checkout -b <nom_de_branche> permet de faire les deux actions précédentes en une commande.

Une branche est tout simplement un pointeur sur un commit. Dans notre cas, nous venons de créer notre branche, et donc nos branches "master" et "my-feature" pointent sur notre seul et unique commit.

Créons maintenant un nouveau fichier et puis commitons le dans notre branche:

Si vous exécutez git log, vous verrez votre nouveau commit. Comme dit précédemment, la branche "master" n’a pas bougée, mais la branche "my-feature" pointe maintenant sur ce nouveau commit.

Vous pouvez maintenant pousser sur votre dépôt distant votre nouveau commit et votre branche avec git push -u origin my-feature.

Nous allons maintenant ajouter le travail que nous avons fait sur la branche "my-feature" sur la branche master. Si vous utilisez un outil comme Github, cela peut être fait via l’interface de Pull Request. Ici, nous le ferons en ligne de commande.

Retournons sur la branche "master" avec git checkout master, et importons notre commit de la branche my-feature:

Vous pouvez voir avec git log que le commit de notre branche a été rajouté à master.

La mention de Fast-forward indique que Git s’est contenté d’appliquer le commit de la branche "my-feature" au dessus de "master". Cela est possible car le travail était linéaire. Notre branche "master" n’avait pas bougée, et le commit de la branche "feature" (dont la source était master) a simplement été rajouté par Git sur "master":

Cela serait différent dans ce cas là:

A ce moment, Git va créer un nouveau commit, appelé commit de merge (et vous demander d’écrire son message).

En effet, la branche "master" a changée depuis le moment de la création de "fix-bug", et dans ce cas Git crée un nouveau commit (qui est la combinaisons de plusieurs commits) pour pouvoir merger votre branche.

Nous reparlerons de tout cela dans un prochain article qui sera dédié aux commandes git avancées (il existe des techniques pour éviter cela si vous le voulez).

A noter que lorsqu’une branche est mergée, elle existe toujours et pointe toujours sur son dernier commit. Si vous voulez la supprimer, vous pouvez le faire avec git branch -D <nom>.

Git a été conçu pour que plusieurs personnes puissent travailler sur le même projet.

La commande git pull <remote> <branche> permet de récupérer l’état d’un dépôt distant sur votre machine local. La commande git pull est en fait la combinaison de deux actions:

Un tag est seulement une étiquette ajoutée à un commit pour qu’il puisse être référencé de façon plus simple par un humain.

La commande git tag <nom> permet de créer un tag.

Il est également possible d’utiliser git tag -a <nom> pour créer un tag avec plus d’informations, comme son auteur ou un message de commit.

Il est possible, comme pour une branche ou pour un hash de commit, de se déplacer sur le commit référencé par un tag en utilisant git checkout <tag>. Cela est pratique si vous voulez vérifier l’état de votre travail sur un tag spécifique.

Vous voudrez parfois que certains fichiers ou dossiers ne soient pas visibles par Git, c’est à dire qu’ils ne puissent jamais être ajoutés à l’index et donc commités.

Cela est contrôlé par le fichier .gitignore, qu’il faut créer à la racine de votre projet. Si vous ajoutez par exemple la valeur my-file dans ce fichier, les fichiers nommés my-file présents dans votre projet seront invisibles pour Git.

Il existe d’autres "patterns" pour ignorer des répertoire, ou bien faire de la négation. Vous pouvez retrouver plus de détails sur ces options dans la documentation de Git.

Cette fonctionnalité est par exemple utile si vous avez besoin d’avoir des fichiers de configurations spécifiques, ou des mots de passes…​ à configurer dans votre projet local.

Nous avons vu ici rapidement comment fonctionne Git. Dans l’article suivant, j’expliquerai des notions avancées et comment se sortir de situations difficiles.

je pense que la chose la plus importante à comprendre dans Git est le fait que l’on travaille avec des commits, et que nous avons des moyens de référencer ces commits (branches, tags…​).

Nous verrons dans l’article suivant qu’il est possible de jouer avec ces commits et ses références pour faire des choses intéressantes dessus.