Que sont les « Gitflows » ?

GitLab flow, Gitflow, GitHub flow, Trunk‑based flow…

Il y en a une bonne poignée. Ce ne sont que des manières standardisées d’utiliser Git, comme des frameworks… mais pour Git.

Si vous avez déjà travaillé en équipe, quelqu’un a sûrement fini par imposer « un truc » pour éviter que tout le monde pousse directement sur main. Cette personne (affectueusement surnommée le « gitmaster ») a expliqué quand créer une branche, comment la mettre à jour, quand la fusionner… en s’inspirant d’un de ces modèles.

D’abord, parlons des commits

Avant de disséquer les modèles de branches, alignons-nous sur ce qu’est un commit. Ce n’est pas un « instantané » complet de votre dépôt – ce serait affreusement inefficace.

Un commit est un delta : un petit paquet de changements représentant la différence entre le code avant et après votre modification.

export default {
  data () {
    return {
      msg: 'Your code before'
      msg: 'What your commit actually contains'
    }
  }
}

Chaque commit pointe vers son parent, formant une chaîne de deltas… un peu comme une liste chaînée (amis théoriciens des graphes, respirez). Une branche n’est qu’un pointeur vers un commit précis dans cette chaîne.

Le comprendre est essentiel. Une branche n’est pas un gros conteneur isolé ; c’est juste une étiquette légère posée sur une chronologie de changements. La complexité vient uniquement de la manière dont on décide d’organiser ces chronologies.

Voyons comment les modèles connus organisent leurs chaînes.

Gitflow

Le grand classique, celui qui a popularisé l’idée qu’« il nous faut des règles Git sinon ça part en vrille ».

Tout est parti d’un article de Vincent Driessen en 2010. Avec Git, ce workflow a pris d’assaut l’industrie et proposé un cadre à un outil qui commencait à se populariser. Idéal pour ceux qui venaient de SVN : un système de branches avec des rôles explicites, dont deux branches « éternelles » :

1. develop pour le code instable en cours de dev
2. master pour le code prêt pour la prod

Le développement se fait via des branches feature (ou bugfix) créées depuis develop, puis fusionnées à nouveau avec cette dernière. Quand vous êtes prêts à livrer, vous créez une branche release/, vous testez, corrigez si besoin, puis vous fusionnez sur master où vous tagguez pour l’historique. Comme les correctifs peuvent aussi être utile sur develop, vous y fusionnez release également.

Si une version taguée a besoin d’un correctif, vous créez une hotfix/ depuis master et vous la fusionnez à la fois dans master et develop pour propager le fix partout.

Gitflow a été révolutionnaire, mais pensé pour un monde de logiciels monolithiques et de sorties peu fréquentes. Aujourd’hui, sa complexité devient souvent un frein. La branche develop finit régulièrement en dépotoir de fonctionnalités à moitié terminées, rendant impossible une release propre.

Le cas d’école : vous devez sortir A et B, mais votre collègue a déjà fusionné C (incomplet et bugué) dans develop.

Vous êtes coincés. Impossible de sortir depuis develop sans embarquer C. Option restante : ouvrir une release et tenter de retirer C chirurgicalement - fastidieux, risqué, et source d’ennuis.

La solution évidente : s’assurer que chaque commit sur la branche principale est publiable. Dans ce cas, develop devient redondant : vous tagguez n’importe quel commit de main pour créer une release. Première marche vers un flux plus simple et plus efficace.

GitLab flow

L’idée est simple : si vous avez un environnement, alors vous avez une branche. Quand vous voulez une fonctionnalité sur un environnement donné, vous la « versez » depuis main vers la branche de l’environnement.

Admettons : develop, staging, production.

Sur le papier, c’est nickel : vous faites avancer la fonctionnalité d’environnement en environnement via des merges successifs. Une visibilité parfaite et un chef de projet ravi.

Il n’y a qu’une règle : les merges doivent suivre le même ordre. main > develop > staging > production. Si vous en sautez un, ou si vous poussez un commit « rapide » sur une branche... Alors les parents de commit diffèrent, les branches divergent, vous amassez les conflits de merge et vous obtenez, petit à petit, des bases de code différentes.

En respectant la règle, ça fonctionne. Mais c’est terriblement inefficace, surtout avec du code compilé : déployer « par branche » oblige à reconstruire pour chaque branche. Ici, quatre fois la même chaîne de build.

Faisons plus simple : rendons le dépôt agnostique des environnements. Vous mergez sur main, vous construisez une seule fois un artefact unique, puis votre pipeline de déploiement propage ce package sur l’environnement voulu.

Besoin de savoir quel commit tourne où ? Les outils CD (GitLab, Azure DevOps, etc.) exposent l’état des environnements. Ajoutez GitVersion pour des versions incrémentales à chaque commit, un changelog côté déploiement… Plus besoin de branches d’environnement ni d’attendre quatre builds.

Si l’on enlève ces branches d’environnement, il reste main et des branches feature. Autrement dit…

GitHub flow

GitHub Flow, c’est ça : une branche main stable, des branches feature créées depuis main. C’est du développement basé sur le tronc, avec la doc GitHub qui y ajoute la revue obligatoire par Pull Request.

C’est aussi simple que vos projets d’école : vous voulez ajouter quelque chose à main, vous créez votre branche, vous développez, vous faites relire, vous fusionnez. Votre CI/CD build et déploie.

En déploiement continu, c’est parfait. Mais les recommandations de Github s’arrêtent là : la PR vous force à mettre à jour votre branche, pas la manière, ni comment écrire vos commits.

Résultat possible : tout le monde merge main dans sa feature, et main finit en spaghetti illisible.

On nettoie ça avec une politique « squash on merge » : chaque branche de fonctionnalité devient un seul commit propre sur main.

Bien mieux. Mais une question subsiste : comment supporter plusieurs versions en production ?

Si vous devez patcher 1.0.0, vous ne pouvez pas corriger directement sur main (vous embarqueriez les nouveautés de 2.0.0). Il faut isoler l’ancienne version.

Et c’est là que le mécanisme de hotfix de Gitflow redevient utile. Et si on combinait la simplicité de GitHub Flow avec la sécurité des branches de support ?

Et voilà. C’est le socle du workflow que ce guide vous apprend : pragmatique, basé sur le tronc, et qui pioche le meilleur de chaque monde.

• Un main toujours publiable (Trunk‑Based Development)
• Des branches de fonctionnalité courtes avec PR obligatoire (GitHub Flow)
• Un historique propre grâce au squash
• Des branches de support durables pour hotfix et maintenance (héritées de Gitflow, mais simplifiées)

Vous gagnez en efficacité au quotidien, et en sécurité pour la maintenance en prod. Les pages suivantes vous montrent comment l’appliquer.