git rebase -i 合并提交前必须确认三件事：目标提交是否属同一逻辑单元、是否存在 --amend 导致 SHA 变更的提交、是否已 fetch 最新远程状态以避免基于过期分支变基。
Git 本身不解决“复杂项目迭代难”的问题，它只提供原子能力；真正起作用的是你对分支、标签、提交粒度和协作节奏的控制方式。
git rebase -i 合并提交前必须确认三件事
交互式变基不是为了“让历史好看”，而是为了降低合入风险。执行 git rebase -i HEAD~5 前，先检查：
- 目标范围内的所有提交是否都只修改了同一逻辑单元（比如“增加 JSON Schema 校验”）
- 中间是否有
git commit --amend过的提交——这类提交 SHA 已变，rebase -i会把它当新提交处理，可能重复引入变更 - 是否已用
git fetch origin拉取最新远程状态，避免基于过期develop分支做变基，导致后续git push --force-with-lease失败
feature/* 分支命名必须带上下文，不能只写功能名
光写 feature/login 是危险的。多人并行时，没人知道这个登录是“微信扫码登录”还是“LDAP 统一认证”。推荐格式：feature/auth-wechat-sso 或 feature/api-v2-login-endpoint。
这样做的实际好处：
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- CI 流水线可基于分支名自动启用对应测试集（如匹配
auth-*的分支跑 SSO 集成测试） -
git branch --format="%(refname:short) %(committerdate:short)" | grep "auth"能快速定位近期相关开发 - Pull Request 标题自动生成更准确，减少人工描述偏差
git tag -a 不只是打个标记，它绑定的是可部署单元
附注标签（git tag -a v1.2.0 -m"Release candidate for macOS arm64 build"）本质是把一次构建产物的元信息固化下来。关键点：
- 标签消息里必须包含构建环境标识，比如
built-on: ci-runner-macOS-14-arm64，否则无法复现 - 不要在 CI 脚本里用
git describe --tags取版本号后直接打包——它依赖最近 tag 的距离，而git describe在 detached HEAD 下行为不稳定 - 发布后立即推送到远程：
git push origin v1.2.0，而不是等--tags批量推送，避免团队成员拉不到最新 release 点
git stash pop 容易丢变更，优先用 git worktree
当你正在改 feature/a，突然要紧急修复 hotfix/db-timeout，别急着 git stash。更稳的方式是：
-
git worktree add ../dev-hotfix hotfix/db-timeout—— 新开一个目录，独立工作区 - 在新目录里改完、提交、push，再切回原目录
git worktree remove ../dev-hotfix - 这样避免了
stash应用冲突、误删、或忘记pop导致本地变更丢失
注意：worktree 不支持裸仓库，且每个工作树需对应不同物理路径，不能嵌套在主工作区子目录下。
