这是一个创建于 759 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天晚上投产，所有需要投产的代码要合并到名为“231102”的分支上，然而大家都在一个名为“230915”的分支上做开发，部分功能还没有开发完，只能把开发完的代码从 230915 分支合并到 23102 上，请问有什么相对快捷又不影响他人开发的分支合并方法吗？
我上午的时候，在本地把 230915 分支代码向 231102 分支代码进行合并，遇到冲突的时候，只把我自己的代码合并过来了，其他人新写的代码没有做迁移。但是我代码尚未提交到远程库，这导致如下问题：
- 我自己代码合并过来后，发现有两个类没有正确合并，也就是说冲突处理出现了错误，所以想着再做一次 merge ，结果由于我刚刚已经处理过一次冲突了，git 直接把这两个类给跳过了，没有办法再进行下一次合并。
- 由此联想到，其他人想要合并自己的代码到生产分支，也会出现第 1 点问题，由于冲突都被我处理过了，所以代码没有办法合并过来。会对别人有影响。
第 1 条附言 2023-11-02 17:04:16 +08:00
本帖完结。
截止到现在为止，初步完成了自己的代码的分支迁移。我是用`idea compare with branch`一个一个比对着提的代码。目前项目可以启动，测试了一个看起来问题不大。不知道上线后会不会冒出一堆其他奇奇怪怪的问题来。
截止到现在为止，初步完成了自己的代码的分支迁移。我是用`idea compare with branch`一个一个比对着提的代码。目前项目可以启动，测试了一个看起来问题不大。不知道上线后会不会冒出一堆其他奇奇怪怪的问题来。
 | 1 murmur 2023-11-02 13:13:57 +08:00 手合 master ，一行一行复制过来，我都这么干了 4 年了，早习惯了 |
| 2 murmur 2023-11-02 13:14:37 +08:00 这样其实也挺好的，每次合一次都能看到底下人代码写的啥样，不行赶紧打回去，有些人 pull request 他是不看的过了扫描就给过来 |
 | 3 jokechen OP @murmur 然而本次投产的代码中，虽有一部分是我负责，但并不是我写的，很容易漏掉（从其他同事手里交接过来的，前情提要： t/982890#reply38 ） |
 | 4 lingex 2023-11-02 13:17:21 +08:00 via Android 如果需要合并的提交是比较孤立完整的，可以用 cherry pick |
 | 5 JadePenG 2023-11-02 13:21:40 +08:00  1 不应该一个开发任务是一个开发分支嘛，这样就直接在源头规避了 merge 冲突的问题。 |
 | 6 Avn 2023-11-02 13:26:08 +08:00 这种情况不应该做 branch 级别的 merge ，应该做 commit 级别的 cherry pick 。 |
 | 8 zackzergzeng 2023-11-02 13:40:05 +08:00 把 230915 上需要上线的提交 cherry-pick 到 231102 上 |
 | 9 scorpion91 2023-11-02 13:40:32 +08:00 把 230915 分支上的 commit 一个一个合过来，不要一次性合，如果发现有错误直接在本地分支回退就行了 |
| 10 zackzergzeng 2023-11-02 13:41:13 +08:00 3 @jokechen 迁移为什么会丢记录啊，你们这个项目的仓库雷也太多了吧 |
 | 11 kuaner 2023-11-02 13:42:22 +08:00 cherry-pick |
 | 12 Rorysky 2023-11-02 13:42:39 +08:00 1 cherry-pick 这樱桃俺不是抢咧，俺是拾咧 |
| 13 Avn 2023-11-02 13:43:59 +08:00 @jokechen 迁移远程仓库应该在本地仓库添加 remote ，把代码和提交记录 push 到新的远程仓库。 如果现状是丢失提交记录的话，那应该基于 231102 创建新的分支，把需要合并的代码从 230915 分支找出来拷贝到新的分支里面，然后把新的分支合并到 231102 发版。新的分支同时也建议合并到 230915 ，虽然不会引起代码变化，但是可以提前解决以后 230915 合并到 231102 时可能出现的潜在问题。 总的来说，不能把 230915 直接合并到 231102 。 |
 | 14 IvanLi127 2023-11-02 13:45:45 +08:00 via Android 每个人自己 cherry pick 到自己的新分支，然后再往发布的分支合。 |
 | 15 Gaoti 2023-11-02 13:52:46 +08:00 同意 @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 2023-11-02 13:57:40 +08:00 现状 cherry-pick 吧，未来建议 feat 、fix 、docs 等都创建小分支，然后 merge 到公共分支，这样子分支也可以保留也可以 rebase |
 | 17 300 2023-11-02 14:09:06 +08:00 via Android @murmur 上家的小组长就是手合的，不过她是完全不会 git （谁让她跟老板关系好呢） 一开始不懂为什么不让我提过多的 commit （指大于一条），后来在她后面观察了一下，她是对照每条 commit 的改动，手动复制到 master… 真的是佩服 |
 | 18 ryd994 2023-11-02 14:48:59 +08:00 via Android 我个人是非常反对用 merge 。只用 rebase 和 cherty-pick 。因为有些 commit 可能是不想要的。所以 merge 不可取。release 分支上 cherry-pick 相应的 commit 。 merge 派和 rebase 派，选了一边就不能换。 |
 | 19 byte10 2023-11-02 16:12:23 +08:00 @ryd994 啥情况。。rebase 跟 marge 本质没啥太大的区别，只是时间线有差异。cherry-pick 问题多多，容易出现漏掉。marge 出问题是因为分支管理出问题，大多数流程都是 PR 或者 MR ，比较好。 |
| 20 ryd994 2023-11-02 19:57:17 +08:00 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