Git distribué signifie que chaque développeur possède une copie complète du projet. Pour que ces copies restent synchronisées, il faut un dépôt distant (remote) et un workflow partagé. Ce module couvre en six leçons la gestion des remotes, les modèles de collaboration, les pull requests, une convention de messages de commit vérifiée en CI, les stratégies de branches et la maintenance d'un projet.
Ce que vous allez apprendre : du solo à l'équipe
Section intitulée « Ce que vous allez apprendre : du solo à l'équipe »Quand vous travaillez seul, add puis commit suffit. Dès qu'une
deuxième personne rejoint le projet, de nouvelles questions
apparaissent, et chacune trouve sa réponse dans une leçon du module.
Le tableau les relie, dans l'ordre où le parcours les traite :
| Question | Réponse dans ce module |
|---|---|
| Comment envoyer mon travail au serveur ? | git push et les remotes |
| Comment récupérer le travail des autres ? | git fetch, git pull |
| Qui intègre le travail de qui ? | Workflows distribués (centralisé, intégrateur, dictateur) |
| Comment proposer des modifications pour revue ? | Pull requests / merge requests |
| Comment écrire des messages que toute l'équipe et les outils comprennent ? | Conventional Commits, vérifiés par commitlint et en CI |
| Comment organiser les branches de l'équipe ? | Workflows (Feature Branch, Gitflow, Trunk-Based) |
| Comment maintenir un projet et publier une version ? | Patches, releases, changelogs |
Le fil du module
Section intitulée « Le fil du module »Tout part de la synchronisation.
Remotes fondamentaux
installe le cycle complet : ajouter un remote, distinguer fetch de
pull, pousser avec push. Sans ce geste maîtrisé, aucune des leçons
suivantes ne tient.
Vient ensuite la question de l'organisation. Workflows distribués présente les modèles de collaboration que permet un outil distribué : dépôt central partagé, gestionnaire d'intégration qui récupère les contributions, dictateur et lieutenants pour les très gros projets.
Pull requests et code review détaille le geste quotidien de ces modèles : proposer une branche, la faire relire, discuter, puis fusionner. La leçon recommande déjà des titres au format conventionnel et introduit la fusion en squash, ce qui amène naturellement la leçon suivante.
Conventional Commits normalise
les messages de commit de l'équipe, type(portée): description, et les
fait vérifier par commitlint, sur le poste avec un hook puis dans le
pipeline CI de chaque merge request. C'est aussi cette convention qui
permet de générer le changelog automatiquement, geste repris dans la
dernière leçon du module.
Workflows Git tranche
ensuite entre les stratégies de branches : Feature Branch, Gitflow ou
Trunk-Based, avec leurs forces, leurs faiblesses et le contexte où chacune
s'impose. Enfin,
Maintenir un projet
se place côté mainteneur : accepter des patches avec git am,
préparer une release, et tirer le changelog des commits écrits au
format Conventional Commits.
À retenir
Section intitulée « À retenir »- Un remote est juste une URL vers un autre dépôt Git,
originest le remote par défaut après ungit clone git fetchtélécharge sans modifier votre branche locale,git pullfait fetch + merge (ou rebase)- Les pull requests ne sont pas une fonctionnalité Git mais un outil de plateforme (GitHub, GitLab), le concept reste le même
- Des messages au format Conventional Commits, vérifiés en CI, rendent l'historique lisible et alimentent changelog et versions
- Choisissez votre workflow selon la taille de l'équipe et la fréquence de release, Trunk-Based pour le déploiement continu, Gitflow pour les releases planifiées
- Ne jamais force push sur une branche partagée sans coordination