Git est un outil de suivi de version distribué.

Les informations définies dans la configuration globale sont stockées dans le fichier ~.gitconfig. Ce sont les valeur par défaut pour l'ensemble des dépots git créés. Pour chaque dépot il est possible de redéfinir ces valeurs.

Par clonage d'un dépot existant, ou par initialisation. Créer d'abord le dossier puis initialiser le depot dans le dossier.

$ mkdir test-git
$ cd test-git/
$ git init
Initialized empty Git repository in /tmp/test-git/.git/

Dans l'idéal, La branche principale (master) comporte les états stables du projet. Pour ajouter des fonctionnalités, créer une branche, travailler dans la branche et lorsque la fonctionnalité est implémentée et le code stable, fusionner sur la branche master.

Pour afficher la branche courante:

$ git branch 
  experimental
* master

Ici deux branches existent: master et experiemental, nous nous trouvons sur la branche master.

Changer de branche

$ git checkout experimental 
Switched to branch 'experimental'

La branche courante est à présent experimental. Les prochains commits se feront sur cette branche.

La commade checkout et le commutateur -b permettent la création et le changement de branche en une seule commande.

$ git checkout -b bug
Switched to a new branch 'bug'

Après invocation de cette commande, la branche bug est créée et l'utilisateur est placé sous la branche bug. Il peut maintenant apporter les modifications nécessaires sur les fichiers sources.

La commande git status donne un récapitulatif de l'état courant, elle liste notamment:

• Les fichiers présents dans l'index, prêts à être commités (archivés dans le dépôt).
• Les fichiers existants dans le dépôt, ayant subis des modifications dans l'espace de travail mais non présents dans l'index (liste not updated).
• Les fichiers existants dans l'espace de travail, n'ayant jamais été commités et donc qi ne sont pas encore suivis par le système de gestion de versions (liste untracked).

$ git status
# On branch experimental
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   licence.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   doc/index.htm
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       src/hello.c

Dans l'exemple ci-dessus git status nous informe que nous sommes sur la branche experimental, que le fichier ./licence.txt est dans l'index, il fera donc parti du prochain commit. Le fichier doc/index.htm présent dans notre espace de travail a été modifié, il diffère de celui présent dans le dépot. Un fichier src/hello.c est présent dans l'espace de travail mais n'a jamais été commité.

git diff permet de visualiser les modifications apportées sur un fichier en comparant le fichier de l'espace de travail avec la version disponible dans le dépot:

$ git diff path/to/file.c

Ceci permet de comparer le fichier présent dans l'espace de travail et celui présent dans le dépot git.

L'index est une zone d'assemblage (staging area). Seuls les fichiers présents dans l'index seront envoyés sur le dépot lors du commit. Pour ajouter un fichier dans l'index:

$ git add path/to/file.c

Pour placer dans l'index tous les fichiers de l'espace de travail modifiés mais déjà suivis par git:

git add --update

Cette commande ajoute seulement à l'index les fichiers déja commités mais ayant subit des modification depuis le dernier commit. Ils sont ainsi prêts à être historisés à nouveau.

Certains fichiers ou dossiers n'ont pas besion d'être suivis, il peuvent être systèmatiquement ignorés par la commande add(par exemple les logs). Pour cela créer à la racine du projet un fichier ./.gitignore contenant la liste des fichiers et dossiers à ignorer.

L'opération de commit placera les fichiers de l'index (staging area) dans le dépot. Les fichiers en cours de modification dans l'espace de travail ne seront pas automatiquemnt placés dans le dépot même s'ils ont déjà été commités auparavant! Il faut bien penser à placer tous les fichiers que l'on souhaite envoyer sur le dépot dans la staging area à l'aide de la commande git add.

$ git commit

La commande précédente affichera l'éditeur permettant de saisir le message d'accompagnement du commit. Une fois validé, les fichiers sont historisés, une nouvelle révision est enregistrée dans le dépot.

Le modificateur -a permet de placer automatiquement les fichiers modifiés de l'espace de travail dans l'index et de lancer le commit. Attention cependant les nouveaux fichiers (untraked) ne seront pas ajoutés.

$ git commit -a

Une fois un état stable atteint et le commit réalisé, les modifications peuvent être rapportées sur la branche principale (master):

$ git checkout master
$ git merge bug

Ici on se place sur la brache master et on fusionne les modifications apportées dans la branche bug sur la branche master. Lors de la fusion des conflits peuvent se révélés. Dans ce cas le processus de fusion automatique est arrêté. La commande git status permet de lister les fichiers en conflit, il faut:

• Editer les fichiers pour régler les conflits,
• Ajouter les fichiers dans la zone d'assemblage (l'index),
• Terminer la fusion avec la commande git commit.

Une fois la branche fusionnée sur la brache master, si aucune autre modification ne doit avoir lieu, elle peut être supprimée:

$ git branch -d bug 
Deleted branch bug (was a0431c3).

Ici la branche bug ayant été fusionnée sur master et les corrections du bug apportées, elle n'a plus de raison d'être, elle est donc supprimée.

git log --graph --oneline --all