基于待合并PR分支开发新功能的Git正确工作流是什么？
2026-7-8
基于待合并分支开发新功能的正确工作流
咱们团队合并PR到main是压缩成单个提交再删分支，这种场景下，要是得基于还没合并的feature-1开发feature-2，推荐两种靠谱的做法：
方法1：从main建分支，临时合并feature-1
- 先切到main拉最新代码：
git checkout main && git pull - 新建feature-2：
git checkout -b feature-2 - 把feature-1临时合并过来：
git merge feature-1 - 接着在feature-2上开发提交就行（比如你的DDD）
这么做的好处是，等feature-1被压缩成FFF合并到main后，你把main合并到feature-2时，Git能识别出feature-2里已经有feature-1的代码，不会因为重复提交产生大量冲突。
方法2：用git rebase --onto提前规划（适合爱用变基的人）
如果你偏好线性提交历史，也可以这么搞：
- 在feature-1上开发完feature-2的提交（比如DDD）
- 等feature-1被压缩合并到main后，跑这个命令：
git rebase --onto main feature-1 feature-2
这个命令的作用很明确：把feature-2里不属于feature-1的提交（就是你写的DDD），直接移到main分支的最新提交后面。
现在已经出冲突的补救办法
你的情况是feature-2基于feature-1的BBB/CCC开发，而main里的FFF是feature-1的压缩版，Git认不出这俩是同一套代码，所以合并或变基才会炸出一堆冲突。按下面步骤来解决：
- 先备份feature-2，以防操作崩了：
git checkout feature-2 && git checkout -b feature-2-backup - 执行
git rebase --onto main feature-1 feature-2- 这个命令会跳过feature-1的所有提交（BBB、CCC），只把你在feature-2上的独有提交（DDD）移到main的GGG后面
- 过程中要是有冲突，只需要解决你写的feature-2代码和main最新代码的冲突就行，不用再处理feature-1的重复内容
- 解决完冲突后，跑
git rebase --continue完成变基；要是不想搞了，就git rebase --abort回到备份分支
重点提醒
- 公共分支（比如main、已经提了PR的feature-1）绝对不能变基，只在自己的私有分支（比如feature-2）上操作
- 如果feature-1还在评审阶段，能不提前基于它开发feature-2就尽量别搞，除非你确定feature-1不会有大改动；实在要开发，优先用临时合并的方式，后面再清理提交历史
内容的提问来源于stack exchange，提问作者IttayD
相关产品推荐
相关产品推荐
