Git

Késako ?

Git est un logiciel de versionning. Cela signifie qu'il conserve un historique des différentes versions de vos projets lors de leur évolution. Vous pouvez créer des snapshots de l'état d'un projet, et revenir à ces snapshots si besoin.

C'est également un moyen de partager de manière décentralisée, les différentes versions d'un même projet avec plusieurs personnes. Git offre la possibilité de télécharger des projets, les modifier en apportant vos propres snapshots d'évolution et même de fusionner ces snapshots avec les projets auxquels vous désirez participer.

Snapshots

Les snapshots sont appelés des commits pour git. C'est l'information du contenu des fichiers d'une architecture de dossiers (appelé repository pour git). Pour sauvegarder de l'espace de stockage, git stocke le contenu total du repository qu'une seule fois, pour chaque snapshot, il ne va stocker que l'information des modifications apportées relativement à la snapshot précédente, et ceux, pour chacun des fichiers. Les snapshots étaient liées entres elles telles des maillons d'une même chaîne.

Différents commits successifs ainsi que leur pointeur vers le commit précédent pour reconstruire l'état d'un projet (repository)

Il existe alors un pointeur sur chaque snapshot, vers la snapshot précédente. Pour identifier une snapshot précise, git génère une signature pour celle-ci, générée à l'aide de l'algorithme de hashage SHA-1 de 40 caractères de long que l'on utilise sur le contenu de chaque fichier et sur l'information de la structure de fichiers du repository. Le hash n'est alors pas unique mais il existe tellement de combinaisons possibles qu'il est une signature suffisamment efficace pour identifier un unique commit (une snapshot) au sein d'un projet. Le hash se compose de la somme des hashs des fichiers modifiés ainsi que du tree, l'architecture de fichiers. Les modifications d'un fichier donné est stocké dans un fichier appelé un blob.

Les blobs sont les modifications de chacun des fichiers. Dans cet exemple, il y a 3 blobs, donc 3 fichiers modifiés. Tree est porteur de l'information de la position de chacun de ses fichiers dans le repo. Le commit représente ces changements.

Les différents commits sont stockés dans le dossier .git à la racine du repository. Il existe un pointeur appelé HEAD qui indique sur quel commit on se trouve. On peut aller à un commit précédent en déplaçant ce pointeur HEAD, annuler des commits, etc..

Branches

Nous avons vu que les snapshots sont liées entres elles telles des maillons d'une même chaîne. Une snapshot dépend de sa précédente pour connaître l'état des fichiers du repository, puisque la snapshot en elle même, ne stocke que l'information des modifications relativement à la snapshot précédente. Et bien vous pouvez vous séparer de cette chaîne principale en créant une nouvelle branche.

Il y a 3 commits et deux branches (master et testing) qui partagent le même commit le plus récent. Le pointeur HEAD est actuellement sur la branche master.

Vous pourrez alors construire votre propre série de snapshots (commits) et construire une suite alternative à la chaîne de commits. Ca permet à plusieurs développeurs de travailler ensemble sur un même projet, sans se marcher sur les pieds.

Chacune des deux branches a effectué un commit.

Vous pourrez ensuite appliquer les changements effectués sur votre branche à la branche principale du projet. Si le projet a été modifié entre temps, alors la signature de son dernier commit ne sera pas présent dans votre chaîne de commits. Il y aura alors des conflits. C'est tout à fait normal et vous serez alors amené à prendre des décisions sur quel changement conserver, celui de la branche principale, ou bien celui de votre branche. C'est un ajustement manuel. Pour éviter de passer trop de temps à régler ce genre de conflits, il est souvent plus simple de ne pas travailler tous en même temps sur les mêmes fichiers. Une telle fusion s'appelle un merge pour git.

Merge d'une branche secondaire sur la branche principal du repository.

Vous pouvez également rebase votre branche. En effet, vous avez vu que vous créé une branche divergente de la branche initial sur une snapshot donnée. Cependant, la branche principale est amenée à évoluer de son côté, comme l'illustre les images précédentes. Si vous ne souhaitez pas modifier la branche principale mais simplement mettre à jour la votre avec les nouvelles modifications de la branche principale, vous pouvez rebase votre branche pour qu'elle ne prenne plus racine sur la snapshot sur laquelle elle a été créée mais sur le dernier commit de la branche principale. Le rebase est fort utile lorsque vous souhaitez maintenir à jour une fork d'un projet publique par exemple.

Voici l'état d'une branche topic avant un rebase :

Les lettres représentent des commits. Il y a une branche topic de la branche principale master.

Voici l'état de cette branche topic après un rebase sur master :

A', B' et C' ne sont pas les mêmes commits que A, B et C. Ils ont été recréé, avec comme racine, le dernier commit de la branche master. Si il y a des conflits générés par les commits F et G, alors il faudra évidemment les régler manuellement.

Commandes

• Initialisation

Emplacement de votre token pour synchroniser votre compte GitHub a votre CLI Git.

#Initialiser notre identité (ajoutez --global pour tous les repositories)
git config user.name "Hubert Bonisseur de La Bath"
git config user.email "[email protected]"
#Sauvegarder vos identifiants pour les prochains push (sans --global si uniquement sur le repo courant)
git config --global credential.helper wincred
#Initialiser un repository
git init

• Gestion des commits

#Stage des fichiers (ou tous les fichiers du repo avec ".")
git add .
git add <file1> <file2> <file3> ...
#Commit (faire une nouvelle snapshot sur la branche courante avec les modifications staged)
git commit -m "message de description du commit"
#Revenir à la dernière version commit d'un fichier (si non staged)
git checkout <commit_id>
#Pareil mais sur une branche spécifiée
git checkout -b <branch_name> <commit_id>
#Créer un nouveau commit qui annule les changements des n derniers commits
git revert HEAD~<n>
#Annuler les n derniers commits et remet le pointeur sur le n-1 dernier commit
git reset HEAD~<n>

• Repository distants

#Lier un repository distant à notre repository local
git remote add <remote_name (generally "origin")> <repo_url>
#Lister le repository distant
git remote -v
#Télécharger un repository distant
git clone <repo_url>
#Upload les changements sur un repository distant
git push
#En cas de conflits, écraser avec notre version (-f ou --force)
git push -f
#Appliquer les commits d'un repository distant sur notre repository local
git pull

• Gestion de branches

#Lister toutes les branches
git branch -a
#Créer une nouvelle branche
git branch <branch_name>
#Se déplacer sur une branche
git switch <branch_name>
#Fusionner une branche A sur une branche B (utiliser -f ou --force pour forcer un merge en écrasant les données conflictuelles de la branche cible)
git switch <B>
git merge <A>
#Déplacer la base de la branche A sur la branche B (modifie alors nos commits)
git rebase <B> <A>
#Visualiser les branches et les commits successifs de manière jouuulie
git log --oneline --decorate --graph --all

• Obtenir de l'aide

#Un flag --help existe pour toutes les commandes de git
git --help
git branch --help
git remote --help
#etc..

Voici un super lien pour apprendre de nouvelles commandes et consolider votre maîtrise de celles ci-dessus de manière ludique et surtout très visuelle :

Learn Git Branchinglearngitbranching.js.org