Restructurer les commits par composant

Réorganisez tous les commits sur une branche de feature en commits logiques basés sur les composants qui correspondent à l'architecture de HyperShift.

Quand l'utiliser

• L'utilisateur demande de « refaire les commits », « restructurer les commits », « squasher par composant » ou « organiser les commits »
• Préparer une branche pour la révision d'une PR avec un historique de commits propre
• La branche contient de nombreux petits commits/WIP qui devraient être consolidés

Catégories de composants et mappage des fichiers

Les commits sont créés dans cet ordre. Chaque commit regroupe les fichiers par limite architecturale.

Exclus de la restructuration : bin/ (output de build), hack/, contrib/, hypershift-ci-python/, self-managed-azure-ci-setup/ et .claude*/ sont des outils de build, des helpers CI ou de la config dev. S'ils sont modifiés, incluez-les dans le commit le plus pertinent selon leur objectif. En cas d'ambiguïté, préférez HO.

Procédure

1. Identifier la base de fusion et les fichiers modifiés

BASE_BRANCH=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null || echo "main")
MERGE_BASE=$(git merge-base ${BASE_BRANCH} HEAD)
git log --oneline ${MERGE_BASE}..HEAD          # review existing commits
git diff ${MERGE_BASE}..HEAD --name-only | sort # all changed files

2. Réinitialiser à la base de fusion (garder les modifications)

git reset --soft ${MERGE_BASE}  # keep everything staged
git reset HEAD                   # unstage everything

3. Indexer et commiter chaque groupe de composant

Pour chaque composant (dans l'ordre), indexez les fichiers correspondants et commitez :

# Example: API commit (exclude test files — they belong in E2E)
git add api/ && git reset HEAD 'api/**/*_test.go' 2>/dev/null || true
git commit  # use conventional commit format

# Example: Vendor commit
git add vendor/ client/ \
  "cmd/install/assets/hypershift-operator/zz_generated.crd-manifests/"
git commit

# ... repeat for CLI, HO, CPO, E2E, Docs

4. Vérifier et forcer le push

git status                                  # must be clean
git log --oneline ${BASE_BRANCH}..HEAD      # verify commit structure
git push --force-with-lease       # requires user confirmation

Conventions de message de commit

Invoquez toujours d'abord la compétence git-commit-format pour les règles de formatage complètes (longueur de ligne, footer, Co-Authored-By, etc.). Cette section fournit le type et la portée spécifiques au composant, plus des conseils sur la rédaction du sujet et du corps.

Rédaction du sujet

1. Examinez les modifications réelles du composant pour déterminer ce qui a été fait
2. Choisissez le type et la portée dans le tableau ci-dessous
3. Écrivez un sujet concis qui résume l'objectif des modifications, pas seulement « mettre à jour les fichiers »
4. Utilisez le mode impératif : « add », « update », « remove » — pas « added », « adds », « adding »

Rédaction du corps

Passez en revue les modifications indexées et écrivez un corps qui décrit ce qui a été ajouté ou modifié. Utilisez des puces lorsqu'il y a plusieurs modifications distinctes. Le corps doit donner au relecteur suffisamment de contexte pour comprendre le commit sans lire chaque fichier. Chaque ligne doit faire moins de 140 caractères (appliqué par gitlint).

Notes

• Le commit Vendor est toujours chore(api): puisqu'il s'agit de la sortie régénérée du commit API
• Le commit E2E est toujours test(e2e): quel que soit ce qui est testé
• Le commit Docs n'a pas de parenthèses de portée — simplement docs:

Cas limites

• Composant vide : Ignorez le commit si aucun fichier ne correspond à ce composant.
• Packages de support : support/ va avec HO (commit 4), pas CPO.
• Sidecars du plan de contrôle : control-plane-pki-operator/, availability-prober/, dnsresolver/, etcd-*, ignition-server/, kas-bootstrap/, konnectivity-*, kubernetes-default-proxy/, sync-fg-configmap/, sync-global-pullsecret/, token-minter/ vont tous avec CPO (commit 5) puisqu'il s'agit de composants du plan de contrôle gérés par CPO.
• Ingress partagé : shared-ingress/ et sharedingress-config-generator/ vont avec HO (commit 4), pas CPO, puisqu'ils font partie du hypershift-operator.
• Opérateur Karpenter : karpenter-operator/ va avec HO (commit 4) puisqu'il est géré par le hypershift-operator.
• Fixtures de test partagées dans CPO : control-plane-operator/**/testdata/ reste avec CPO.
• Manifestes d'installation CRD générés : cmd/install/assets/hypershift-operator/zz_generated.crd-manifests/ va avec Vendor (commit 2), pas CLI.
• go.mod API : api/go.mod va avec API (commit 1), pas Vendor.
• Fichiers de test API : api/**/*_test.go (tests de validation de l'API UX) vont avec E2E (commit 6), pas API. Indexez d'abord les fichiers non-test d'API, puis incluez les fichiers de test API lors de l'indexation d'E2E.
• Fichiers de documentation : docs/ et examples/ vont avec Docs (commit 7), pas Vendor. Cela inclut la configuration mkdocs, les guides pratiques, les références d'architecture et la documentation agrégée. La docs/content/reference/api.md (référence d'API générée) va également ici.
• Outils de build/CI : hack/, contrib/, hypershift-ci-python/, self-managed-azure-ci-setup/ ne sont pas mappés à un composant par défaut. Incluez dans le commit le plus pertinent selon l'objectif, ou HO en cas d'ambiguïté.

Liste de contrôle rapide

• [ ] Branche de base déterminée à partir de la PR (par défaut main)
• [ ] Tous les fichiers modifiés examinés avant de commencer
• [ ] Réinitialisation avec --soft (aucune perte de données)
• [ ] Commits dans l'ordre correct : API, Vendor, CLI, HO, CPO, E2E, Docs
• [ ] L'arborescence de travail est propre après tous les commits
• [ ] Force push confirmé avec l'utilisateur avant l'exécution