Les workflows Git

Qu'est-ce qu'un workflow Git

Un workflow Git est un ensemble de conventions définies par une équipe sur la façon d'utiliser les branches, les commits et les merges pour collaborer sans se marcher dessus. Git lui-même n'impose rien — il vous fournit les outils mais ne dicte pas la façon de les utiliser. Un workflow comble ce vide en répondant à des questions pratiques : où vit le nouveau travail, comment est-il révisé et comment arrive-t-il en production.

Pourquoi c'est important

Sans workflow partagé, une équipe dérive rapidement vers le chaos : du travail inachevé sur la branche principale, des conflits de merge inattendus et des releases difficiles à reproduire. Un bon workflow maintient la branche principale dans un état publiable, fait de la révision une étape naturelle et donne à chacun le même modèle mental de l'avancement du code dans son parcours.

Le workflow centralisé

Le modèle le plus simple, et une bonne base pour comprendre les autres, est le workflow centralisé : tout le monde commit directement sur une seule branche partagée (généralement main). Il n'y a pas de branches de fonctionnalité — git pull et git push maintiennent chaque développeur synchronisé avec le dépôt central.

# Get the latest shared history before you start
git pull origin main

# ...make and commit your changes...
git add .
git commit -m "Add user profile page"

# Share your work; rebase on top of any new commits first
git pull --rebase origin main
git push origin main

C'est facile à comprendre mais ne passe pas bien à l'échelle : chaque commit atterrit sur la seule branche dont dépendent les coéquipiers, donc une modification inachevée peut tout casser. Les workflows ci-dessous résolvent tous ce problème en isolant le travail dans des branches d'abord.

Les workflows courants

Ces quatre approches s'appuient sur l'idée centralisée mais ajoutent de l'isolation. Chacune fait des compromis différents entre simplicité et structure :

Une feature branch en action

En pratique, la plupart des équipes commencent avec les feature branches car les commandes sont familières et l'isolation est immédiate. Le schéma est toujours le même : brancher depuis main, faire son travail, puis merger en retour.

# Create and switch to an isolated branch
git switch -c feature/login

# ...edit files, then stage and commit...
git add .
git commit -m "Add login form"

# Bring the finished work back into main
git switch main
git pull origin main          # make sure main is current
git merge feature/login       # integrate the feature
git push origin main

La branche maintient main dans un état publiable pendant que la fonctionnalité est à moitié terminée, et elle offre aux relecteurs un ensemble de commits autonomes à lire.

Les pull requests sur n'importe quel workflow

Sur les plateformes hébergées comme GitHub, GitLab ou Bitbucket, vous ne mergez généralement pas en local. À la place, vous poussez la branche et ouvrez une pull request (une « merge request » sur GitLab) : un endroit pour réviser le diff, exécuter la CI et discuter avant que le code n'atteigne main.

git switch -c feature/login
# ...commit work...
git push -u origin feature/login   # push branch, set upstream
# then open a pull request in the web UI

Les pull requests ne sont pas un workflow séparé — ce sont une porte de révision que vous pouvez superposer aux modèles feature branch, Gitflow, trunk-based ou forking.

Comment choisir

Commencez par le workflow le plus simple qui convient à votre situation et n'ajoutez de la structure que lorsque vous ressentez la douleur de ne pas en avoir.

• Une petite équipe livrant une application web en continu sera bien servie par l'approche feature branch ou trunk-based.
• Un produit avec des releases versionnées et planifiées bénéficie des branches de release et de hotfix explicites de Gitflow.
• Un projet open source accueillant des contributions d'inconnus a besoin du modèle forking, car les contributeurs n'ont pas d'accès en écriture au dépôt principal.

Ces workflows ne sont pas mutuellement exclusifs. De nombreuses équipes mélangent les idées — par exemple, utiliser des branches de fonctionnalité de courte durée avec un état d'esprit trunk-based, ou des pull requests par-dessus n'importe lequel d'entre eux.

Le fil conducteur commun

Chaque workflow ici repose sur les mêmes primitives que vous avez déjà apprises : git branch, git switch, git merge, git rebase et git push. Le workflow n'est qu'une convention superposée à ces commandes. Maîtrisez les commandes, convenez des conventions et la collaboration deviendra nettement plus fluide.

Pratique