5

我正在使用 git-svn 针对我公司的 Subversion 存储库进行离线开发，该存储库是项目的记录存储库。为了启用管理可见性，我需要在 SVN 中维护我的功能分支。有时我需要在分支的生命周期内多次合并从主干到特性分支的更改。由于我需要在 SVN 中保持分支是最新的，所以我必须合并；一旦提交被推送到 SVN，我就无法重新设置提交。此外，git svn dcommit从合并提交中删除第二个父级。这意味着在第一次git merge将分支根标识为合并基础而不是最近的合并父项之后进行合并。因此，它试图重新合并已经合并的更改，这几乎可以保证令人讨厌的冲突。

当我在 SVN 中合并时，我手动指定了基本版本：

svn merge -r 49262:49608 $svn/trunk

git中有没有办法与手动指定的基本修订进行合并？

更新：

请注意，我需要指定两个修订版，基础修订版和父修订版。我有这样的历史

trunk: A -- B -- C -- D -- H -- I
             \         \
    feature:  E -- F -- G -- J -- K

但已删除和git svn dcommit之间的父关系。我需要将on与. 简单地运行GDIKD

$ git checkout feature
$ git merge trunk

将尝试与基础I而不是合并，这会重新应用并导致极端的合并冲突。使用 SVN 我会运行类似的命令KBDCD

$ svn switch $svn/feature
$ svn merge -r D:I $svn/trunk

但git merge没有指定基本版本的选项D。我正在寻找类似的东西

$ git merge --base D trunk

但这样的选择似乎不存在。

4

3 回答 3

4

（编辑：有关执行此操作的较低级别的方式，请参见以前的修订版，但这种方式是最快的）

  • feature使用正确的合并基础上的树进行 nonce 提交

    git checkout `git commit-tree -p $D -m - feature^{tree}`

  • 像往常一样将主干合并到那个

    git merge trunk --no-commit
git commit    # the two-stepper gets the commit message someplace known

  • 提交合并的树作为新的feature提示

    git commit-tree -p feature -p trunk -F .git/COMMIT_EDITMSG HEAD^{tree} \
        | xargs git checkout -B feature
于 2013-11-09T02:10:46.000 回答
0

您可以尝试git merge <commit hashcode>使用可以找到提交的哈希码的位置git log

更新：

根据您的修订，我认为您正在寻找的是以下内容。从做开始git branch D。您应该能够通过执行git status. 然后，做git checkout feature。然后做git merge newBranchFromD。这会将特征的状态置于来自 D 的合并状态，来自主干。

为了保持更清晰的提交历史记录，您还可以git rebase newBranchFromD在检出功能分支后进行操作。请注意，这会将 H 插入到提交历史记录中的正确位置，因此您最终会得到：

           trunkAtD: -- H -- I
                       /
后备箱：A -- B -- C -- D -- H -- I
    \ \
    特征： E -- F -- G -- H -- I -- J -- K

这与合并提交有点不同，因为 rebase 将所有提交按时间顺序放在提交历史记录中。您拥有的另一个选择是在提交时使用 --squash，这样合并就不会尝试自动提交。

谨慎使用 rebase，因为如果在您知道它发生了什么的情况下不使用它，它可能会导致意外结果。

于 2013-11-09T00:49:59.373 回答
0

这就是我们所做的。我们首先找到了丢失其“合并”的合并提交的哈希 - MISSING_MERGE，其次我们找到了该提交合并的提交 - MERGED_POINT。

然后我们去接收分支并创建了一个假提交

git merge -s ours MERGED_POINT --no-commit
git commit -m "Fake commit because MISSING_MERGE is not marked as a merge commit"

然后我们可以看到

git merge-base OURS THEIRS

我们现在再次有了正确的基础。

于 2014-06-03T12:00:25.270 回答