Branchement git
Chaque modification va sur sa propre branche. Cela inclut une correction en une ligne et une modification sans ticket. Ne commitez pas sur la branche de base.
1. Trouver la branche de base
Utilisez la première source qui donne une réponse :
- Instructions du dépôt. Lisez
CLAUDE.md,CONTRIBUTING.mdet les documents dans.github/. S'ils nomment une branche de base ou d'intégration, utilisez-la. - Branche par défaut distante.
git symbolic-ref --short refs/remotes/origin/HEAD # affiche origin/<nom> gh repo view --json defaultBranchRef -q .defaultBranchRef.name - Ambiguïté. Si le dépôt distant a aussi
developoudevelopmentet qu'aucun document ne précise laquelle est la base, demandez à l'utilisateur. Ne devinez pas.
Lorsqu'une branche d'intégration (par exemple develop) est la base, un correctif (hotfix) pour une version publiée part de la branche par défaut à la place. N'utilisez cela que lorsque l'utilisateur qualifie le travail de correctif.
2. Vérifier où vous êtes
git status --porcelain
git rev-parse --abbrev-ref HEAD
- Si l'arbre de travail contient des modifications que vous n'avez pas faites, arrêtez-vous. Demandez à l'utilisateur quoi en faire.
- Si vous êtes déjà sur une branche pour ce même travail, restez dessus.
- Si vous êtes sur la branche de base avec vos propres modifications non commitées, déplacez-les :
git switch -c <nom>les conserve dans l'arbre de travail.
3. Créer la branche à partir de la pointe distante
git fetch origin --prune
git switch -c <nom> origin/<base>
git log -1 --oneline
Partir de origin/<base> garantit qu'une branche de base locale obsolète ne cause aucun problème. N'exécutez pas git pull sur la branche de base pour "rattraper" d'abord. Ce n'est pas nécessaire.
4. Nommer la branche
Utilisez la convention du dépôt si elle existe. Sinon, utilisez <type>/<ref>-<slug> :
| Partie | Valeurs |
|---|---|
type | feat, fix, docs, chore, refactor, test, release, hotfix |
ref | Numéro de ticket (42), ticket de pipeline (ticket-007), ou rien |
slug | Deux à cinq mots en minuscules, reliés par des tirets |
Exemples : fix/42-null-session-crash, feat/ticket-007-search-filters, docs/readme-install-steps.
5. Pendant le travail
- Commitez en petites étapes qui ont chacune leur sens individuellement. Rédigez le sujet à l'impératif, 72 caractères ou moins. Utilisez le corps pour expliquer pourquoi.
- N'ajoutez pas de ligne
Co-Authored-By: Claudeà aucun message de commit. C'est une règle de gener8v. - Avant le premier push, vous pouvez rebaser sur
origin/<base>. Une fois la branche poussée, fusionnez la base dans la branche à la place. Un rebase d'une branche déjà poussée réécrit l'historique, etengineering:git-safetycontrôle cela. - Poussez avec une chaîne qui s'arrête à la première erreur :
set -o pipefail git fetch origin && <commande de test> 2>&1 | tail -n 40 && git push -u origin HEADset -o pipefail,| tailmasque le code de sortie de la commande précédente. Ne passez jamais une commande git ou une commande de test danstailsans cela.
Travail parallèle
Pour deux agents ou plus qui modifient du code en même temps, lisez resources/parallel-work.md avant de démarrer un agent. En résumé : une branche de lot depuis la base, un espace de travail et une branche par agent depuis la branche de lot, et aucun agent sur les mêmes fichiers.
Terminé quand
- Vous êtes sur une branche avec un nom clair, et elle commence à
origin/<base>actuelle. git statusn'affiche aucune modification appartenant à quelqu'un d'autre.
Compétences connexes
engineering:github-pr-merge: ouvrir la PR lorsque le travail est terminé.engineering:git-safety: règles d'approbation pour les push forcés, la suppression de branches et les commandes similaires.engineering:github-issue-workflow: le cycle de vie complet d'un ticket ou d'un ticket de pipeline. Il appelle cette compétence en premier.