Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Avec l'arrivée des outils d'IA, la vitesse de génération du code a considérablement augmenté. Cependant, la vitesse de revue ne suit pas. Selon le rapport DORA (DevOps Research and Assessment) de 2024, les équipes ayant un taux d'adoption élevé de l'IA ont vu la taille de leurs PRs augmenter en moyenne de 154 %, tandis que le temps de revue a grimpé de 91 %. Résultat : les cycles de déploiement ont en réalité ralentit. Demander à quelqu'un de relire d'un coup plus de 1 000 lignes de code fatigue les yeux de n'importe qui. Pour mettre fin à ce chaos, il est indispensable de passer à une structure en chaîne de PRs empilées (Stacked PRs), où le code est superposé par couches.
Couper du code au hasard provoque des erreurs de compilation ou brise les dépendances. Il faut des critères clairs. Limitez une PR unique à 200 lignes de code modifiées et à moins de 10 fichiers modifiés, afin qu'un relecteur puisse terminer en 15 minutes. Une grande fonctionnalité se divise en une chaîne maximale de 3 branches enfants :
Cet ordre doit être strictement respecté. Fixez également le nom des branches selon le format feature/<nom-fonctionnalite>/stack-<etape>-<description>.
Le processus pour décomposer une branche de 1 000 lignes déjà emmêlée (legacy-giant-branch) en une chaîne est simple.
Tout d'abord, mettez à jour la branche main et sauvegardez l'original :
`bash
git checkout main
git pull origin main
git checkout legacy-giant-branch
git branch backup/legacy-giant-branch
`
Ensuite, créez la branche Layer 1 à partir de main et appliquez par « cherry-pick » uniquement les commits liés au schéma :
`bash
git checkout -b feature/order-refactor/stack-1-schema main
git cherry-pick
git push origin feature/order-refactor/stack-1-schema
`
Il suffit ensuite d'utiliser Layer 1 comme parent pour étendre séquentiellement Layer 2 et Layer 3 :
`bash
git checkout -b feature/order-refactor/stack-2-service feature/order-refactor/stack-1-schema
git cherry-pick
git push origin feature/order-refactor/stack-2-service
git checkout -b feature/order-refactor/stack-3-controller feature/order-refactor/stack-2-service
git cherry-pick
git push origin feature/order-refactor/stack-3-controller
`
Le choix des outils est également un point important. Un pur CLI Git est gratuit mais demande beaucoup de manipulations, tandis qu'un outil dédié comme Graphite est pratique mais entraîne des coûts et une dépendance à l'infrastructure.
| Critères d'évaluation | Pure Git CLI | GitHub CLI (gh stack) | Graphite / Outils externes |
|---|---|---|---|
| Suivi des dépendances | Configuration manuelle de la base des branches | .git local et métadonnées GitHub |
Moteur distant séparé et base de données locale |
| Automatisation du rebase | Actions manuelles par branche | Exécution de la commande gh stack rebase |
Traitement automatique de la chaîne inférieure lors de la modification des commits |
| Courbe d'apprentissage | Élevée (nécessite de maîtriser les principes de Git) | Faible (installation d'une extension CLI) | Moyenne (nécessite de s'adapter à une interface dédiée) |
| Stabilité opérationnelle | 100 % compatible standard Git | En état de préversion publique | Très élevée |
Quand on utilise des PRs empilées, le moment le plus pénible est celui où l'on demande de modifier la PR parente. Comme le hash des commits change, toutes les branches enfants en dessous sont cassées. Faire simplement un git rebase duplique les commits. Il faut spécifier la plage à découper avec la syntaxe git rebase --onto.
Si Layer 1 a été modifiée, rendez-vous sur Layer 2 et repositionnez tous les éléments allant du point de commit de Layer 1 avant modification jusqu'au HEAD actuel, au-dessus du point final du nouveau Layer 1.
`bash
git checkout feature/order-refactor/stack-2-service
git rebase --onto feature/order-refactor/stack-1-schema feature/order-refactor/stack-2-service
git push --force-with-lease
`
Faites de même pour Layer 3 au-dessus du nouveau Layer 2 :
`bash
git checkout feature/order-refactor/stack-3-controller
git rebase --onto feature/order-refactor/stack-2-service feature/order-refactor/stack-3-controller
git push --force-with-lease
`
Si vous faites cette tâche manuellement à chaque fois, l'humain commettra inévitablement des erreurs. Créez un script shell pour automatiser le rebase séquentiel :
`bash
#!/usr/bin/env bash
set -e
STACK_BRANCHES=(
"feature/order-refactor/stack-1-schema"
"feature/order-refactor/stack-2-service"
"feature/order-refactor/stack-3-controller"
)
TARGET_BASE="main"
git fetch origin
CURRENT_PARENT="$TARGET_BASE"
for BRANCH in "BRANCH"
OLD_BASE=CURRENT_PARENT" "OLD_BASE" ]; then
git rebase --onto "OLD_BASE" "BRANCH"
CURRENT_PARENT="$BRANCH"
done
`
N'oubliez pas non plus d'activer la fonction d'enregistrement de l'historique de résolution des conflits dans la configuration Git. Cela permettra de passer outre automatiquement les conflits répétitifs.
`bash
git config --global rerere.enabled true
git config --global rerere.autoupdate true
git config --global rebase.autoStash true
git config --global rebase.updateRefs true
`
Diviser une PR en trois crée le problème de faire tourner les runners CI par trois. Il n'est pas nécessaire d'exécuter des tests E2E lourds sur toutes les PRs. Configurez l'environnement GitHub Actions pour n'exécuter que de solides tests unitaires sur les couches inférieures, et de réserver la validation d'intégration globale uniquement à la PR la plus haute.
Ajoutez une condition sur la position de la pile dans .github/workflows/ci.yml :
`yaml
name: Stack-Aware CI Pipeline
on:
pull_request:
branches: [ main ]
jobs:
fast-lint-and-unit-test:
name: Fast Validation (All Layers)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Linter & Unit Tests
run: |
npm ci
npm run test:unit
heavy-integration-test:
name: Full E2E Test (Top Layer Only)
runs-on: ubuntu-latest
if: |
github.event.pull_request.stack == null ||
github.event.pull_request.stack.position == github.event.pull_request.stack.size
steps:
- uses: actions/checkout@v4
- name: Run Heavy Integration & E2E Tests
run: |
npm ci
npm run test:e2e
`
La configuration de règles de protection des branches au niveau de l'organisation est également indispensable :
Pour faire fonctionner correctement les PRs empilées, les relecteurs doivent avoir une vue d'ensemble. Précisez la carte de la pile dans .github/PULL_REQUEST_TEMPLATE.md :
`markdown
Stack Overview
Cette PR fait partie de la chaîne de la pile Order Refactoring Stack.
Current Layer Scope
Dependency Status
`
Une fois que la PR inférieure #101 est intégrée dans main par un Squash Merge, le diff de l'interface utilisateur GitHub de la PR enfant #102 explose soudainement. C'est un phénomène où l'ensemble du code de #101 déjà fusionné est capturé comme modification de la PR enfant. Cela se produit parce que les SHA du commit Squash et du commit parent ont changé sur le graphe des commits Git. Ne paniquez pas, il vous suffit de remonter uniquement les commits de la branche enfant au-dessus de main dans l'ordre suivant :
`bash
git log --graph --oneline
git checkout feature/order-refactor/stack-2-service
git fetch origin
git rebase --onto origin/main feature/order-refactor/stack-2-service
git push --force-with-lease origin feature/order-refactor/stack-2-service
`
Le travail de division d'une énorme PR de 1 000 lignes ne se résume pas à de la manipulation technique de Git. Il s'agit plutôt d'un travail d'ingénierie visant à nettoyer proprement la méthode de révision du code de l'équipe et toute la chaîne de déploiement. Lorsque vous tombez sur une branche legacy brouillonne, commencez par créer une sauvegarde et découpez-la en 3 couches. Non seulement la fatigue des relecteurs diminuera, mais vous parviendrez vous-même à contrôler votre code beaucoup plus clairement.
