Workflow Git pour les développeurs Rust : du premier commit à la revue de code

Pourquoi un workflow Git est une bouée de sauvetage pour votre projet Rust (et votre santé mentale)

Avez-vous déjà essayé d'annuler un commit « cassé » dans un projet Rust qui touche accidentellement src/main.rs, Cargo.toml et trois autres modules ? Cela vous dit quelque chose ? Si oui, vous n'êtes certainement pas seul. Rust est réputé pour sa rigueur, mais sans un workflow Git bien conçu, même le code le plus parfait se transforme en bouillie.

Dans cet article, je vais vous montrer comment construire un processus de travail avec Git qui vous fera gagner des heures de débogage et de stress. Nous analyserons des exemples concrets en Rust, parlerons de CI/CD, de revue de code et de la façon de ne pas perdre la face devant vos collègues. C'est parti !

Les bases du workflow Git pour Rust : par où commencer

Avant de plonger dans les détails, définissons les bases. Pour les projets Rust, je recommande d'utiliser GitHub Flow ou Git Flow — selon la taille de l'équipe. Mais il y a une particularité : Rust exige un typage strict et des tests, donc votre workflow doit être adapté à cargo test et cargo clippy.

Structure des branches pour Rust

Voici l'ensemble minimal de branches que j'utilise dans mes projets :

\n
• main — version stable, toujours prête pour la release
\n
• develop — branche d'intégration pour les fonctionnalités
\n
• feature/nom-de-la-fonctionnalité — chaque nouvelle fonctionnalité est isolée
\n
• hotfix/nom — pour les corrections urgentes
\n

Pourquoi est-ce important pour Rust ? Parce que cargo check et cargo build peuvent révéler des conflits de dépendances qu'il est plus facile de résoudre dans une branche isolée que dans une branche commune.

Exemple : création d'une branche de fonctionnalité pour une nouvelle fonction

Supposons que vous écriviez un analyseur JSON en Rust. Vous commencez à partir de la branche main :

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

Maintenant, vous écrivez le code. Voici un exemple simple d'une fonction que vous ajoutez dans src/parser.rs :

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}

Avant de commiter, exécutez impérativement les tests :

cargo test\ncargo clippy -- -D warnings

Si tout est OK — on commit :

git add src/parser.rs Cargo.toml\ngit commit -m "feat: ajouter un analyseur JSON de base avec gestion des erreurs"

Notez le format du commit : feat: — cela fait partie des Conventional Commits, qui fonctionnent très bien avec les projets Rust, surtout si vous utilisez un changelog automatique.

CI/CD pour Rust : vérification automatique du code

Sans CI, votre workflow Git n'est qu'un ensemble de branches. Pour Rust, je recommande vivement d'ajouter à la racine du projet un fichier .github/workflows/ci.yml (si vous utilisez GitHub) :

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

Désormais, chaque push sur main ou develop déclenchera la compilation, les tests et le linting. Si la CI échoue — le commit n'est pas fusionné. C'est une protection en béton contre le « ça marche sur ma machine ».

Pourquoi cela sauvera votre projet

Imaginez : vous avez oublié de mettre à jour Cargo.lock après avoir ajouté une dépendance. La CI le remarquera immédiatement — cargo build renverra une erreur. Ou vous avez accidentellement utilisé unwrap() dans du code de production — clippy avec le flag -D warnings le détectera.