我在内部Git-repository A中有这个内部项目，
我必须从外部Git-repository B添加和调整外部库中的大部分代码。
我没有添加B的总历史，我只是在一次提交中添加了所有当前代码（让我们称之为B3）（让我们称之为A5_B3'）
使用明确引用B3的提交消息。
然后我在一次额外提交中删除了我不需要的所有内容，并在下次提交时根据我的需要调整了代码。
A1 - A2 - A3 - A4 - A5_B3' - A6 - A7
/*
B1 - B2 - B3
"/*" = copy/cherry-pick/... (no 'real' reference/merge-point)
稍后的几个月（以及对A的很多提交），我需要来自外部Git-repository B的一些更新。
我添加了远程B，当然没有检测到共同的祖先，因为B被添加到中间而没有历史记录。
但是，我找到了description to line up the two SHA's using a graft，
所以我可以排列B的代码为'相等'（B3和A5_B3'）的点。
我甚至设法将我的本地存储库（B）中的更改从A合并到A18_B6'：
A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B6'
/* /
B1 - B2 - B3 - B4 - B5 - B6
但事实证明，我无法将此合并推送到我的远程存储库A。
（修改：我得到的错误是[remote rejected] master -> master (n/a (unpacker error))。）
考虑到这一点，这可能是合理的，因为我的远程远程存储库不知道B，
所以它可能不知道如何/在哪里查找/添加B4，B5和B6。
也许我可以从B（B4，B5，B6）挑选更改并将其添加到A17。
但是这样，B没有明确的合并，虽然 - 当然 - 我可能会调整提交消息。
（我知道，我开始的B3没有明确的合并，我会回到那里。）
A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B4' - A19_B5' - A20_B6'
/* /* /* /*
B1 - B2 - B3 - B4 - B5 - B6
我现在能够提出的唯一“解决方案”是从A_B添加单独的“A5 - 分支”（使用明确指代B的分支名称），
在该分支中挑选来自B（B4，B5，B6）的更改，并不时将该分支合并到A。< / p>
A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B6'
/ /
AB3' - AB4' - AB5' - AB6'
/* /* /* /*
B1 - B2 - B3 - B4 - B5 - B6
与此同时，还从另一个外部Git-repository C添加了另一个外部库中的一小部分代码。
这可能会得到错误修复，所以它甚至可能加倍麻烦......
我的问题是：
A_B - 分支'与樱桃选择（对不起，如果这是重复的。我试图寻找类似的东西。 我找到了许多关于将项目/分支与“完整”共同历史合并的答案。 我找到了一些需要单一合并的类似项目的答案。 但我想我可能需要稍后再进行一些bug修复。 但是，我可能缺少正确的Git术语/关键字来搜索。）
答案 0 :(得分：0)
首先，您的错误与您的合并无关。我从来没有这样的错误，如果没有进一步的背景，这是我能找到的最好的：git: can't push (unpacker error) related to permission issues
由于历史记录重写或您的历史记录早于服务器，您无法推送到“服务器”（git确实没有服务器）。就这样。如果您从服务器撤出，成功合并，然后推送，所有“原子”（没有其他人触及服务器），它将正常工作。
所以，如果我在你的位置上，并且我有这个问题，那么在重新开始时我会检查那个问题是什么并继续前进。 您的合并策略没有任何问题。
此外，避免挑选。从我的经验来看，这通常是一件坏事，因为它不会在任何地方保存参考（也许有一种我不知道的方式）。但有时候，很少见，它很有用。然后，我写它的提交“樱桃挑选”或甚至添加从哪里（再次，也许有一个更好的方法，但因为我很少这样做，无论如何我不在乎那么多）。有一件事是肯定的：如果你做了太多樱桃采摘，你就是做错了。回到basics。