这是一个创建于 1070 天前的主题，其中的信息可能已经有所发展或是发生改变。
假设我有一个 Git 源。一开始只有一个 main 分支。后来，分出了一个 i18n 分支。
分裂以后，main 分支与 i18n 分支各自独立发展，各自积累了 100 多个新的 commit.
现在，发现程序有一个 bug，并且这个 bug 在这两个分支里面都有。于是，我在 main 里面修复了这个 bug 。修复量不大，也就十几行代码。请问有什么办法，能让我直接把这个修复的 commit 弄到 i18n 里面去。（前提条件：修复这个 bug 涉及到的文件，在两个 branch 里面完全一样。）
我不想切换到 i18n 分支以后，重新再写一遍这些代码。
 |
1
fffang 2021-05-14 11:37:57 +08:00
遴选 /cherry pick
|
 |
2
yeqizhang 2021-05-14 12:58:15 +08:00 via Android
我感觉可以从岔开的那点检出，修复 bug，推送一条分支 fixbug，然后另两条再合并这条分支
|
 |
3
EastLord 2021-05-14 13:03:17 +08:00
cherry pick
|
 |
4
anguiao 2021-05-14 13:52:10 +08:00
cherry-pick，有个项目是类似的情况，一直是这么操作的。
|
 |
5
mekingname OP @yeqizhang 那一点太古老了，已经找不到了。
|
 |
6
hwdef 2021-05-14 15:28:00 +08:00
cherrypick 最合适
|
 |
7
GeruzoniAnsasu 2021-05-14 16:14:22 +08:00
经验 1： 重写一遍最简单。
经验 2：200 行以内的代码重写一遍都比改历史简单。 100 多个 commit 了，数据结构什么的很可能已经早都变了，甚至 i18n 上已经有其它用来生成代码的新轮子了，pick 过去很可能要面临变量名全对不上的状况。我说的是亲身经历。 复制粘贴√ |
|
8
GeruzoniAnsasu 2021-05-14 16:16:52 +08:00
补充一下，cherry-pick 在两条分支上生成的是彼此独立的 commit，从历史上是完全看不出有关联性的，效果跟复制粘贴自行 commit 完全一样。所以还不如手动修复然后在 commit message 里标明 bugfix
|
 |
9
ladypxy 2021-05-14 16:25:16 +08:00 via iPhone
想保留历史就 git merge，不过要手动处理冲突了
|
|
10
mekingname OP @ladypxy 显然不可能用 merge 。分支差了 100 多个 commit，解冲突都会死人。
|
Select Language