Git分支策略建议

## 合并策略（保守）

- 目标
  - release/1.0 只接收必要修复，降低回归风险；
  - main 保持历史清晰，承担最终可发布版本与标签。

- 从 main 到 release/1.0（仅必要时）
  - 触发条件：与发布强相关的严重缺陷修复、安全修复或紧急依赖更新已经进入 main。
  - 建议做法（保守优先顺序）：
    1) 在 release/1.0 上创建临时 hotfix 分支，使用 cherry-pick 精准回收指定提交，再通过 PR 合入 release/1.0；
    2) 避免将 main 整体合并进 release/1.0，减少不必要变更面。
  - 历史策略：保留原提交信息（cherry-pick 使用 -x 标注来源），禁止 rebase 和 squash 已共享的 release 分支。

- 从 release/1.0 到 main（发布时）
  - 时机：完成回归测试与验收，版本内容已冻结。
  - 合并方式：通过 Pull Request 使用「Create a merge commit」（--no-ff），保留分支上下文，便于审计。
  - 标签：合并完成后在 main 上打注解标签（如 v1.0.0），标签指向合并提交。
  - 若需后续补丁：在 main 打标签后，基于 release/1.0 分出维护分支 release/1.0.x，仅纳入高优先级修复。

- 历史与冲突管理
  - main 与 release/1.0 禁止 rebase、禁止 force push。
  - 本地更新使用 --ff-only，确保拉取安全且不产生意外合并。
  - 版本号、变更日志、发布说明在 release/1.0 上维护，回合 main 时一并带回。
  - 如遇冲突，优先在临时分支解决并补充测试，再发起 PR。

- CI 与准入
  - 必须通过：单测、集成测试、静态检查与安全扫描。
  - 分支保护：要求 PR、至少两名评审、PR 必须 up-to-date、禁止直接推送和强制推送。
  - 合并方式：允许「Merge commit」，禁用「Rebase merge」和「Squash merge」（避免丢失追溯）。

---

## 操作提示（命令示例与流程）

- 准备工作（本地同步）
  - git fetch --all --prune
  - git switch release/1.0
  - git pull --ff-only origin release/1.0
  - git switch main
  - git pull --ff-only origin main

- 将 main 的关键修复引入 release/1.0（保守：cherry-pick 到 hotfix 分支）
  - git switch release/1.0
  - git switch -c hotfix/1.0.1
  - git cherry-pick -x <main上的修复commit1> [<commit2> ...]
  - 运行测试、修复冲突并提交
  - git push -u origin hotfix/1.0.1
  - 在代码托管平台创建 PR：hotfix/1.0.1 -> release/1.0
  - 要求通过所有检查后再合入

- 发布合并：release/1.0 -> main
  - 在平台发起 PR：release/1.0 -> main
  - 合并策略选择「Create a merge commit」（等价于 --no-ff）
  - 冲突在 PR 中解决并补充测试
  - 合并后在本地或平台打标签（以本地为例）：
    - git switch main
    - git pull --ff-only origin main
    - 确认 HEAD 为合并提交
    - git tag -a v1.0.0 -m "Release 1.0.0"
    - git push origin v1.0.0

- 发布后维护
  - 若需要补丁版本：从 release/1.0 切出 release/1.0.x，继续使用 cherry-pick + PR 纳入高优先级修复，再按上述流程回合 main 并打标签（v1.0.1、v1.0.2...）。
  - 若不再维护 1.0：将 release/1.0 设为只读保护或归档，避免误变更。

- 分支保护建议（平台设置）
  - main、release/1.0：启用分支保护；禁止直接推送与强制推送；要求 PR 与状态检查通过；要求评审与对话已解决；禁止 squash/rebase 合并。
  - 标签保护：保护 v1.* 标签，限制推送与删除权限。

- 注意事项
  - 不要在 release/1.0 或 main 上使用 rebase、reset --hard 或强制推送。
  - 避免将 main 整体频繁合入 release/1.0；仅 cherry-pick 必要修复以控制风险面。
  - 如需回滚发布，优先在 main 上对相关提交使用 revert 生成反向提交，并通过 PR 合入；不要使用 reset 或 force push。

# 合并策略（偏好：快速）

目标：在不破坏分支历史的前提下，尽快将 feat/login 合并到 main，保持线性、可追踪的历史，并减少冲突概率。

推荐策略（按是否已推送/shared分为两种）：
- 策略A（优先，未推送或仅你本地开发）：本地 rebase 再快进合并
  - 在本地将 feat/login 基于最新的 main 进行 rebase（仅限本地未推送的情况下），以获得线性历史。
  - 在 main 上使用 fast-forward-only 合并，快速集成，无额外 merge commit。
- 策略B（已推送或多人协作）：合并更新再快进合并
  - 使用 merge 将最新 main 合入 feat/login，避免重写已公开历史。
  - 合并完成并通过CI后，在 main 上进行 fast-forward-only 合并。

合并到 main 的方式：
- 首选：fast-forward 合并（git merge --ff-only），保证历史线性、快速清晰。
- 可选：Squash Merge（在代码评审平台选择），将多个提交压缩为一个提交，简化历史（不破坏 main，安全）。适用于提交粒度较碎的场景。

# 操作步骤（命令示例）

准备（所有场景通用）：
- 确保工作区干净：git status
- 同步远端：git fetch --all --prune

策略A：本地 rebase（仅限 feat/login 未推送或未共享）
1) 更新并重放
- git checkout feat/login
- git rebase origin/main
- 解决冲突（若有）：编辑文件 → git add ... → git rebase --continue（需要时可 git rebase --abort 放弃此次 rebase）
2) 自测与CI
- 运行测试/构建
3) 快进合并到 main
- git checkout main
- git merge --ff-only feat/login
- git push origin main
4) 善后
- 删除功能分支（可选）：git branch -d feat/login；git push origin :feat/login（如需保留记录可不删）

策略B：已推送/多人协作（避免历史重写）
1) 将 main 合入 feat/login
- git checkout feat/login
- git merge --no-edit origin/main
- 解决冲突：编辑文件 → git add ... → git commit
- 自测并推送：git push origin feat/login
2) 发起 PR（推荐在平台设置“仅允许 fast-forward”或选择 Squash Merge）
- CI 通过、评审通过后合并
3) 如需本地直接合入 main（有权限且CI已通过）
- git checkout main
- git merge --ff-only feat/login
- git push origin main
4) 善后
- 视需要删除远端 feat/login 分支（非强制）

# 注意事项与建议

- 禁止：对已推送/多人协作的 feat/login 使用 rebase 后强制推送（避免历史重写导致他人分支紊乱）。本建议不提供任何强制推送命令。
- 若 git merge --ff-only 在 main 上失败，说明 main 已前进且不能快进，请先回到 feat/login 按策略A或B更新，再重试。
- 在 PR 合并策略上：
  - 追求快速线性：启用“fast-forward only”或“rebase then ff-only”的项目设置；
  - 提交较碎时：使用 Squash Merge 保持 main 简洁（不会破坏 main）。
- 为 main 启用保护：
  - CI 必须通过后才能合并；
  - 禁止直接推送（只允许通过 PR 合并）；
  - 要求分支为 up-to-date（防止陈旧基线合并）。
- 冲突处理：
  - rebase 冲突：逐个提交解决 → git add → git rebase --continue；
  - merge 冲突：一次性解决 → git add → git commit；
  - 遇到复杂冲突，优先在 feat/login 处理，保持 main 干净。
- 回退方式（安全做法）：
  - 合并后若需撤销，使用 git revert 目标提交（或 PR 的 merge/squash 提交），避免重写历史。

# 操作提示（简版速查）

- 本地单人、未推送：
  - git checkout feat/login
  - git rebase origin/main
  - 测试通过
  - git checkout main && git merge --ff-only feat/login && git push

- 已推送/多人：
  - git checkout feat/login
  - git merge --no-edit origin/main
  - 测试通过 && git push
  - PR 合并：fast-forward only 或 Squash Merge

- 失败处理：
  - main 上 ff-only 失败 → 回到 feat/login 同步 main 后重试
  - 冲突 → 解决后继续（rebase --continue 或 commit）

## 合并策略（main ← hotfix/ci）

- 默认推荐：Squash Merge
  - 适用：hotfix 改动较小、含有多次临时/修正提交，需保持 main 历史整洁且便于整体回滚。
  - 效果：将 hotfix/ci 的变更压缩为 1 个提交合入 main，回滚时一键 revert 即可。

- 备选（按团队偏好选择）
  - Merge Commit（--no-ff）
    - 保留分支上下文，审计友好；历史将多一个合并提交。
    - 适合严格审计或需要完整保留分支结构的团队。
  - Rebase + Fast-Forward（--ff-only）
    - 线性历史最清晰；仅在分支未被多人共享或未对外发布时采用。
    - 注意：已共享分支不要强制推送，避免影响他人历史。

- 分支保护建议
  - 对 main 启用保护：禁止直接 push，要求状态检查通过、至少 1–2 名评审、限制合并方式（按上面策略固定为 Squash 或 Merge-Commit）。


## 操作建议与注意事项

- 合并前
  - 同步最新代码：
    - git fetch origin
    - git checkout hotfix/ci
    - git merge origin/main
  - 本地/CI 全量验证：lint、单测、关键集成用例（特别是 CI 相关变更要在沙箱或试运行验证）。
  - 尽量将改动控制在最小范围，避免夹带无关变更（例如只改 CI 配置）。

- 提交 PR（推荐）
  - base=main，compare=hotfix/ci。
  - PR 描述包含：问题背景、变更点、影响面、回滚方案。
  - 通过所有检查与评审后选择合并方式：
    - 若采用 Squash Merge：在平台选择“Squash and merge”，提交信息建议：hotfix(ci): 简述问题与修复点。
    - 若采用 Merge Commit：选择“Create a merge commit”，确保主干保留分支上下文。
    - 若采用 Rebase + FF：确认分支无人协作、历史未共享，选择“Rebase and merge”或先在本地 rebase 再在平台执行 FF-only 合并。
  - 冲突处理：在 hotfix/ci 分支上解决冲突并重跑 CI，不在 main 上直接手工解决提交。

- 合并后
  - 观察主干 CI/CD 与生产/预发表现，确认修复生效。
  - 同步本地：git checkout main && git pull
  - 如需发布标识，可创建补丁标签（例如 vX.Y.Z+1-hotfix-ci），便于回滚与审计。

- 注意事项（避免破坏性操作）
  - 不要直接向 main 推送；通过受保护的 PR 合并。
  - 不要对已共享的 hotfix/ci 执行 rebase 或 push --force。
  - 避免使用 reset --hard 等破坏历史的操作；需要调整请新建分支处理。
  - 若冲突频繁，尽早与 main 同步或将改动拆小，减少一次性冲突面。


## 操作提示（示例命令）

- 更新分支并预检
  - git fetch origin
  - git checkout hotfix/ci
  - git merge origin/main
  - # 运行测试与 CI 预检查…

- 通过 PR 合并（推荐）
  - 在代码托管平台创建 PR：base=main，compare=hotfix/ci
  - 选择合并策略：
    - Squash Merge：选择“Squash and merge”，提交信息如：hotfix(ci): fix <简述>
    - Merge Commit：选择“Create a merge commit”
    - Rebase + FF：选择“Rebase and merge”（仅在未共享时）

- 如需在本地模拟 Squash 合并（平台不支持时）
  - git checkout main
  - git pull
  - git merge --squash hotfix/ci
  - git commit -m "hotfix(ci): <简述>"
  - git push

说明：未提供明确的策略偏好，以上默认推荐使用 Squash Merge。若团队偏好为 merge-commit 或 rebase-ff，可按对应小节执行。