Git avancé : flux de travail et versions

Un flux de travail (workflow) fixe comment une équipe utilise les branches, les fusions et les versions. Il n’en existe pas de meilleur en soi : le choix dépend de la taille de l’équipe, du rythme de livraison et des tests.

Les principaux flux

Flux	Principe	Convient à
Trunk-based	Tout le monde intègre souvent (au moins chaque jour) dans main ; branches très courtes	Équipes avec bons tests et déploiement continu
Branches de fonctionnalité (feature branches)	Une branche par fonctionnalité, fusionnée par demande de fusion	La plupart des équipes
GitFlow	Branches develop, release/*, hotfix/* en plus de main	Logiciels livrés en versions numérotées, plusieurs versions maintenues
Fork + demande de fusion	Chaque contributeur travaille sur sa copie du dépôt	Projets ouverts aux contributions externes

Pour un petit projet ou une équipe réduite : branches de fonctionnalité courtes + demandes de fusion + main toujours déployable.

Branches de fonctionnalité

git switch main
git pull --ff-only
git switch -c feat/formulaire-contact

# travail, commits atomiques
git push -u origin feat/formulaire-contact
# ouvrir la demande de fusion sur le serveur

Règles :

• Courte durée (quelques jours) et petite taille : plus simple à relire et à fusionner.
• Nom explicite : feat/…, fix/…, docs/…, chore/… (même vocabulaire que Conventional Commits).
• Rebaser régulièrement sur main (Rebase et historique).
• Supprimer la branche après fusion.

git branch -d feat/formulaire-contact              # locale (refuse si non fusionnée)
git push origin --delete feat/formulaire-contact   # distante
git fetch --prune                                   # nettoyer les références distantes disparues
git config --global fetch.prune true
git branch --merged main                            # branches déjà fusionnées (supprimables)

Demandes de fusion

Une demande de fusion (pull request, merge request) propose d’intégrer une branche, avec relecture et vérifications automatiques (Gitea Actions : écrire un workflow).

Une bonne demande :

Élément	Contenu
Titre	Au format du projet (feat(portée): description)
Description	Pourquoi (contexte, ticket), quoi (résumé), comment tester
Taille	Moins de 400 lignes modifiées si possible
État	Tests verts, analyse et formatage passés
Relecteur	Au moins une personne autre que l’auteur

Pour relire : git fetch origin pull/12/head:pr-12 (selon la plateforme), ou récupérer la branche et la lire localement.

Branches protégées

Sur le serveur (Gitea : dépôts, accès et API, Paramètres du dépôt > Branches) :

Règle	Effet
Interdire les poussées directes sur main	Tout passe par une demande de fusion
Exiger des vérifications réussies	Tests, analyse, formatage
Exiger une approbation	Relecture obligatoire
Interdire les poussées forcées	Protège l’historique
Exiger un historique linéaire	Fusion par rebase ou squash seulement
Interdire la suppression de la branche	Protection contre l’accident

Un hook local (voir Husky : pre-push et tests) est un confort ; la protection du serveur fait autorité.

Étiquettes et versions

Une étiquette (tag) marque un commit précis, typiquement une version publiée.

git tag                                   # liste
git tag -a v1.4.0 -m "version 1.4.0"      # étiquette ANNOTÉE (recommandée) : auteur, date, message
git tag v1.4.0-rc1                        # étiquette légère
git tag -a v1.3.0 a1b2c3d -m "..."        # sur un ancien commit
git show v1.4.0
git push origin v1.4.0                    # les étiquettes ne sont PAS poussées automatiquement
git push origin --tags
git tag -d v1.4.0                         # suppression locale
git push origin --delete v1.4.0           # suppression distante
git checkout v1.4.0                       # explorer une version (HEAD détaché)
git tag -s v1.4.0 -m "..."                # étiquette SIGNÉE (voir « Sécurité et configuration »)

Versionnement sémantique

Format MAJEUR.MINEUR.CORRECTIF (SemVer) :

Numéro	Incrémenté quand
MAJEUR	Changement incompatible de l’interface
MINEUR	Fonctionnalité ajoutée sans casser l’existant
CORRECTIF	Correction de bogue compatible

Les types Conventional Commits s’y rattachent : fix → correctif, feat → mineur, ! ou BREAKING CHANGE: → majeur. Des outils (release-please, semantic-release, standard-version) calculent la version et le journal des modifications à partir des messages.

git log v1.3.0..v1.4.0 --pretty=format:'- %s (%h)' --no-merges          # notes de version brutes
git describe --tags --abbrev=0                                           # dernière version

Versions et maintenance

git switch -c release/1.4 v1.4.0                  # branche de maintenance d'une version
git cherry-pick -x a1b2c3d                         # reporter une correction de main
git tag -a v1.4.1 -m "correctif 1.4.1"

Pour plusieurs versions maintenues en parallèle, une branche release/x.y par version ; corriger d’abord sur main, puis reporter (cherry-pick -x).

git worktree : plusieurs branches en même temps

git worktree add ../projet-correctif fix/urgent        # nouveau dossier, branche existante
git worktree add -b feat/essai ../projet-essai main     # crée la branche et le dossier
git worktree list
git worktree remove ../projet-correctif
git worktree prune

Chaque worktree est un dossier de travail distinct relié au même dépôt : on corrige un bogue urgent sans mettre de côté (stash) le travail en cours, on teste une branche en parallèle, on lance un long build pendant qu’on continue ailleurs. Une branche ne peut être extraite que dans un seul worktree à la fois.

Conventions à documenter

Créer un CONTRIBUTING.md qui précise :

• le flux choisi (branches, fusion, rebase ou non) ;
• le format des messages (Conventional Commits) et des noms de branches ;
• les vérifications avant demande de fusion (npm run verifier) ;
• la politique de versions (SemVer, étiquettes, journal des modifications) ;
• qui fusionne et quand ;
• comment signaler un problème de sécurité.

Une équipe qui s’accorde sur peu de règles simples, rappelées par des hooks (Husky : installation) et vérifiées par la CI, perd moins de temps qu’une équipe qui a un flux sophistiqué mal appliqué.

Monodépôt ou plusieurs dépôts

	Monodépôt	Plusieurs dépôts
Changements transversaux	Un seul commit atomique	Plusieurs demandes coordonnées
Partage de code	Direct	Paquets versionnés
Taille	Peut devenir grande (voir Gros dépôts et sous-projets)	Chaque dépôt reste petit
Droits d’accès	Plus grossiers	Par dépôt
Intégration continue	Doit cibler les dossiers modifiés	Simple, par dépôt

Dépannage

Symptôme	Piste
Branche très divergente de main	Rebaser plus souvent, fusionner plus tôt, découper
main cassée après une fusion	Exiger des vérifications avant fusion (branche protégée) ; git revert du commit de fusion
Étiquette non visible sur le serveur	git push origin <étiquette> (non poussée automatiquement)
Étiquette à déplacer	Éviter : en publier une nouvelle version ; sinon git tag -f puis git push --force origin <étiquette> (casse les clones)
fatal: '<branche>' is already checked out at …	Branche extraite dans un autre worktree
Beaucoup de branches mortes	git fetch --prune, git branch --merged
Les numéros de version se trompent	Automatiser avec les messages de commit (outil de release)

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune propre à Ubuntu. git worktree et les options décrites existent dans les versions de Git des deux Ubuntu.

Pour aller plus loin

• Versionnement sémantique, Gestion des branches (Pro Git)
• Suite : Gros dépôts et sous-projets

Dans la même rubrique

• Rebase et réécriture de l’historique
• Reflog et récupération
• Fusion et conflits
• Recherche et diagnostic
• Flux de travail et versions
• Gros dépôts et sous-projets
• Sécurité et configuration