Git-Workflow für Rust-Entwickler: Vom ersten Commit bis zum Code-Review

Warum ein Git-Workflow die Rettung für Ihr Rust-Projekt (und Ihre Nerven) ist

Haben Sie schon einmal versucht, einen "kaputten" Commit in einem Rust-Projekt rückgängig zu machen, der versehentlich src/main.rs, Cargo.toml und noch drei weitere Module betrifft? Kommt Ihnen bekannt vor? Wenn ja, sind Sie definitiv nicht allein. Rust ist bekannt für seine Strenge, aber ohne einen durchdachten Git-Workflow wird selbst der perfekteste Code zu einem Chaos.

In diesem Artikel zeige ich Ihnen, wie Sie einen Arbeitsablauf mit Git aufbauen, der Ihnen Stunden des Debuggens und Nerven spart. Wir besprechen echte Beispiele in Rust, sprechen über CI/CD, Code-Review und darüber, wie Sie vor Ihren Kollegen kein Gesicht verlieren. Los geht's!

Grundlagen des Git-Workflows für Rust: Wo anfangen

Bevor wir in die Details eintauchen, legen wir die Basis fest. Für Rust-Projekte empfehle ich die Verwendung von GitHub Flow oder Git Flow – abhängig von der Teamgröße. Es gibt jedoch eine Besonderheit: Rust erfordert strenge Typisierung und Tests, daher sollte Ihr Workflow auf cargo test und cargo clippy ausgelegt sein.

Branch-Struktur für Rust

Hier ist ein minimaler Satz von Branches, den ich in meinen Projekten verwende:

\n
• main – stabile Version, immer bereit für ein Release
\n
• develop – Integrationsbranch für Features
\n
• feature/feature-name – jedes neue Feature ist isoliert
\n
• hotfix/hotfix-name – für dringende Korrekturen
\n

Warum ist das für Rust wichtig? Weil cargo check und cargo build Abhängigkeitskonflikte aufdecken können, die sich in einem isolierten Branch leichter lösen lassen als in einem gemeinsamen.

Beispiel: Erstellen eines Feature-Branches für eine neue Funktion

Angenommen, Sie schreiben einen JSON-Parser in Rust. Sie beginnen mit dem Branch main:

git checkout main\ngit pull origin main\ngit checkout -b feature/json-parser

Jetzt schreiben Sie den Code. Hier ist ein einfaches Beispiel einer Funktion, die Sie in src/parser.rs hinzufügen:

use serde_json::Value;\n\npub fn parse_json(input: &str) -> Result<Value, String> {\n    serde_json::from_str(input).map_err(|e| e.to_string())\n}

Führen Sie vor dem Commit unbedingt die Tests aus:

cargo test\ncargo clippy -- -D warnings

Wenn alles in Ordnung ist – machen Sie den Commit:

git add src/parser.rs Cargo.toml\ngit commit -m "feat: Basis-JSON-Parser mit Fehlerbehandlung hinzugefügt"

Beachten Sie das Format des Commits: feat: – das ist Teil der Conventional Commits, die hervorragend mit Rust-Projekten funktionieren, insbesondere wenn Sie einen automatischen Changelog verwenden.

CI/CD für Rust: Automatische Code-Überprüfung

Ohne CI ist Ihr Git-Workflow nur eine Ansammlung von Branches. Für Rust empfehle ich dringend, eine Datei .github/workflows/ci.yml im Stammverzeichnis des Projekts hinzuzufügen (falls Sie GitHub verwenden):

name: Rust CI\n\non:\n  push:\n    branches: [ "main", "develop" ]\n  pull_request:\n    branches: [ "main" ]\n\nenv:\n  CARGO_TERM_COLOR: always\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n    - uses: actions/checkout@v3\n    - name: Build\n      run: cargo build --verbose\n    - name: Run tests\n      run: cargo test --verbose\n    - name: Lint\n      run: cargo clippy -- -D warnings\n    - name: Format check\n      run: cargo fmt -- --check

Jetzt wird bei jedem Push in main oder develop der Build, die Tests und das Linting gestartet. Wenn CI fehlschlägt – wird der Commit nicht gemerged. Das ist ein eiserner Schutz vor "es funktioniert auf meinem Rechner".

Warum das Ihr Projekt retten wird

Stellen Sie sich vor: Sie haben vergessen, Cargo.lock nach dem Hinzufügen einer Abhängigkeit zu aktualisieren. CI wird das sofort bemerken – cargo build gibt einen Fehler aus. Oder Sie haben versehentlich unwrap() im Produktionscode verwendet – clippy mit dem Flag -D warnings wird es abfangen.