How does Git work ? - For Integration

Comment fonctionne Git ?

Tout d'abord, notre code réside non pas dans 2, mais 4 endroits différents :

Endroit	Description
Espace de travail	Dossier courant de notre projet
Aire de Staging	Endroit temporaire où les changements de nos fichiers sont enregistrés
Dépôt local	Dépôt de nos changements validés uniquement présent sur notre ordinateur
Dépôt distant	Serveur (comme GitHub) pour partager et sauvegarder notre code

Déroulé

La plupart des commandes git déplacent notre code entre ces 4 endroits:

sequenceDiagram
participant A as Espace de travail
participant B as Aire de staging
participant C as Dépôt local
participant D as Dépôt distant
D->>C: git clone
C->>A: git checkout
A->>B: git add
B->>C: git commit
C->>D: git push
D->>A: git pull

git clone clone un répertoire distant en local, nous permettant de modifier ses fichiers dans notre espace de travail
git checkout bascule sur une autre branche ou restaure un espace de travail
git add ajoute le contenu des fichiers modifiés dans l'aire de staging en attendant leur validation
git commit enregistre les changements de l'aire de staging dans le dépôt local
git push envoie les changements locaux sur le dépôt distant
git pull récupère les changements du dépôt distant

La commande git pull est en réalité l'association de deux commandes : git fetch et git merge

flowchart LR
    id1[(Dépôt distant)]-- git pull-->id2(Espace de travail)
    id1[(Dépôt distant)]-- git fetch -->id3[(Dépôt local)]
    id3[(Dépôt local)]-- git merge -->id2(Espace de travail)

git fetch récupère les dernières mises à jour depuis le dépôt distant
git merge applique ces mises à jour au dépôt local

Git branching

L'intérêt de git réside dans son système de branche : un même dépôt peut contenir plusieurs versions d'un même code, cahcune résidant dans sa propre branche.

Les commandes git checkout (voir ci-dessus) et git switch permettent de naviguer entre ces branches.

flowchart LR
commit4-->commit1A-->commit2A~~~id2{{Branch A}}
commit1-->commit2-->commit3-->commit4-->commit5-->commit6~~~id1{{Main branch}}
commit2A-- git switch -->commit6
commit6-->commit2A

Pratiques

On rencontre courramment différents noms de branches, chacun correspondant à un environnement précis :

main ou master : production
develop : développement
feature : fonctionnalité qui sera fusionnée sur develop, puis sur main/master
hotfix : qui vise à corriger un souci sur la main/master
etc...

Conflits

Imaginons un cas dans lequel j'ai créé une branche depuis la develop, mais que celle-ci a évolué entretemps :

flowchart LR
    commit4-->commit1A-->commit2A~~~id2{{feature/ft-mafeature}}
    commit1-->commit2-->commit3-->commit4-->commit5-->commit6~~~id1{{develop}}

Pour fusionner ma branche et la redescendre dans develop, je vais devoir intégrer son historique dans ma branche avec un rebase ou un merge de develop dans ma branche, ce qui me donnera l'historique local suivant au niveau de ma feature :

flowchart LR
    commit4-->commit5-->commit6-->commit1A-->commit2A~~~id2{{feature/ft-mafeature}}

Je peux ensuite la fusionner dans develop, ce qui à terme donnera

flowchart LR
    commit4-->commit5-->commit6-->commit1A-->commit2A~~~id2{{develop}}

yostane / cours-archi-logicielle