Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
45 lines
2.6 KiB
Markdown
45 lines
2.6 KiB
Markdown
# 分支規則 — SDLC 各階段動工前的分支確認
|
||
|
||
分析要讀對分支的程式碼,實作要寫進對的分支。兩件事都不能從「目前 checkout 的分支」推定使用者的意圖。
|
||
|
||
## 先確認,再動工
|
||
|
||
| 階段 | 要確認的分支 | 確認時機 |
|
||
| --- | --- | --- |
|
||
| `analyze` | **來源分支**——哪條分支的程式碼算現況 | 讀任何程式碼之前 |
|
||
| `implement` | **目標分支**——這批工作要合併進哪條分支 | 寫任何檔案之前 |
|
||
|
||
確認方式:
|
||
|
||
1. 先把事實攤開:目前分支、工作區是否乾淨、遠端有哪些分支(`git branch -r`)、下節判定出的遠端預設分支。
|
||
2. 依 `jsc-ask:ask` 的決策樹詢問,每個選項都要標明影響範圍。分析錯分支會產出對不上程式碼的工作包;目標分支錯了則 PR 會開到錯的地方。
|
||
3. 把確認結果寫進產出(分析頁的來源分支欄、PR 的目標分支),後續步驟一律沿用同一個答案,不再自行改判。
|
||
4. 使用者沒回答就**不預設** `develop`/`master`;預設值只在使用者明確同意後才成立。
|
||
|
||
## 判定遠端預設分支
|
||
|
||
1. 先用 `git symbolic-ref --quiet refs/remotes/origin/HEAD`,結果形如 `refs/remotes/origin/<預設分支>`。
|
||
2. 取不到時退而用 `git remote show origin`,找輸出中的 `HEAD branch:` 那行。
|
||
3. 兩者都取不到 → 回報並停止,**不臆測** `master`/`main`。
|
||
|
||
需要基準或後備分支時(例如 PR 目標):`origin/develop` 存在就用 `develop`;否則 `origin/master` 存在就用 `master`;兩者皆無則回報並停止。
|
||
|
||
## 只讀階段不動工作區
|
||
|
||
`analyze` 是 logic-only 階段:
|
||
|
||
- 需要換分支才能讀到正確現況時,**停下來請使用者自己切換**。
|
||
- 不代為 `switch`、不 `stash`、不動工作區、不建分支。
|
||
|
||
## 實作階段的分支選擇
|
||
|
||
- **只有來源分支與目標分支同名時才開新的工作分支**:同名就不可在該分支上直接 commit,改從已更新到最新的目標分支建立新工作分支,後續操作都以新分支為準。不同名就在目前分支處理。
|
||
- 新分支名稱要可讀且不覆蓋既有分支;本地或遠端已存在同名分支時,換一個時間戳或短 hash。
|
||
- 切換或建立分支屬不可忽略的狀態變更,要在輸出中講清楚原因與結果分支名稱。
|
||
|
||
## 不破壞既有工作
|
||
|
||
- 工作區有未提交變更時,先提醒使用者 commit 或備份,**絕不**強制丟棄。
|
||
- 未提交變更導致切換分支或 pull 失敗 → 停止並回報,請使用者處理。
|
||
- **絕不** `reset --hard`/`checkout -f`/`clean`。
|