Workflow Git pour développeurs Go : du chaos au code propre

Pourquoi le workflow Git est-il un casse-tête pour chaque développeur Go ?

Avez-vous déjà passé une demi-journée à comprendre pourquoi la build s'est cassée sur la branche master, alors que tout fonctionnait hier ? Ou vous êtes-vous embrouillé dans les versions des modules Go lorsque deux développeurs modifiaient le même package en même temps ? Cela vous parle ? Bienvenue au club.

Go est un langage simple et élégant. Mais sans un workflow Git approprié pour les développeurs Go, même le code le plus propre se transforme en spaghetti. Dans cet article, nous n'aborderons pas des théories abstraites, mais des scénarios réels : comment travailler avec go modules, comment ne pas casser le CI/CD et comment rendre la code review rapide et utile. Attachez vos ceintures, ce sera pratique.

Les bases : Git Flow et son adaptation à Go

Le Git Flow classique (branches main, develop, feature/*, release/*, hotfix/*) fonctionne très bien pour les grands projets. Mais dans le monde de Go, il y a des nuances.

Pourquoi le Trunk-Based Development gagne-t-il souvent ?

La communauté Go aime la simplicité. Le Trunk-Based Development (travailler dans une branche principale unique avec des branches de fonctionnalités de courte durée) s'accorde parfaitement avec la philosophie de Go. Moins de branches, moins de maux de tête avec les merges. Pour les petites équipes (jusqu'à 5 personnes), c'est souvent le meilleur choix.

Cependant, si votre cycle de release est de 2 semaines et que vous avez plusieurs fonctionnalités en parallèle, Git Flow reste roi. Rappelez-vous simplement : chaque branche ne doit pas vivre plus de 2-3 jours. Sinon, les conflits sont inévitables.

# Exemple de création d'une branche feature pour un nouveau middleware\ngit checkout -b feature/add-request-logger\n# On travaille, on commit, on push\ngit push origin feature/add-request-logger\n# Après la code review — squash et merge dans main\n

Go Modules et Git : Comment ne pas perdre la tête

Le problème le plus fréquent dans un workflow Git golang concerne les dépendances. Go Modules (depuis Go 1.11) a résolu de nombreux problèmes, mais en a ajouté de nouveaux.

Bien travailler avec les tags

Votre module est une API publique. Si vous le modifiez, changez la version. Le versionnement sémantique (semver) n'est pas seulement à la mode, c'est obligatoire.

\n
• v0.x.x — version instable, la compatibilité peut être rompue.
\n
• v1.x.x — stable, la rétrocompatibilité est obligatoire.
\n
• v2+ — changements majeurs, changez obligatoirement le chemin du module.
\n

Exemple de taggage correct :

git tag v1.2.3\ngit push origin v1.2.3\n

Et maintenant, un exemple de ce qu'il NE faut PAS faire :

# Mauvais : tag sans synchronisation avec go.mod\ngit tag v1.0.0\n# Mais dans go.mod, la version est encore v0.5.0\n

Mettez toujours à jour go.mod d'abord, puis posez le tag. Sinon, go get deviendra fou.

Comment mettre à jour les dépendances en équipe

Supposons que vous ayez mis à jour la bibliothèque github.com/gin-gonic/gin. Au lieu de pusher un énorme diff, suivez la règle : un commit = un changement.

# Mise à jour d'une seule dépendance\ngo get github.com/gin-gonic/gin@v1.9.1\ngo mod tidy\ngit add go.mod go.sum\ngit commit -m "chore: update gin to v1.9.1"\ngit push\n

Cela simplifie la code review : votre collègue voit exactement ce qui a changé, et non de la « magie » dans go.sum.

Code Review pour Go : Le workflow Git au service de la qualité

La code review ne consiste pas à « trouver des bugs ». Il s'agit de transmettre des connaissances et de maintenir un style. Mais si votre workflow Git pour les projets golang n'est pas configuré, la review devient un enfer.

Comment rendre la review rapide

\n
• Petites PR : 200-300 lignes de code maximum. Au-delà, divisez.
\n
• Linting automatique : golangci-lint doit fonctionner avant la review, pas après. Configurez une pre-commit hook ou le CI.
\n
• Style unifié : utilisez gofmt (oui, c'est obligatoire). Pas de disputes