我正在尝试重组 GIT 存储库，其中充满了无组织的分支。现在我们想在那里做一些结构（开发、生产、功能......分支）并删除/压缩许多小更改。但是有些东西需要保持原样，因为有人在做这件事。
所以我创建了大结构，把旧的东西压在一起（没有人再对小错别字感兴趣了），基本上把所有东西都固定到今年年初。
但是现在问题来了 - 一些分支是活动的，无法完全压缩，无法删除/移动（直到新模式证明可以工作一段时间），并且内部包含许多小合并，如下所示：
jacks_branch
A-B-C-F-G-H-I-J-M-N-O-P ...
D-E/ K-L/
我想在适当的功能分支之上复制它，例如
feature_123
XX-YY
=>
XX-YY-C'-F'-G'-H'-I'-J'-M'-N'-O'-P' ...
D'-E'/ K'-L'/
（模式比较复杂，这是有问题的部分）
我想做类似的事情
git checkout feature_123
git cherry-pick C..P
但它会导致所有这些合并的冲突
error: could not apply E
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
I提交（合并）解决了所有这些冲突，但它没有应用，樱桃采摘停止
最好的出路是什么（除了从一开始就组织好）？
编辑 - 添加了示例：
我有
* 3b0a2b4 3.line Adam (HEAD, Adam)
* c04efb0 Just fixed merge from other computer
|
| * 3e5f111 2.line Adam_a
* | 897bfc3 2.line Adam_b
|/
* 308a3c5 1.line Adam
* 33f3119 === new year ==== (master)
* 436619b 1000.line
.............
* 0a12c01 4.line
* 41d763d 3.line
* dd1feb0 2.line
* 55aa2c2 1.line
* 84b12e9 Point zero
请注意，分支Adam冲突（3e5f111 和 897bfc3 分别将第 Adam_a 行和Adam_b添加到同一位置），开发人员 Adam 以某种方式在 c04efb0 中解决了这个问题（通过在那里编写完全不同的东西，比如Adam_* # it does not matter左右）
我想添加新的分支develop - 这很容易master
* 75675e1 === new_year === squashed 1.000 lines (HEAD, develop)
* 84b12e9 Point zero
现在我想添加分支feature_1（超过 develop 个）与 Adam 中的内容（但不必手动解决所有已经解决的冲突，我希望合并 （4444567） 与分支 Adam 相同）
* 555567 3.line Adam (HEAD, feature_1)
* 4444567 Just fixed merge from other computer
|
| * 3334567 2.line Adam_a
* | 2234567 2.line Adam_b
|/
* 1234567 1.line Adam
* 75675e1 === new_year === squashed 1.000 lines (develop)
* 84b12e9 Point zero
要得到这个：
* 555567 3.line Adam (HEAD, feature_1)
* 4444567 Just fixed merge from other computer
|
| * 3334567 2.line Adam_a
* | 2234567 2.line Adam_b
|/
* 1234567 1.line Adam
* 75675e1 === new_year === squashed 1.000 lines (develop)
| * 3b0a2b4 3.line Adam (Adam)
| * c04efb0 Just fixed merge from other computer
| |
| | * 3e5f111 2.line Adam_a (Adam_a)
| * | 897bfc3 2.line Adam
| |/
| * 308a3c5 1.line Adam
| * 33f3119 === new year ==== (master)
| * 436619b 1000.line
| * 0a12c01 4.line
| * 41d763d 3.line
| * dd1feb0 2.line
| * 55aa2c2 1.line
|/
* 84b12e9 Point zero
（稍后我会删除Adam和master）
我认为，与其试图重写历史，你（和你的团队）现在应该专注于使用你想使用的工作流程。这就引出了我的下一点，那就是如果你继续使用特定的 git 工作流程，而团队的其他成员继续使用你当前的工作流程，你可能不会成功。
假设仓库中的各个分支没有太大分歧，你和你的团队应该开始合并和整合，朝着你想要的仓库的样子，例如主分支和功能分支。
重写历史记录（例如使用变基）是很棘手的，因为这意味着自您正在修改或压缩的提交以来的每个提交也必须重写，这意味着这些提交的新版本不再与其他人的"旧"版本匹配。当在最近的历史记录中谨慎使用时，它可能很有用，但是重写整个存储库的历史记录并期望将其与积极开发相协调并不是我尝试过的事情。