今天晚上投产，所有需要投产的代码要合并到名为“231102”的分支上，然而大家都在一个名为“230915”的分支上做开发，部分功能还没有开发完，只能把开发完的代码从 230915 分支合并到 231102 上，请问有什么相对快捷又不影响他人开发的分支合并方法吗？
我上午的时候，在本地把 230915 分支代码向 231102 分支代码进行合并，遇到冲突的时候，只把我自己的代码合并过来了，其他人新写的代码没有做迁移。但是我代码尚未提交到远程库，这导致如下问题：
 | 1 murmur Nov 2, 2023 手合 master ，一行一行复制过来，我都这么干了 4 年了，早习惯了 |
| 2 murmur Nov 2, 2023 这样其实也挺好的，每次合一次都能看到底下人代码写的啥样，不行赶紧打回去，有些人 pull request 他是不看的过了扫描就给过来 |
 | 3 jokechen OP @murmur 然而本次投产的代码中，虽有一部分是我负责，但并不是我写的，很容易漏掉（从其他同事手里交接过来的，前情提要： t/982890#reply38 ） |
 | 4 lingex Nov 2, 2023 via Android 如果需要合并的提交是比较孤立完整的，可以用 cherry pick |
 | 5 JadePenG Nov 2, 2023  1 不应该一个开发任务是一个开发分支嘛，这样就直接在源头规避了 merge 冲突的问题。 |
 | 6 Avn Nov 2, 2023 这种情况不应该做 branch 级别的 merge ，应该做 commit 级别的 cherry pick 。 |
 | 8 zackzergzeng Nov 2, 2023 把 230915 上需要上线的提交 cherry-pick 到 231102 上 |
 | 9 scorpion91 Nov 2, 2023 把 230915 分支上的 commit 一个一个合过来，不要一次性合，如果发现有错误直接在本地分支回退就行了 |
| 10 zackzergzeng Nov 2, 2023 3 @jokechen 迁移为什么会丢记录啊，你们这个项目的仓库雷也太多了吧 |
 | 11 kuaner Nov 2, 2023 cherry-pick |
 | 12 Rorysky Nov 2, 2023 1 cherry-pick 这樱桃俺不是抢咧，俺是拾咧 |
 | 13 Avn Nov 2, 2023 @jokechen 迁移远程仓库应该在本地仓库添加 remote ，把代码和提交记录 push 到新的远程仓库。 如果现状是丢失提交记录的话，那应该基于 231102 创建新的分支，把需要合并的代码从 230915 分支找出来拷贝到新的分支里面，然后把新的分支合并到 231102 发版。新的分支同时也建议合并到 230915 ，虽然不会引起代码变化，但是可以提前解决以后 230915 合并到 231102 时可能出现的潜在问题。 总的来说，不能把 230915 直接合并到 231102 。 |
 | 14 IvanLi127 Nov 2, 2023 via Android 每个人自己 cherry pick 到自己的新分支，然后再往发布的分支合。 |
 | 15 Gaoti Nov 2, 2023 同意 @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 同时延期 摸鱼时间的回复，可能描述的还不太精准，仅供参考。要管理好分支，本质上还是要将各个开发环境独立开来 |
 | 16 victimsss Nov 2, 2023 现状 cherry-pick 吧，未来建议 feat 、fix 、docs 等都创建小分支，然后 merge 到公共分支，这样子分支也可以保留也可以 rebase |
 | 17 300 Nov 2, 2023 via Android @murmur 上家的小组长就是手合的，不过她是完全不会 git （谁让她跟老板关系好呢） 一开始不懂为什么不让我提过多的 commit （指大于一条），后来在她后面观察了一下，她是对照每条 commit 的改动，手动复制到 master… 真的是佩服 |
 | 18 ryd994 Nov 2, 2023 via Android 我个人是非常反对用 merge 。只用 rebase 和 cherty-pick 。因为有些 commit 可能是不想要的。所以 merge 不可取。release 分支上 cherry-pick 相应的 commit 。 merge 派和 rebase 派，选了一边就不能换。 |
 | 19 byte10 Nov 2, 2023 @ryd994 啥情况。。rebase 跟 marge 本质没啥太大的区别，只是时间线有差异。cherry-pick 问题多多，容易出现漏掉。marge 出问题是因为分支管理出问题，大多数流程都是 PR 或者 MR ，比较好。 |
| 20 ryd994 Nov 2, 2023 via Android @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 解决冲突，最终产物是网状的历史。 |
Select Language