IT Toolbox AI
CI/CD · Git et branches

Git et stratégies de branches

Organisez des changements courts et relisibles avec commits, branches, reviews, merges et tags.

Leçon disponible
20 min

Objectifs

  • Comprendre repository, commit, branch, merge, pull request, tag et conflict.
  • Lire les commandes Git courantes d’un changement local.
  • Comparer trunk-based development, feature branches et Git Flow.
  • Expliquer le risque des branches trop longues.

Git et stratégies de branches

Git fournit l’historique sur lequel la CI s’appuie. Une branche isole temporairement un changement ; une pull request ou merge request ouvre la revue, déclenche les tests et prépare le merge.

Un tag nomme un commit, souvent pour identifier une version. Un conflict apparaît lorsque Git ne peut pas combiner automatiquement des changements concurrents et exige une résolution humaine relue.

Un changement pédagogique

Ces commandes illustrent le cycle local. Elles sont affichées uniquement : les tests du parcours ne créent aucune branche, aucun commit et aucun push.

Inspecter l’état
git status
git branch
Créer une branche
git switch -c feature/login
Préparer et enregistrer le changement
git add .
git commit -m "feat: add login"
Publier selon la configuration du dépôt
git push
Lire l’historique et les tags
git log --oneline
git tag

Avant git add ., vérifiez git status pour ne pas inclure de secret, fichier local ou changement sans rapport. N’exécutez git push que vers un dépôt autorisé.

De la feature vers main

Une branche courte facilite la revue et réduit la distance avec main. Les protections de branche peuvent exiger une review et des tests réussis avant le merge.

  • Un commit cohérent facilite la revue et le diagnostic.
  • Une review détecte erreurs, secrets exposés et changements trop larges.
  • Les tests automatiques complètent la review sans la remplacer.
  • Le merge intègre le changement validé dans la branche cible.
Flux de validation
feature
   ↓
review
   ↓
tests
   ↓
merge
   ↓
main

Choisir une stratégie adaptée

Trunk-based development privilégie de très petites intégrations fréquentes vers une branche principale, éventuellement protégées par des feature flags. Les feature branches isolent un changement pendant sa revue. Git Flow ajoute des branches structurées comme develop, release et hotfix.

Aucune stratégie n’est universellement meilleure. Une équipe choisit selon sa taille, son rythme de livraison, ses contraintes réglementaires et sa capacité à tester rapidement.

  • Trunk-based : intégrations très fréquentes et branches très courtes.
  • Feature branches : isolation claire, mais risque de divergence si elles durent.
  • Git Flow : cycles de releases formalisés, avec davantage de branches et de merges.
  • Une branche longue accumule les écarts avec main et augmente les conflits et l’intégration tardive.

Mini résumé

  • Repository, commits et branches donnent une histoire vérifiable aux changements.
  • Review, tests et protections précèdent le merge vers une branche importante.
  • Trunk-based, feature branches et Git Flow répondent à des contextes différents.
  • Les branches courtes limitent la divergence et les conflits.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Quel est le rôle principal d’une pull ou merge request ?
2. Pourquoi une branche très longue augmente-t-elle le risque ?
3. Quelle stratégie de branches faut-il choisir ?