Git workflow pour les développeurs C# : du chaos à l'ordre

Git workflow pour les développeurs C# : comment arrêter d'avoir peur des fusions et commencer à vivre

Avez-vous déjà passé une demi-journée à essayer de comprendre qui et quand a réécrit votre méthode préférée CalculateOrderTotal() ? Ou peut-être avez-vous poussé un "correctif urgent" directement dans master, pour que la production plante avec une erreur NullReferenceException ? Cela vous parle ? Bienvenue dans le club des développeurs C# qui tentent de survivre dans le chaos de Git sans workflow clair.

Si vous pensez que Git se résume à git add . et git push, vous passez à côté de l'essentiel. Un bon workflow Git n'est pas un débat religieux, mais un outil qui économise les nerfs, le temps et l'argent. Surtout dans le monde C#, où nous avons des solutions (.sln), des projets (.csproj) et une multitude de paquets NuGet qui aiment entrer en conflit.

Dans cet article, je vais vous montrer des stratégies de branchement fonctionnelles, des exemples de code réels pour C# et vous expliquer comment automatiser les tâches répétitives. C'est parti !

Pourquoi les projets C# nécessitent-ils une approche particulière de Git ?

Lorsque vous travaillez avec C#, vous n'avez pas affaire à de simples fichiers texte. Vous avez :

• La solution (.sln) — un seul fichier qui référence tous les projets. Si deux développeurs ajoutent un nouveau projet en même temps, le conflit de fusion est garanti.
• Les fichiers .csproj — des fichiers XML qui sont mis à jour lors de l'ajout de paquets NuGet ou du changement de Target Framework. Fusionner ces fichiers manuellement est une douleur.
• appsettings.json et web.config — des fichiers de configuration qui contiennent souvent des chaînes de connexion. Ils ne doivent pas être commités, mais tout le monde oublie.
• Les dossiers bin/ et obj/ — si vous les commitez une seule fois, vos collègues vous maudiront pour toujours.

Par conséquent, votre workflow Git pour C# doit être méticuleusement pensé. Et cela commence par un .gitignore correct.

Étape 1 : Configuration du .gitignore pour C#

Le .gitignore standard pour C# peut être téléchargé depuis GitHub/gitignore, mais j'ajoute quelques lignes importantes souvent négligées :

# Fichiers de configuration avec secrets (ne pas commiter !)appsettings.Development.jsonappsettings.Local.jsonsecrets.json

# Fichiers générés par ReSharper ou Rider*.DotSettings.user*.DotSettings

# Paquets NuGet (cache)packages/*.nupkg

# Résultats de testsTestResults/*.trx

# Dossiers Visual Studio.vs/*.suo*.user*.sln.docstates

Pourquoi est-ce important ? Imaginez que vous commitez appsettings.Development.json avec une chaîne de connexion locale à la base de données. Votre collègue fait un pull, et son application plante car il n'a pas cette base de données. Cela semble être une petite erreur, mais cela coûte une heure de travail.

Choisir une stratégie de branchement pour une équipe C#

Il existe plusieurs workflows Git populaires. Pour les projets C#, je recommande deux stratégies principales : Git Flow et Trunk-Based Development. Analysons-les avec des exemples.

Option 1 : Git Flow (classique pour les grands projets)

Git Flow est comme le SOLID pour Git. Il est idéal lorsque vous avez des versions claires (par exemple, version 2.1.0, 2.2.0). Les branches ressemblent à ceci :

• main — uniquement du code stable.
• develop — branche d'intégration.
• feature/XXX-123-add-new-api — fonctionnalités à partir de develop.
• release/2.1.0 — préparation de la version.
• hotfix/2.0.1-critical-bug — corrections urgentes à partir de main.

Exemple pour C# : vous travaillez sur une nouvelle fonctionnalité "Calcul de la réduction avec un code promo".

# Créer une fonctionnalité à partir de developgit checkout developgit pullgit checkout -b feature/ABC-42-add-promo-discount

# Écrire du code en C#// DiscountService.cspublic class DiscountService{    public decima