Atelier technique Primtux : GIT

Atelier technique : GIT

Créé par Linus Torvald en 2005 pour le noyau Linux
Décentralisé
Basé sur Unix : tout est fichier

Atelier technique : GIT > les bases

Unité : Commit = instantanée de code + hash + date + auteur
Pointeur = mettre le curseur sur un commit à la fois
Tag = nom sur un Commit
Branche = liste de commits qui se suivent + nom. Le pointeur sera toujours mis sur le dernier commit.
Le fichier = la matière manipulée

Atelier technique : GIT > avantages techniques

Partage de sources
Décentralisé : travaille à plusieurs
Conserver un historique des modifications
Gérer une application au format Semver
Performance : peu de latence, peu gourmand en ressources et occupation mémoire faible
Avoir un fonctionnement standardisé

Atelier technique : GIT > la base

On peut voir le fonctionnement de git comme 4 espaces distincts.
Par analogie, on peut représenter ça par le monde du transport :

Le Working Directoryreprésente l'espace de stockage avec des fichiers classés tel que le serais un grand entrepôt.
Le Staging Area représente un camion en cours d'affraitement. On sélectionne les fichiers pour constituer un commit.
Une fois que l'on est satisfait, on peut créer un commit : c'est l'équivalent de plomber un camion.
La zone ou les commits sont en attentes d'être déployé s'appelle le Local Repository.
Enfin, on pousse sur un serveur distant, appelé Remote.

Pour passer d'un espace à un autre, on utilise les commandes listés. 80% des opérations git ne concerne que ce passage.

Atelier technique : GIT > merge

git switch main

git merge feature/decouverte

Atelier technique : GIT > merge

git switch main

git merge feature/decouverte

Atelier technique : GIT > rebase

git switch main

git rebase feature/decouverte

Atelier technique : GIT > conflit

Proposition A

Proposition B

Atelier technique : GIT > conflit avec merge

Quand on opère un git merge sur des branches avec des conflits, git nous demandera de les résoudres.

Dans cet exemple, imaginons :

un conflit sur le fichier A pour le commit 5
un conflit sur le fichier B pour le commit 6
un conflit sur le fichier C pour le commit 7

Dans le cadre du merge, git demandera de résoudre les 3 conflits en une fois.
Une fois résolus, il créera un commit de merge (N°8) porteur de la résolution des conflits.

Gros avantages : si pour une raison x (souvent une mauvaise résolution des conflits), vous souhaitez revenir en arrière, il est tout à fait possible de supprimer le commit 8 et donc de revenir dans l'état précédent le git merge.

Un conflit pour 3 commits
= 1 opération de résolution

Atelier technique : GIT > conflit avec rebase

Regardons ensemble la même situation mais pour la commande git rebase.

Git ne va pas du tout se comporter de la même façon.

Il va d'abord essayer d'intégrer le commit 5 et va identifier le conflit sur le fichier A.
Après résolution, il créera le commit 8 qui contiendra les changements du commit 5 ainsi que la résolution de conflit sur le fichier A.

Git continuera sur l'intégration du commit 6 avec le même fonctionnement.

Conclusion : Le résultat sera un historique linéaire (donc plus lisible) mais :

Nous aurons 3 opérations de conflits à résoudre les un derrière les autres. C'est beaucoup plus long que via un git merge
Les commits créé seront tous porteurs de leur résolution de conflit respectives. Il sera donc beaucoup plus délicat de revenir en arrière.

Un conflit pour 3 commits
= 3 opérations de résolution

Atelier technique : GIT > pull

Que fait la commande : git pull ?

Atelier technique : GIT > pull

git pull = git fetch + git merge
ou
git pull = git fetch + git rebase

Atelier technique : GIT > avant pull (config merge)

Atelier technique : GIT > pull (config merge)

Atelier technique : GIT > workflow

Définition Workflow: flux de travail, flux opérationnel

Intérêt :

Éviter les bugs
Éviter les conflits
Éviter des interactions chronophages
Gagner du temps et de l'assurance
Identifier les bugs et les résoudres

Atelier technique : GIT > workflow web

Dans le cadre d'une application en ligne, l'objectif est la continuité de service.

Pour celà, la branche main est protégé : interdiction de pousser des modifications directement dessus.

Les nouvelles fonctionnalités sont encadrés dans des branches dédiés (feature/nom).

Une branche de release permet d'avoir un espace de recette ou l'on inclus des fonctionnalités.

Quand la recette est démaré, on n'autorise plus de nouvelles fonctionnalités mais uniquement des correctifs.
Ces derniers sont effectués via des branches bugfix/nom

Une fois la recette concluante, on peut envisager la fusion (merge request = demande de fusion sur gitlab)

Tous les correctifs sur la production sont quant à eux des branches hotfix/nom

Atelier technique : GIT > workflow applicatif

Atelier technique : GIT > conseils

Utiliser git en ligne de commande
Ne pas utiliser les git rebase (sauf pour les git pull sur les branches protégées)
Ne jamais rien supprimer sur gitlab
Éviter de travailler en detach head
Créer son propre git.config
Utiliser un shell comme fish avec Starship
S'entrainer sur des plateformes comme https://learngitbranching.js.org
Ne plus jamais recloner un projet pour résoudre un soucis

Atelier technique : GIT > allez plus loin

Un futur atelier sur les commandes : git add, git restore, git reset, git revert, git stash, cherry-pick, etc.
Eviter les conflits en séparant les sources en petits fichiers
Gestion des conflits
git bisect
gitlab avancés : regarder des diffs, naviguez sur un historique, faire des squash etc.
La gestion de projets sous gitlab
Les hooks de git
La CI/CD avec gitlab
git LFS : et si on stockait des fichiers avec de gros volumes ?
?

Atelier technique : GIT > The end ?

Les sources de cet atelier sont sur La Forge des Communs Numériques Éducatifs

Fait avec :

Une version custom de revealjs
Des graphiques sous draw.io
D'autres graphiques sous Inskcape
Un éditeur de code : Visual Studio Code
Une distrib Ubuntu qui va bientôt être remplacé par une Mint (un jour, peut-être NixOS)
Git et gitlab, bien sur 😉