PR 还没合，新需求又来了，分支怎么管
提示本文发布于 4 个月前，其中信息可能已经时过境迁...
这个场景应该很多人都遇到过：你提交了一个 PR 正在等 review，这时候又来了一个新需求。你是继续在同一个分支上开发，还是另起一个分支？
以前我图省事，直接在原分支上继续写。结果 review 的时候 reviewer 说"这个改动和 PR 主题无关"，新功能又因为 PR 没合不能提测，两边都卡着。
后来我总结了一套做法。
核心原则：一个分支一个功能
分支的职责应该单一。PR 里的提交只应该和这个功能相关，混入其他改动会让 review 变得困难，回滚也变得复杂。
具体怎么做
如果新需求和当前 PR 无关
基于主分支创建新分支：
bash
git checkout master
git pull origin master
git checkout -b feat/new-issue如果新需求和当前 PR 相关
可以在同一分支继续开发，但提交信息要写清楚，方便 reviewer 区分。
如果新需求是当前 PR 的 bug 修复
直接在当前分支修复，这样 PR review 时可以一并处理。
几个好习惯
- 及时合并：PR 通过后马上合并到主分支，避免分支堆积
- 命名规范：
feat/issue-123、fix/login-bug，一看就知道是干什么的 - 定期清理：合并后删除本地分支，保持干净
分支管理不是什么高深的技术，但做得好不好，直接影响团队的协作效率。