开发存在依赖的代码时两名开发者是否应共用同一feature分支？

你提的「有依赖关系的开发任务共用同一个feature分支协作」的方案，是行业里跑了很多年的成熟实践，完全能解决你说的依赖版本对不上、合release时一堆冲突、残留僵尸代码的问题，但它有明确的适用场景，也不是处理这类问题的唯一选项。

方案的实际收益 #

你们现在的流程出问题，本质是跨分支的依赖同步全靠开发者自觉，只要有人忘了拉对方分支的最新提交，本地就会留着旧版本的依赖代码，时间拖得越久，各个分支的代码差得越多，最后合到一起的时候当然冲突满天飞，还容易把早就废弃的旧逻辑（就是你说的僵尸代码）带到下游。

改成强依赖的任务共用一个feature分支之后，原来跨分支同步的麻烦事就变成了同分支正常拉代码的常规操作，从流程上堵死了版本错位的可能：所有人的提交都落在同一个分支上，每次pull下来的就是这个功能当前最新的全量代码，根本不会出现“甲的分支里依赖的是乙3天前写的代码，丙的分支里依赖的是乙昨天写的代码”这种离谱情况，合release时那种因为版本差导致的无意义冲突会少一大截，僵尸代码残留的问题也基本能解决。

这种模式特别适合2-3个人搭伙做、开发周期1-2周、代码耦合度极高的活——比如两个人搭伙做一个新的支付模块，一个写页面交互一个写后端接口，拆成两个独立分支根本跑不通完整流程，共用分支反而是效率最高的选择。

落地注意事项 #

这个方案也不是拿来就能用，要避坑得先定好几个基础规则：

• 所有人提交代码前必须先跑git pull --rebase拉到分支最新代码，尽量小步提交，别攒个大几百行代码一次性往上推，不然冲突解决起来照样麻烦
• 公共的feature分支一定要开保护，禁止任何人force push，不然哪个人操作失误把别人提交的代码冲掉，排查起来能折腾半天
• 别什么场景都硬套这个方案：如果两个任务只是弱依赖——比如甲写的是全团队都能用的通用工具函数，乙只是用其中两个方法，后续这个工具还要给好几个其他功能用，硬凑到一个分支上反而会把不相关的代码绑死，合入的时候带一堆无关改动，反而容易出新问题。

行业内其他常用处理方案 #

除了共用分支之外，行业里处理这类跨开发者依赖的常见方案还有几个，你们可以根据自己团队的节奏选：

• 短分支+强制每日同步：要求所有feature分支最多活3天，超了就拆成更小的能独立交付的任务；所有分支每天必须至少从上游拉一次最新代码，如果要依赖别人还没合入的功能，固定每天同步一次对方分支的更新，从流程上不让分支分叉太久差太多。
• 依赖代码优先合主干：这是现在很多推主干开发的团队的标准做法：如果甲的工作是乙的前置依赖，就让甲先把自己的代码拆成能独立合入的最小块，尽快合到develop分支，乙直接从develop拉要用的代码，根本不需要在本地merge别人没合入的分支，从根上就消灭了跨分支长期依赖的问题。
• 栈式PR协作：如果是好几个人串行依赖的场景——比如丙的代码依赖乙，乙的代码依赖甲，那每个人还是从develop切自己的分支，提PR的时候先不往develop合，目标分支直接选自己依赖的上游分支；等最底层甲的PR合进develop了，再依次把乙、丙的PR目标分支切回develop，每层PR只留自己写的那部分改动，不会混进不同版本的依赖代码，适合人多、依赖链清晰的中大型团队。

你提的这个方案完全可以先小范围试，找2-3个平时协作就比较紧密的小团队跑1-2个月，把基本的提交规则、分支保护配好，看看合入冲突率、交付速度的实际变化，再决定要不要全团队推就行。

内容的提问来源于stack exchange，提问作者AlJones1816