Workflow Git avec Claude Code : branches propres, petits commits, CI et passation d'équipe

Plus Claude Code écrit vite, plus votre workflow Git doit être explicite. L’IA peut produire un diff utile en quelques minutes, mais elle peut aussi mélanger des fichiers hors sujet, créer un commit trop gros, résoudre un conflit sans comprendre l’intention ou pousser avant les contrôles locaux.

Ce guide propose un workflow Git concret pour le développement solo et en équipe avec Claude Code : branche propre, petits commits, point de review, hygiène du worktree, conflits, rollback sûr, CI avant push et passation quotidienne. Les notions de staging, commit et rebase sont expliquées sans jargon.

À lire ensuite : résolution de conflits Git avec Claude Code, GitHub Actions avancé et review workflow checklist. Références officielles : Claude Code hooks, Claude Code headless mode, Git user manual, Git rebase, GitHub Actions workflow syntax et pre-commit.

Les mots Git en clair

Le working tree est l’espace où les fichiers sont modifiés. Claude Code écrit dans cette zone. La zone de staging est le panier du prochain commit : git add ne sauvegarde pas tout, il choisit ce qui entrera dans le prochain commit.

Un commit est un instantané nommé des changements en staging. Un bon commit est assez petit pour être relu en une fois. Un rebase reprend vos commits et les repose au-dessus du main à jour. L’historique devient plus lisible, mais réécrire une branche déjà partagée peut gêner les autres.

Claude Code ne doit pas seulement produire du code. Il doit aussi lire le diff, proposer les fichiers à placer dans le staging, rédiger un message, expliquer les conflits, lancer les vérifications et laisser une note de passation.

flowchart LR
  A["Objectif clair"] --> B["Mettre main a jour et creer branche"]
  B --> C["Implementer une petite tranche"]
  C --> D["Lire le diff et choisir le staging"]
  D --> E["Review gate et CI locale"]
  E --> F["Petit commit"]
  F --> G["Rebase ou PR"]
  G --> H["Handoff et rollback"]

Commencer par une branche propre

Avant toute édition, rendez l’état du dépôt compréhensible. “Propre” ne signifie pas toujours zéro changement ; cela signifie qu’aucun changement hors sujet n’est mélangé à la tâche.

git status --short
git fetch origin
git switch main
git pull --ff-only origin main
git switch -c feature/checkout-coupon-validation
git status --short

Sous PowerShell, un nom de branche daté aide lorsque plusieurs sessions tournent en parallèle.

$topic = "checkout-coupon-validation"
$date = Get-Date -Format "yyyyMMdd"
git fetch origin
git switch main
git pull --ff-only origin main
git switch -c "feature/$date-$topic"
git status --short

Le premier prompt doit fixer le périmètre.

Goal: add coupon expiry validation to checkout.
Scope: edit only src/checkout, src/coupons, and matching tests.
Do not stage, commit, push, or edit unrelated files.
Before editing, read package.json and existing checkout tests.
After editing, show git diff --stat and the exact test commands you ran.

Chez ClaudeCodeLab, Masa a souvent vu des tâches d’article inclure par accident des brouillons produit, des scripts locaux ou des rapports temporaires. Le build passait, mais le diff n’était plus défendable. Préciser ce qui est hors périmètre réduit beaucoup ce risque.

Staging sélectif et petits commits

git add -A est pratique, mais trop large avec une IA. Il peut ajouter des fichiers temporaires, une configuration locale ou une autre tâche.

git diff --stat
git diff
git add src/checkout/validateCoupon.ts
git add tests/checkout/validateCoupon.test.ts
git diff --staged --stat
git diff --staged

Un message de commit doit être retrouvable.

git commit -m "feat(checkout): validate coupon expiry before payment"

Pour un changement qui touche les lecteurs ou les clients, ajoutez un corps.

git commit -m "fix(content): keep Claude Code Git workflow CTA localized" -m "Updates the localized article body, internal links, and review checklist so translated pages follow the same Git workflow."

Demandez à Claude Code de proposer le message, sans committer.

Read only the staged diff.
Propose one Conventional Commits message.
Do not run git commit.
Mention the user impact in the body if the change affects readers or customers.

Fixer les règles dans CLAUDE.md

CLAUDE.md est le mode d’emploi local pour Claude Code. Ce n’est pas le README utilisateur, mais le contrat de travail du binôme IA.

# Claude Code Git rules

- Start every coding task with `git status --short` and report unrelated dirty files.
- Do not run `git add -A`, `git commit`, `git push`, `git reset --hard`, or `git clean -fd` unless the user explicitly asks.
- Keep commits small: one behavior change, one test update, or one content slug at a time.
- Before proposing a commit, show `git diff --stat` and `git diff --staged --stat`.
- If a conflict appears, explain both sides before editing the conflicted file.
- Run the closest local checks before push: lint, typecheck, test, build, or article metadata checks.
- Leave a handoff note with changed files, commands run, failing checks, and rollback option.

En équipe, ajoutez un hook pour bloquer les commandes Git dangereuses.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git *)",
            "command": "node .claude/hooks/block-dangerous-git.mjs"
          }
        ]
      }
    ]
  }
}

// .claude/hooks/block-dangerous-git.mjs
import process from "node:process";

let raw = "";
for await (const chunk of process.stdin) raw += chunk;

const input = JSON.parse(raw || "{}");
const command = input.tool_input?.command ?? "";

const blocked = [
  /git\s+reset\s+--hard\b/,
  /git\s+clean\s+-[^\s]*f/,
  /git\s+push\s+--force(?!-with-lease)/,
  /git\s+checkout\s+--\s+\./,
  /git\s+restore\s+\.\b/
];

if (blocked.some((pattern) => pattern.test(command))) {
  process.stderr.write(`Blocked risky Git command: ${command}\n`);
  process.exit(2);
}

Un hook réduit les accidents, mais ne remplace pas la review, les droits Git et la CI.

CI locale avant push

N’attendez pas l’échec de la CI distante. Ajoutez un preflight local qui lance les scripts disponibles.

// scripts/claude-git-preflight.mjs
import { execSync } from "node:child_process";
import { existsSync, readFileSync } from "node:fs";

const run = (command) => {
  console.log(`\n$ ${command}`);
  execSync(command, { stdio: "inherit", shell: true });
};

run("git diff --check");
run("git diff --cached --check");
run("git status --short");

const pkg = existsSync("package.json")
  ? JSON.parse(readFileSync("package.json", "utf8"))
  : { scripts: {} };

for (const script of ["lint", "typecheck", "test", "build"]) {
  if (pkg.scripts?.[script]) run(`npm run ${script}`);
}

node scripts/claude-git-preflight.mjs

Prompt utile :

After implementation, run the local preflight.
If a command fails, stop and explain the first failing command, likely cause, and smallest next fix.
Do not push until the preflight is green.

pre-commit et GitHub Actions

pre-commit applique les contrôles avant la création du commit.

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: git-diff-check
        name: git diff whitespace check
        entry: git diff --check
        language: system
        pass_filenames: false
      - id: npm-test
        name: npm test when available
        entry: node scripts/claude-git-preflight.mjs
        language: system
        pass_filenames: false

python -m pip install pre-commit
pre-commit install
pre-commit run --all-files

Sur les PR, GitHub Actions refait les vérifications dans un environnement propre.

# .github/workflows/claude-code-pr-gate.yml
name: Claude Code PR Gate

on:
  pull_request:
    branches: [main]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: git diff --check origin/main...HEAD
      - run: npm run lint --if-present
      - run: npm run typecheck --if-present
      - run: npm test --if-present
      - run: npm run build --if-present

Conflits, rebase et rollback

Un conflit veut dire que Git ne peut pas choisir automatiquement. Faites expliquer les deux intentions avant de modifier.

git fetch origin
git rebase origin/main
git status --short
git diff --name-only --diff-filter=U

We are in a rebase conflict.
For each conflicted file, explain what our branch changed and what origin/main changed.
Resolve only after explaining the business intent.
After editing, run the narrowest relevant test.
Do not continue the rebase until I approve the resolved diff.

git add src/checkout/validateCoupon.ts
npm test -- --runInBand validateCoupon
git rebase --continue

Si la résolution semble mauvaise :

git rebase --abort

Pour annuler un commit partagé, préférez git revert.

git log --oneline -5
git revert --no-edit HEAD
git status --short

Pour un fichier non committé :

git restore --staged src/checkout/validateCoupon.ts
git restore src/checkout/validateCoupon.ts

Cas d’usage et pièges

Cas 1 : fonctionnalité solo. Créez feature/yyyyMMdd-topic, limitez les fichiers, gardez un commit par comportement et lancez le preflight avant push.

Cas 2 : PR d’équipe. La session d’implémentation ne crée pas de commit. La session de review lit seulement le staged diff. Une personne valide le titre, la CI, le risque et le rollback.

Cas 3 : contenus et pages produit. Sur ClaudeCodeLab, articles, liens Gumroad, CTA de formation et liens internes touchent le revenu. Travaillez par slug et locale, puis vérifiez description, hero, CTA, liens et localisation.

Cas 4 : refactor long. Tests d’abord, changement interne ensuite, suppression à la fin.

Piège	Cause	Prévention
git add -A ajoute trop	L’IA a modifié trop largement	Ajouter au staging par chemin
Commit géant	Trop de sujets mélangés	Un objectif par commit
Conflit mal résolu	Intention non lue	Expliquer ours/theirs
Push dangereux après rebase	Historique divergent	--force-with-lease sous règle d’équipe
PR rouge	Pas de checks locaux	Preflight
Rollback destructeur	reset --hard	git revert pour commit partagé

Passation quotidienne

Une passation doit être courte et vérifiable.

## Handoff: 2026-06-02

Branch: feature/20260602-checkout-coupon-validation
Goal: validate coupon expiry before payment authorization

Changed:
- src/checkout/validateCoupon.ts
- tests/checkout/validateCoupon.test.ts

Checks:
- npm run lint: passed
- npm test -- --runInBand validateCoupon: passed
- npm run build: not run, no UI/build config touched

Risk:
- Coupon timezone boundary still needs one integration test.

Rollback:
- Revert commit `abc1234` if production checkout rejects valid coupons.

Suite logique

Pour travailler seul, commencez par la fiche gratuite Claude Code. Pour des prompts réutilisables, des règles CLAUDE.md et des templates de review, consultez les produits ClaudeCodeLab. Pour une équipe qui doit adapter branches, CI, permissions, rollback et passation à un vrai dépôt, passez par la formation et consultation Claude Code.

Resultat observe

Appliqué à ClaudeCodeLab, ce workflow a transformé la review : au lieu de tout relire, on contrôle le slug, les locales, les métadonnées, le CTA et le scope du diff. git diff --staged --stat et la passation rendent les preuves visibles.