3

我在我们的内部 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是在中间添加的并且没有历史记录。但是，我找到了使用 a 排列两个 SHA 的描述graft，因此我可以排列代码来自B“相等”（B3和A5_B3'）的点。我什至设法将更改 from 合并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. 但是这种方式没有明确的合并 from 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-branch”，从该分支中​​的( , , ) 中挑选更改，然后合并该分支时不时地进入。A5BBB4B5B6A

A1 - A2 - A3 - A4 - A5_B3' - A6 - A7 - ... - A17 - A18_B6'
                      /                             /
                    AB3'  -  AB4'   -  AB5'    -  AB6'
                   /*        /*        /*        /*
        B1 - B2 - B3     -  B4     -  B5     -  B6

同时，还添加了来自另一个外部 Git-repository 的另一个外部库的一小部分代码C。这可能会得到错误修复，所以它甚至可能使麻烦加倍......

我的问题是：

  • 如果我们可以重新开始，添加（部分）B（和 C）的最佳实践是什么
  • 鉴于目前的情况，有没有比这个A_B带有樱桃挑选的“-branch”的其他/更好的解决方案

（对不起，如果这是重复的。我试图寻找类似的东西。我找到了许多关于合并具有“完整”共同历史的项目/分叉的答案。我找到了一些关于需要单个合并的类似项目的答案。但我猜稍后我可能需要进行更多的错误修复。但是，我可能缺少正确的 Git 术语/关键字来搜索。）

4

1 回答 1

0

首先，您的错误与您的合并无关。我从来没有遇到过这样的错误，如果没有进一步的上下文，这是我能找到的最好的：git: can't push (unpacker error) related to permission issues

由于历史记录重写或您的历史记录比服务器旧，您无法推送到“服务器”（git 没有服务器，真的） 。就这样。如果您从server拉出，成功合并，然后推送，所有“原子”（没有其他人接触过server），它会工作得很好。

因此，如果我处于您的位置，并且在推动时遇到了问题，那么在重新开始时，我会检查问题所在并继续前进。你的合并策略没有错。

另外，避免采摘樱桃。根据我的经验，这通常是一件坏事，因为它没有保存它来自哪里的参考（也许有一种我只是不知道的方法）。但有时，很少见，它是有用的。然后，我在它的提交中写“樱桃采摘”，甚至添加来自哪里（同样，也许有更好的方法，但因为我很少这样做，所以我不太在意）。有一件事是肯定的：如果你采摘太多樱桃，那你就做错了。回到基础。

于 2013-07-23T16:39:34.870 回答