🌿 Mermaid

Graphe Git

Expliquez vos stratégies de branches visuellement

Ouvrir cet exemple dans l’éditeur En générer un avec l’IA

Qu’est-ce qu’un Graphe Git ?

Un graphe Git montre commits, branches, merges et tags. C’est la façon la plus claire de documenter votre stratégie de branches — git flow, trunk-based, release trains — pour toute l’équipe.

Le graphe Git est un support pédagogique : sa place est dans CONTRIBUTING.md, dans le guide d’onboarding, dans le débat sur l’opportunité de squasher. C’est le seul diagramme dont la syntaxe reprend les commandes que le lecteur va taper, ce qui le rend facile à vérifier. Il n’a en revanche aucun lien avec votre dépôt : il montre le modèle de branches que vous visez, jamais l’historique que vous avez réellement. Il ne connaît pas non plus la notion de dépôt distant : un fork se dessine comme une branche ordinaire.

Exemple en direct

Code Mermaid

gitGraph
    commit id: "init"
    branch develop
    commit id: "setup CI"
    branch feature/auth
    commit id: "login page"
    commit id: "JWT"
    checkout develop
    merge feature/auth tag: "v0.2.0"
    checkout main
    merge develop tag: "v1.0.0"

Exemple en direct

Quand l’utiliser

Documenter la stratégie de branches et de releases de l’équipe

Onboarder les développeurs avec des conventions git visuelles

Expliquer les procédures de hotfix et de release

Erreurs fréquentes

branch change aussi de branche courante

Après branch develop, tous les commits suivants atterrissent sur develop et non sur main. On ajoute des commits en les croyant sur le tronc, puis on s’étonne que sa voie soit vide — écrivez checkout main si c’était l’intention.

Le tronc s’appelle main

checkout master échoue sur « Trying to checkout branch which is not yet created ». Renommez la branche par défaut avec une directive init qui fixe gitGraph.mainBranchName à master, sur la première ligne du diagramme.

Le cherry-pick exige une autre branche

Le commit source doit exister, porter l’id que vous référencez et se trouver sur une autre branche. Un cherry-pick depuis la branche courante échoue sur « Source commit is already on current branch ».

Syntaxe de base

.mmd

gitGraph
    commit
    branch develop
    commit
    checkout main
    merge develop

gitGraph TB:
La disposition par défaut se déroule de gauche à droite. Ajouter TB: rend le graphe vertical, ce qui fait bien mieux tenir un long historique de releases dans une page de documentation.
commit id: "hotfix" type: HIGHLIGHT tag: "v1.0.1"
Un commit accepte un id réutilisable plus loin, un type NORMAL, REVERSE ou HIGHLIGHT, et un tag dessiné comme une étiquette de release sur la voie.
branch develop order: 2 commit
branch crée la branche et s’y positionne en une seule étape. L’attribut order fixe la position verticale de la voie, pour que main reste là où le lecteur l’attend.
cherry-pick id: "fix-npe"
Le cherry-pick copie un commit sur la branche courante : c’est ainsi qu’on montre un correctif rétroporté sur une ligne de release sans redessiner toute la branche.

Questions sur ce diagramme

Puis-je montrer les tags et les releases ?

Oui — commits et merges acceptent un attribut tag: (ex. tag: "v1.0.0"), parfait pour documenter les points de release.

Quelles stratégies de branches peut-il représenter ?

Toutes : git flow, GitHub flow, trunk-based development, branches de release — la syntaxe reflète les vraies opérations git (branch, checkout, merge, cherry-pick).

Puis-je mettre un graphe Git dans le CONTRIBUTING.md d’un dépôt GitHub ?

Oui : un bloc délimité annoté mermaid s’affiche dans la vue fichier de GitHub comme de GitLab. C’est sa place naturelle — les règles de branches et leur illustration changent dans le même commit et dans la même revue. Le relecteur obtient un diff, pas une nouvelle capture d’écran.

Le graphe Git lit-il mon dépôt réel ?

Non. Il est écrit à la main et ne sait rien de votre dépôt : il ne dérivera donc pas avec votre historique, mais il ne vous préviendra pas non plus quand il deviendra faux. C’est un modèle de stratégie de branches, pas un journal.

Comment représenter un rebase ou un revert ?

Il n’existe pas de mot-clé rebase : dessinez plutôt le résultat, c’est-à-dire les commits redessinés sur la branche cible. Un revert s’écrit commit type: REVERSE, qui affiche le commit barré sur sa voie pour montrer qu’il a été annulé.

Un graphe Git peut-il montrer des dates ou un calendrier de release ?

Non. Les commits sont ordonnés mais ne portent aucun horodatage et il n’y a pas d’axe. Associez le graphe à une frise chronologique pour les dates de release, ou à un Gantt quand le train de releases a des durées et des dépendances à planifier.

Graphe Git ou un autre type de diagramme ?

Graphe Git ou frise chronologique ?

Les deux sont chronologiques. Le graphe Git est chronologique et ramifié : il montre le travail qui avance sur des lignes parallèles puis se rejoint. La frise chronologique, elle, est plate. Si l’essentiel est que deux flux ont divergé, seul le graphe Git le rend visible.

Graphe Git ou flowchart ?

Le graphe Git montre à quoi ressemble l’historique, le flowchart montre ce qu’un développeur doit faire. « Partir de main, ouvrir une PR, merger en squash » est une procédure avec des décisions : c’est un flowchart, qu’un graphe Git vient illustrer.

Explorer les autres types de diagrammes

🔀 Flowchart (logigramme)💬 Diagramme de séquence 🧩 Diagramme de classes 🗄️ Diagramme entité-association 🔄 Diagramme d’états 📅 Diagramme de Gantt 🥧 Diagramme circulaire 🧠 Carte mentale 🕰️ Frise chronologique 🚶 Parcours utilisateur 🎯 Matrice à quadrants

Créez votre Graphe Git maintenant

Décrivez-le en langage naturel — l’IA écrit le code Mermaid pour vous.

Ouvrir Mermaid Studio