Git-Workflow für C#-Entwickler: Vom Chaos zur Ordnung

Git-Workflow für C#-Entwickler: Wie man aufhört, Merges zu fürchten, und anfängt zu leben

Haben Sie schon einmal einen halben Tag damit verbracht, herauszufinden, wer wann Ihre geliebte Methode CalculateOrderTotal() überschrieben hat? Oder haben Sie vielleicht einen "dringenden Fix" direkt in master gepusht, woraufhin die Produktion mit einem NullReferenceException-Fehler abstürzte? Kommt Ihnen bekannt vor? Willkommen im Club der C#-Entwickler, die im Chaos von Git ohne klaren Workflow zu überleben versuchen.

Wenn Sie denken, Git sei einfach nur git add . und git push, dann übersehen Sie das Wesentliche. Ein richtiger Git-Workflow ist keine religiöse Debatte, sondern ein Werkzeug, das Nerven, Zeit und Geld spart. Besonders in der Welt von C#, wo wir Lösungen (.sln), Projekte (.csproj) und jede Menge NuGet-Pakete haben, die gerne in Konflikt geraten.

In diesem Artikel zeige ich Ihnen funktionierende Branching-Strategien, reale Codebeispiele für C# und erkläre, wie Sie Routinearbeiten automatisieren. Los geht's!

Warum C#-Projekte einen besonderen Ansatz für Git erfordern?

Wenn Sie mit C# arbeiten, haben Sie es nicht nur mit Textdateien zu tun. Sie haben:

• Lösung (.sln) – eine Datei, die auf alle Projekte verweist. Wenn zwei Entwickler gleichzeitig ein neues Projekt hinzufügen, ist ein Merge-Konflikt garantiert.
• .csproj-Dateien – XML-Dateien, die beim Hinzufügen von NuGet-Paketen oder Ändern der Target Framework aktualisiert werden. Das manuelle Zusammenführen solcher Dateien ist eine Qual.
• appsettings.json und web.config – Konfigurationen, die oft Verbindungszeichenfolgen enthalten. Diese sollten nicht committet werden, aber jeder vergisst es.
• bin/ und obj/-Ordner – wenn Sie diese einmal committen, werden Ihre Kollegen Sie für immer verfluchen.

Daher muss Ihr Git-Workflow für C# bis ins kleinste Detail durchdacht sein. Und er beginnt mit der richtigen .gitignore.

Schritt 1: Einrichtung der .gitignore für C#

Die Standard-.gitignore für C# kann von GitHub/gitignore heruntergeladen werden, aber ich füge einige wichtige Zeilen hinzu, die oft übersehen werden:

# Konfigurationsdateien mit Geheimnissen (nicht committen!)appsettings.Development.jsonappsettings.Local.jsonsecrets.json

# Von ReSharper oder Rider generierte Dateien*.DotSettings.user*.DotSettings

# NuGet-Pakete (Cache)packages/*.nupkg

# TestergebnisseTestResults/*.trx

# Visual Studio-Ordner.vs/*.suo*.user*.sln.docstates

Warum ist das wichtig? Stellen Sie sich vor, Sie committen appsettings.Development.json mit einer lokalen Datenbank-Verbindungszeichenfolge. Ihr Kollege pulled und seine Anwendung stürzt ab, weil er diese Datenbank nicht hat. Es sieht nach einem kleinen Versehen aus, kostet aber eine Stunde Arbeitszeit.

Auswahl einer Branching-Strategie für das C#-Team

Es gibt mehrere gängige Git-Workflows. Für C#-Projekte empfehle ich zwei Hauptstrategien: Git Flow und Trunk-Based Development. Lassen Sie uns diese anhand von Beispielen analysieren.

Variante 1: Git Flow (Klassiker für große Projekte)

Git Flow ist wie SOLID für Git. Es ist ideal, wenn Sie klare Releases haben (z. B. Version 2.1.0, 2.2.0). Die Branches sehen so aus:

• main – nur stabiler Code.
• develop – Integrationsbranch.
• feature/XXX-123-add-new-api – Features von develop.
• release/2.1.0 – Release-Vorbereitung.
• hotfix/2.0.1-critical-bug – dringende Fehlerbehebungen von main.

Beispiel für C#: Sie arbeiten an einer neuen Funktion "Rabattberechnung mit Aktionscode".

# Feature von develop erstellengit checkout developgit pullgit checkout -b feature/ABC-42-add-promo-discount

# Code in C# schreiben// DiscountService.cspublic class DiscountService{    public decima