当所有人的开发都在同一个分支，而本次投产只投该分支的部分新增代码时，你怎么处理？

[jokechen]

今天晚上投产，所有需要投产的代码要合并到名为“231102”的分支上，然而大家都在一个名为“230915”的分支上做开发，部分功能还没有开发完，只能把开发完的代码从 230915 分支合并到 231102 上，请问有什么相对快捷又不影响他人开发的分支合并方法吗？

我上午的时候，在本地把 230915 分支代码向 231102 分支代码进行合并，遇到冲突的时候，只把我自己的代码合并过来了，其他人新写的代码没有做迁移。但是我代码尚未提交到远程库，这导致如下问题：

1. 我自己代码合并过来后，发现有两个类没有正确合并，也就是说冲突处理出现了错误，所以想着再做一次 merge ，结果由于我刚刚已经处理过一次冲突了，git 直接把这两个类给跳过了，没有办法再进行下一次合并。
2. 由此联想到，其他人想要合并自己的代码到生产分支，也会出现第 1 点问题，由于冲突都被我处理过了，所以代码没有办法合并过来。会对别人有影响。

本帖完结。
截止到现在为止，初步完成了自己的代码的分支迁移。我是用`idea compare with branch`一个一个比对着提的代码。目前项目可以启动，测试了一个看起来问题不大。不知道上线后会不会冒出一堆其他奇奇怪怪的问题来。

[murmur]

手合 master ，一行一行复制过来，我都这么干了 4 年了，早习惯了

[murmur]

这样其实也挺好的，每次合一次都能看到底下人代码写的啥屌样，不行赶紧打回去，有些人 pull request 他是不看的过了扫描就给过来

[jokechen]

@murmur 然而本次投产的代码中，虽有一部分是我负责，但并不是我写的，很容易漏掉（从其他同事手里交接过来的，前情提要： https://www.v2ex.com/t/982890#reply38 ）

[lingex]

如果需要合并的提交是比较孤立完整的，可以用 cherry pick

[JadePenG]

不应该一个开发任务是一个开发分支嘛，这样就直接在源头规避了 merge 冲突的问题。

[Avn]

这种情况不应该做 branch 级别的 merge ，应该做 commit 级别的 cherry pick 。

[jokechen]

@Avn 比较有意思的是，我们最近新迁了仓库，也就是 10 月 31 日的时候迁的。既往的提交记录都没有了。

[zackzergzeng]

把 230915 上需要上线的提交 cherry-pick 到 231102 上

[scorpion91]

把 230915 分支上的 commit 一个一个合过来，不要一次性合，如果发现有错误直接在本地分支回退就行了

[zackzergzeng]

@jokechen 迁移为什么会丢记录啊，你们这个项目的仓库雷也太多了吧😂

[kuaner]

cherry-pick

[Rorysky]

cherry-pick

这樱桃俺不是抢咧，俺是拾咧

[Avn]

@jokechen 迁移远程仓库应该在本地仓库添加 remote ，把代码和提交记录 push 到新的远程仓库。

如果现状是丢失提交记录的话，那应该基于 231102 创建新的分支，把需要合并的代码从 230915 分支找出来拷贝到新的分支里面，然后把新的分支合并到 231102 发版。新的分支同时也建议合并到 230915 ，虽然不会引起代码变化，但是可以提前解决以后 230915 合并到 231102 时可能出现的潜在问题。

总的来说，不能把 230915 直接合并到 231102 。

[IvanLi127]

每个人自己 cherry pick 到自己的新分支，然后再往发布的分支合。

[Gaoti]

同意 @Avn #6 的说法，这种情况应该 cherry-pick 。

但是你们这个分支管理也太混乱了，正常情况下(需求之间独立)都应该基于 master 创建新的 feat 分支，本地 checkout feat 分支来开发的。如果多个需求之间相互依赖，就应该要确定 release version 是不是一致。
假设有 A 、B 两个 feat
case 1: A 先发布的情况下， 创建 A 、B 两个分支。提测的时候 A 先合入测试环境 ，B 在本地开发过程中继续 rebase feat A 代码。如果有多个测试环境，A 、B 分开测试更好；
case 2: A 、B 一起发布，创建一个分支即可。跟团队确认并同步两个需求不可独立发布，按期同时发布 or 同时延期

摸鱼时间的回复，可能描述的还不太精准，仅供参考。要管理好分支，本质上还是要将各个开发环境独立开来

[victimsss]

现状 cherry-pick 吧，未来建议 feat 、fix 、docs 等都创建小分支，然后 merge 到公共分支，这样子分支也可以保留也可以 rebase

[winterbells]

@murmur 上家的小组长就是手合的，不过她是完全不会 git （谁让她跟老板关系好呢）
一开始不懂为什么不让我提过多的 commit （指大于一条），后来在她后面观察了一下，她是对照每条 commit 的改动，手动复制到 master…
真的是佩服

[ryd994]

我个人是非常反对用 merge 。只用 rebase 和 cherty-pick 。因为有些 commit 可能是不想要的。所以 merge 不可取。release 分支上 cherry-pick 相应的 commit 。

merge 派和 rebase 派，选了一边就不能换。

[byte10]

@ryd994 啥情况。。rebase 跟 marge 本质没啥太大的区别，只是时间线有差异。cherry-pick 问题多多，容易出现漏掉。marge 出问题是因为分支管理出问题，大多数流程都是 PR 或者 MR ，比较好。

[ryd994]

@byte10 你看一下 git log 的可视化就知道了。merge 的优点是可以保存 feature branch 上的支线 commit 。

merge 产生的是一个“merge commit”，有多个父节点。这样的 commit 在 rebase 的时候非常蛋疼。也就是说，如果一个 branch 有过 merge ，那就基本告别 rebase 了。

rebase-and-squash 对人多的项目比较合适。因为开发人员水平不一，很多人的 feature branch 的历史都乱七八糟。squash 以后主分支上，一个 PR 对应一个 commit ，就非常干净。之后某个 release branch 需要 backport 的话也很方便，直接 cherry-pick 特定 commit 就行。

如果是 merge ，那就要保留对应的 feature branch 。backport 的时候直接从 feature branch 上 merge 。

通过 rebase 解决冲突，最终产物是树狀的历史。通过 merge 解决冲突，最终产物是网状的历史。

[ryd994]

@byte10 “cherry-pick 问题多多，容易出现漏掉” backport 的时候我就是不想要某些 commit
另外，你用法可能错了，cherry-pick 是可以一次性指定一段范围的 commit ，会一个一个 pick 过去。和 rebase 效果类似但是方向相反。

[byte10]

@ryd994 你说的 merge 和 rebase 的区别 是对的。但是 cherty-pick 有一个非常大的问题，无法判断 2 个分支的差异。也就是说你无法判断 A 分支包含了 B 分支的多少个 commit 点，要人肉的去比对，cherty-pick 非常破坏整个分支管理流程，一般在 hotfix 流程上会有场景使用。经常使用这个操作的话，最终无法判断 2 个分支是否有缺漏。