Introduction pratique à git

Un dépôt git (repository) est un espace conservant l’ensemble d’un projet géré par git

Un dépôt est constitué de plusieurs zones :

initialiser un dépôt local (git init) ou

faire une copie d’un dépôt existant (git clone).

Chaque modification doit être indexée par git avant d’être enregistrée dans une nouvelle version du projet

Les commandes git add, git rm et git mv permettent d’enregistrer des modifications dans l’index

$ git add index.adoc

Un document peut être retiré de l’index avec la commande git restore --staged

$ git restore --staged index.adoc

La commande git status affiche l’état des documents

$ git status
Sur la branche main
Votre branche est en avance sur 'origin/main' de 1 commit.
  (utilisez "git push" pour publier vos commits locaux)

Modifications qui ne seront pas validées :
  (utilisez "git add <fichier>..." pour mettre à jour ce qui sera validé)
  (utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
        modifié :         index.adoc

aucune modification n a été ajoutée à la validation (utilisez "git add" ou "git commit -a")
$ git add index.adoc
$ git status
Sur la branche main
Votre branche est en avance sur 'origin/main' de 1 commit.
  (utilisez "git push" pour publier vos commits locaux)

Modifications qui seront validées :
  (utilisez "git restore --staged <fichier>..." pour désindexer)
        modifié :         index.adoc

L’option --short (ou -s) donne l’information de façon concise

$ git status -s
 M index.adoc

Sans option, les différences entre la copie de travail et l’index sont affichées

$ git diff index.adoc
diff --git i/index.adoc w/index.adoc
index a82de36..6f14e19 100644
--- i/index.adoc
+++ w/index.adoc
@@ -12,28 +12,30 @@ v2021.01.1,

 == Introduction
+** chaque copie d un dépôt `git` est elle-même un _dépôt_ qui peut être publié
 * Il a été créé par _Linus Torvalds_ pour le développement du noyau Linux
-* Chaque copie de travail est elle-même un _dépôt_ qui peut être publié
[...]
@@ -55,74 +57,145 @@ Après une étape de configuration
[...]

L’option --cached effectue la comparaison entre l’index et le dernier commit

$ git diff --cached index.adoc
diff --git c/index.adoc i/index.adoc
index a82de36..b307752 100644
--- c/index.adoc
+++ i/index.adoc
@@ -12,28 +12,30 @@ v2021.01.1,
[...]

Il est également possible de comparer une révision particulière avec la copie de travail, deux révisions, …​

La commande git commit valide les modifications de l’index et crée une nouvelle version (commit)

L’option -a permet de valider tous les changements des fichiers déjà suivis sans git add préalable

L’option --amend permet de modifier le dernier commit

$ git add index.adoc
$ git commit -m"Ajoute des exemples aux différentes sections" --amend
[main 9c72c80] Ajoute des exemples aux différentes sections
 Date: Thu Jan 28 13:27:18 2021 +0100
 1 file changed, 148 insertions(+), 34 deletions(-)

La commande git log liste l’ensemble des révisions enregistrées

$ git log
commit 9c72c80 (HEAD -> main)
Author: John Doe <john.doe@example.com>
Date:   Thu Jan 28 13:27:18 2021 +0100

    Ajoute des exemples aux différentes sections

commit 9b77d11
Author: John Doe <john.doe@example.com>
Date:   Thu Jan 28 11:00:12 2021 +0100

    Ignore les fichiers générés par asciidoctor
[...]

L’option -2 (ou -n avec n entier) limite aux n dernières

-p affiche également les différences

Le format de la sortie peut être adapté (--pretty=oneline, --pretty=format:"…​")

--graph montre le graphe des branches et des fusions

Certains fichiers ne doivent pas être suivis (résultat de la compilation, fichiers temporaires d’un éditeur, …​)

Un fichier .gitignore placé dans le projet (et dans le dépôt) permet de lister les fichiers et répertoires à ne pas suivre

Des exemples pour de nombreux types de projets sont disponibles

La commande git remote permet de gérer les références à un dépôt distant

# ajoute une référence origin vers un dépôt
$ git remote add origin https://github.com/libgit2/libgit2

# liste les références
$ git remote -v
origin        https://github.com/libgit2/libgit2 (fetch)
origin        https://github.com/libgit2/libgit2 (push)

git fetch récupère les révisions d’un autre dépôt

git pull récupère les révisions et les intègre

git push envoie les révisions locales vers une référence

$ git push origin main
Énumération des objets: 9, fait.
Décompte des objets: 100% (9/9), fait.
Compression par delta en utilisant jusqu'à 24 fils d'exécution
Compression des objets: 100% (5/5), fait.
Écriture des objets: 100% (6/6), 2.43 Kio | 2.43 Mio/s, fait.
Total 6 (delta 3), réutilisés 0 (delta 0), réutilisés du pack 0
remote: Resolving deltas: 100% (3/3), completed with 2 local objects.
To github.com:user/howto-git.git
   30fca42..9c72c80  main -> main

Une branche est une ligne de développement indépendante de la ligne principale mais qui partage le même historique

Une branche peut ensuite être fusionnée avec une autre afin d’y reporter les modifications

L’initialisation d’un dépôt crée une branche nommée master par convention

$ git init
$ [...] # ajouter quelques commits
$ git branch
* master

Création de la branche testing

$ git branch testing
$ git branch
* master
  testing
$ git log
commit 6c622f5 (HEAD -> master, testing)
[...]

Basculer sur la branche testing

$ git checkout testing
$ git branch
  master
* testing
$ git log
commit 6c622f5 (HEAD -> testing, master)
[...]

Création et bascule en une seule opération sur la branche testing

$ git checkout -b testing

Suppression de la branche testing

$ git branch -d testing

Fusionner testing avec master

* git checkout master
* git merge testing

Différentes stratégies de fusion peuvent être utilisées

Un tag est un marqueur qui fait référence à une révision particulière

Lister les tags

* git tag

Placer un tag sur la révision courante (HEAD)

* git tag -a v1.0 -m"Version 1.0"

Envoyer le tag v1.0 sur le dépôt origin

* git push origin v1.0

Envoyer tous les tags sur le dépôt origin

* git push origin --tags

Se positionner sur le tag v1.0

* git checkout -b version1 v1.0

Un workflow décrit un ensemble d’activités ainsi que la manière dont elles s’enchaînent, i.e.

C’est le workflow le plus simple et le plus proche de celui des VCS centralisés

Un dépôt fait référence

Tout se passe sur la branche principale (master)

Quand l’historique local est satisfaisant, il est publié sur le dépôt de référence

En cas de conflit, les modifications distantes sont reportées localement (rebase)

L’historique est toujours linéaire

Chaque développement se déroule sur une branche spécifique (feature branch)

La branche principale (master) ne contient que du code \og fiable\fg{}

Un dépôt fait référence

Les feature branches sont poussées sur le dépôt central

Quand les modifications sont satisfaisantes, la feature branch est fusionnée avec master

Il est possible d’utiliser les pull requests pour discuter d’une branche spécifique