Module 1 : Versioning et collaboration avec Git & GitHub

Module 1 Module 1

Le versioning

Définition

Un système de gestion de versions (VCS) :

  • enregistre l’historique des modifications d’un projet,
  • permet de revenir à un état antérieur,
  • permet à plusieurs personnes de travailler sur le même projet.

Centralisé vs distribué

  • Centralisé (SVN) : un seul dépôt sur un serveur, pas de travail hors ligne.
  • Distribué (Git) : chaque poste possède une copie complète du dépôt (historique inclus).

Git : les trois zones

Working directory --git add--> Index (staging) --git commit--> Dépôt local

Les trois zones de Git Les trois zones de Git Working directory → Index → Dépôt local → Remote, selon la commande utilisée.

  • Working directory : les fichiers tels qu’édités,
  • Index : ce qui sera inclus dans le prochain commit,
  • Dépôt : l’historique des commits (.git).

Le commit

  • un instantané (snapshot) du projet,
  • identifié par un hash unique (ex. a3f9c2e),
  • pointe vers son commit parent → l’ensemble forme un historique.

Branche et HEAD

  • Branche : un pointeur mobile vers un commit (main par défaut),
  • HEAD : pointe vers la branche courante,
  • créer une branche est instantané.
A---B---C            main
         \
          D---E      feature/dns   <- HEAD

Commandes essentielles

Commande Rôle
git init créer un dépôt
git status état du dépôt
git add <fichier> ajouter à l’index
git commit -m "message" créer un commit
git log --oneline --graph historique
git switch -c <branche> créer une branche et basculer dessus
git merge <branche> fusionner une branche dans la courante

Annuler des modifications

Situation Commande
Fichier modifié, pas indexé git restore <fichier>
Fichier indexé git restore --staged <fichier>
Corriger le dernier commit (local) git commit --amend
Annuler un commit en gardant l’historique git revert <hash>
Revenir en arrière en réécrivant l’historique git reset --soft | --mixed | --hard <hash>

Attention : git reset --hard supprime les modifications non commitées. Sur un commit déjà poussé, utiliser git revert.

Fusionner : merge et rebase

  • Merge fast-forward : la branche cible n’a pas avancé, le pointeur se déplace.
  • Merge 3-way : les branches ont divergé, un commit de fusion est créé.
  • Rebase : rejoue les commits d’une branche au-dessus d’une autre → historique linéaire, mais réécrit les hashes.
git switch feature
git rebase main

Attention : ne jamais rebaser des commits déjà poussés. Règle : rebase en local, merge en partagé.

Merge vs Rebase Merge vs Rebase Fast-forward, 3-way merge et rebase : trois façons différentes d’intégrer une branche, avec des conséquences différentes sur l’historique.

Conflits

Un conflit survient quand deux branches modifient les mêmes lignes :

<<<<<<< HEAD
adresse actuelle
=======
adresse proposée
>>>>>>> feature

Résolution : éditer le fichier, supprimer les marqueurs, puis git add + git commit (ou git rebase --continue).

Dépôts distants

  • remote : dépôt distant référencé par un nom,
  • origin : remote créé par défaut lors d’un git clone,
  • upstream : dépôt d’origine d’un fork,
  • fork : copie personnelle d’un dépôt sur GitHub.
Commande Effet
git clone <url> copier un dépôt distant
git fetch télécharger les nouveautés sans modifier les fichiers
git pull fetch + merge
git push envoyer les commits vers le remote

Authentification : HTTPS + token (PAT) ou SSH (recommandé).

Bonnes pratiques

Commits atomiques

Un commit = un changement logique. Convention Conventional Commits :

<type>(<portée>): <description>

Types : feat, fix, docs, refactor, test, chore.

Tags et versionnement sémantique

Format MAJOR.MINOR.PATCH (v1.4.2) :

  • MAJOR : changement incompatible,
  • MINOR : nouvelle fonctionnalité,
  • PATCH : correction.
git tag -a v1.0.0 -m "Première version stable"

.gitignore et secrets

  • .gitignore : fichiers non suivis par Git (.env, *.bak, …),
  • jamais de mot de passe ou de clé dans un dépôt : Git conserve tout l’historique.

Attention : un secret poussé est considéré comme compromis, même supprimé ensuite. Il doit être révoqué.

Stratégies de branching

Stratégie Principe
GitHub Flow main toujours déployable, branches courtes, Pull Requests
GitFlow main, develop, feature/*, release/*, hotfix/*
Trunk-based commits fréquents sur main, branches très courtes

Stratégies de branching Stratégies de branching GitHub Flow, GitFlow et Trunk-based : trois organisations de branches différentes selon le besoin de l’équipe.

Collaboration sur GitHub

Issues

Représente une tâche, un bug ou une idée : labels, assignés, milestone. Écrire Closes #12 dans un commit ferme l’issue à la fusion.

Pull Request (PR)

Demande de fusion d’une branche avec discussion et revue.

Mode de fusion Résultat
Merge commit conserve tous les commits
Squash and merge un seul commit résumé
Rebase and merge historique linéaire

Revue de code

  • Approve / Request changes,
  • CODEOWNERS désigne les relecteurs par fichier :
# .github/CODEOWNERS
/configs/firewall/   @equipe-securite

Protection de branches

Règles empêchant les mauvaises pratiques sur une branche sensible (main) :

Règle Effet
Require a pull request interdit le push direct
Required approvals nombre minimal de relecteurs
Require status checks la CI doit réussir
Require linear history interdit les commits de fusion
Require signed commits commits vérifiés uniquement
Block force pushes / deletions protège l’historique

Secret scanning / push protection : GitHub détecte et bloque les secrets dans un dépôt.

Cycle de vie d’une PR sur branche protégée Cycle de vie d’une PR sur branche protégée De la création de branche au merge : chaque porte (revue, status checks, règles de protection) doit être franchie ; un push direct sur main est refusé.

À retenir

  • Git est distribué : chaque clone contient tout l’historique.
  • Un commit est un instantané ; une branche est un pointeur.
  • Rebase en local, merge en partagé ; revert plutôt que reset sur ce qui est poussé.
  • Sur GitHub : issues + Pull Requests, sur une branche main protégée.