rebase-clean

작성자: openshift

기능 브랜치를 메인 브랜치 위로 엄격하게 정리하여 리베이스하며, 충돌 해결을 최소화하고 전체 검증을 수행합니다. 사용자가 신중하게 리베이스해 달라고 요청할 때 사용하세요…

npx skills add https://github.com/openshift/lightspeed-operator --skill rebase-clean

Clean Rebase Workflow

Use this workflow exactly for rebases in this repository.

Rules

  • Do not create extra temporary branches unless the user explicitly asks.
  • Do not make unrelated edits.
  • Do not stop after analysis; finish rebase and validation.
  • Keep output brief and operational.
  • Never assume target branch names; detect current branch first.
  • CRITICAL: Never use go test directly - ALWAYS use make test (handles envtest, CRDs, build flags).

Step 0: Detect Branch Context

  1. Run git branch --show-current.
  2. Treat detected current branch as the candidate target branch.
  3. Ask user to confirm explicitly before proceeding:
    • I detected '<current-branch>' as the current branch. Should I rebase this branch?
  4. If user specified a target branch, verify it matches current branch; if not, stop and ask.
  5. Do not run reset/rebase commands until this confirmation is received.
  6. Before any reset/rebase command, restate:
    • current branch
    • target branch
    • approved baseline ref and confirm when there is any mismatch or ambiguity.

Step 1: Restore Branch Baseline (Rerun Only)

Use this step only when a prior rebase attempt failed or introduced unwanted edits. For a first rebase attempt, skip this step and go directly to Step 2.

  1. Checkout target branch.
  2. Hard reset to the known backup/base commit the user approved.
  3. Fetch upstream.

Command pattern:

git checkout <branch>
git reset --hard <backup-or-approved-base>
git fetch upstream

Step 2: Rebase Onto Main

Run:

git rebase upstream/main

If conflicts occur, resolve only the conflicted files. Do not add extra refactors.

Step 3: Conflict Resolution Policy

For each conflicted file:

  1. Start from one side (ours or theirs) as a temporary base.
  2. Apply only minimal compatibility changes required to compile and run tests on the new base branch.
  3. Keep behavior from the feature commit unless it is incompatible with upstream removals/renames.
  4. Resolve matching tests together with production code changes.
  5. Avoid opportunistic refactors during conflict resolution.
  6. Go module conflicts: If go.mod or go.sum conflict, prefer theirs (upstream) and run go mod tidy after.

Then:

git add <resolved files>
GIT_EDITOR=true git rebase --continue

Repeat until rebase completes.

Step 4: Verify No Code Loss

Run these checks against the approved pre-rebase baseline (backup/base commit):

git range-diff upstream/main...<approved-base> upstream/main...HEAD
git diff --name-status <approved-base>..HEAD
git merge-base --is-ancestor upstream/main HEAD
git log --left-right --cherry-pick --oneline upstream/main...HEAD

Acceptance criteria:

  1. Branch intent is preserved:
    • Commit intent maps cleanly in range-diff (rewritten SHAs are fine).
  2. Main is fully incorporated:
    • git merge-base --is-ancestor upstream/main HEAD succeeds (exit code 0).
  3. No unexpected file removals/renames beyond what upstream already changed.
  4. Any conflict-touched files have expected compatibility-only deltas.
  5. No unexplained drift from the approved baseline.

If any check fails, treat as code-loss risk and restart from Step 1.

Step 5: Regenerate Manifests (If API Changed)

If any files in api/v1alpha1/ were touched during rebase:

make generate
make manifests
git add api/ config/
git commit --amend --no-edit

This ensures CRD manifests are up to date with API changes.

Step 6: Full Validation Pipeline

Run exactly:

make test && make lint

Critical: Use make test, not go test. The Makefile handles essential setup (envtest, CRDs, build flags).

If validation or code-loss checks fail at any point:

  1. Treat it as an incorrect rebase result.
  2. Abort/restore to the approved baseline.
  3. Re-run the rebase/conflict-resolution flow from Step 1.
  4. Re-run Step 4 and this step.
  5. Repeat full loop until all checks pass.

Step 7: Optional E2E Validation

Only if the user requests or if changes affect reconciliation logic:

make test-e2e

Note: Requires a running OpenShift/Kubernetes cluster with operator deployed.

Step 8: Final Report

Report only:

  • Rebase completed (yes/no)
  • Current branch and ahead/behind state (git status -sb)
  • make test result
  • make lint result
  • make test-e2e result (if run)
  • Manifests regenerated (yes/no/not needed)

Do not include unrelated diagnostics.

openshift의 다른 스킬

openshift-docs
openshift
OpenShift Container Platform 문서를 마크다운 형식으로 검색하고 읽습니다. 사용자가 OpenShift 기능, 구성, 설치 등에 대해 질문할 때 사용합니다.
triage-leaked-infra
openshift
AWS VPC 또는 HyperShift CI의 인프라 세트가 삭제해도 안전한지 평가합니다. 사용자가 cleanleaked 출력을 붙여넣고 '이거 삭제해도 되나요?', '이거...'라고 물을 때 사용합니다.
openshift-expert
openshift
OpenShift 플랫폼 및 Kubernetes 전문가로, 클러스터 아키텍처, 오퍼레이터, 네트워킹, 스토리지, 문제 해결 및 CI/CD 파이프라인에 대한 깊은 지식을 보유하고 있습니다. 사용…
Konflux Archived PipelineRuns
openshift
KubeArchive를 통해 보관된 Konflux PipelineRun, TaskRun 및 파드 로그에 접근합니다. Konflux PipelineRun 결과를 확인하거나 조사할 때 자동으로 적용됩니다.
backport
openshift
메인 브랜치에서 릴리스 브랜치로 커밋이나 PR을 백포트합니다. 사용자가 브랜치 간 변경 사항을 백포트, 체리픽, 포팅하거나 해결을 요청할 때 사용합니다.
rebase
openshift
현재 브랜치를 기본 브랜치 위로 리베이스하고, 모든 충돌을 해결한 뒤 린트, i18n, 빌드가 통과하는지 확인합니다. 사용자가 리베이스, 업데이트, 또는 동기화를 요청할 때 사용합니다…
Build CPO Image
openshift
컨트롤 플레인 오퍼레이터 컨테이너 이미지를 빌드하고 푸시합니다. 라이브 클러스터에 배포가 필요한 CPO 변경 사항을 테스트할 때 자동으로 적용됩니다.
find-complexity
openshift
순환 복잡도가 높거나, 길이가 지나치게 길거나, 매개변수가 너무 많은 함수와 메서드를 찾습니다. 사용자가 복잡한 코드나 복잡도를 찾아 달라고 요청할 때 사용하세요.