Rebase？Merge？这Git这么多讲究

合并分为 快进合并，三路合并 策略还分为 Squash and merge (压缩合并) Rebase and merge (变基合并) Squash and merge (压缩合并) 不过我到没必要思考那麽多，我这个人项目，贡献者也只有我一个，选择压缩还是变基好像都行？ 看看我这个Git工作流 1. 更新本地 `main` - 切到 `main` - 执行“签出并更新” - 确保本地 `main` 与 `origin/main` 一致 2. 从 `main` 新建功能分支 - 功能：`feat/<feature-name>` - 修复：`fix/<issue-name>` - 文档：`docs/<topic-name>` 3. 在功能分支开发 - 只改本次迭代相关内容 - 完成对应测试、类型检查、Lint、构建 - 更新 `docs/iterations/` 迭代文档并记录 Migration/API 影响 4. 本地提交 - 暂存本次相关文件 - 使用 Conventional Commit，例如： ```text feat(qas): show answer timestamps in QA lists ``` - 提交前确认没有误包含 `.env`、构建产物、`coverage/`、无关文档 5. 推送功能分支 - 首次推送时设置 upstream - GitHub 出现对应远程功能分支 6. 创建 Pull Request - `base: main` - `compare: feat/...` - PR 描述包含：变更内容、验证结果、Migration/API/权限影响 - 不要把方向反过来 7. 等待 CI/CD - PR 的 Backend、Frontend、Deployment artifacts 全部通过 - 任意失败先修复功能分支、重新推送，CI 会自动重跑 - 合并到 `main` 后，CD 自动部署生产 8. 合并 PR - 当前项目、单一迭代单一提交的惯例：选 `Squash and merge` - 确认合并目标是 `main` - 合并后删除 GitHub 上的远程功能分支 9. 本地收尾 - 切回 `main` - “签出并更新”，拿到合并后的最终代码 - 删除本地 `feat/...` 分支 - 下次开发从这份最新 `main` 重复第 2 步