1
XiLingHost 2023-07-11 10:31:47 +08:00
试试 cherry-pick 吧
|
2
xiaoxuxu 2023-07-11 10:35:22 +08:00
这种只能 cherry-pick 然后手工解决冲突了。如果还想再合并回 main 可以先 merge 或者 rebase main
|
3
E0421 OP @XiLingHost @xiaoxuxu 谢谢回复。。忘了补充 因为我们提交合并请求里带有 excel 这种文件。。好像 cherry-pick 不过去
|
4
fanyer 2023-07-11 10:47:51 +08:00
checkout from A, rebase main, pick B
|
5
wellhome 2023-07-11 11:27:04 +08:00
```
git checkout B git rebase A ``` rebase 把 B 的工作基于 A 的基础之上。 |
6
virualv 2023-07-11 12:53:17 +08:00 via iPhone
在 A 分支找到需要的提交,把这些提交按顺序 cherry-pick 到 B 分支
|
7
E0421 OP |
8
aqw012 2023-07-11 13:14:27 +08:00
首先,A 分支里面的功能很难通过 cheery-pick 处理。大概率 commit 并不是按照单一功能来提交的,并且后续的 bug 修复也会产生非常多的 commit 。所以 cherry-pick 这条路走不通。同理 rebase ,merge 之类的也很难
我建议是如果 A 里面的功能是对 main 的架构完善和补充,可以整理出来这部分代码合回到 main 中 如果只是特定功能或者业务逻辑处理,并且除了 B 难以再复用,那就直接用现在的方案,拷贝过来对比看 如果是通用业务逻辑,可以基于 main 拉取一个分支 C ,再将 A 中代码沉淀到此分支。B 分支再 rebase C |
9
mingsi 2023-07-11 14:38:02 +08:00 via Android
支持 8 楼的建议,另外我觉得你们的问题是软件架构层次框架没有做好,本该分离的东西耦合在一起,版本控制工具解决不了软件架构的问题。
|
10
unco020511 2023-07-11 14:38:19 +08:00
B 要用 A 的部分代码,那当然是 cherry-pick
|
11
LunarG 2023-07-11 14:49:44 +08:00
要我就把 A 分支整理一遍,至少把 commit 分为前面是通用代码,后面是客制化内容,通用代码部分合入主干,之后 B rebase 主干从这里拉出来。如果通用部分合不了主干,至少也能从这里拉出 B 分支
|
12
harrozze 2023-07-11 15:26:10 +08:00
@unco020511 #10 cherry-pick 是对完整 commit pick ,不能对其中每个 commit 的每个文件的多处修改单独 pick 。
还可以 git diff main > patch 以后,单独给 B 打 patch 。excel 文件那种就只能 git checkout A -- xx.exml 然后再 git add 了。 总体感觉这项目的 git 管理有段乱 |