Question

我在家里使用Arch Linux版本的git版本1.8.5.3，在工作中使用Ubuntu 13.10版本的git版本1.8.1.2。在工作中，我们使用svn，所以我使用git svn处理它。

我在工作和家里使用git svn检查了svn存储库。包含git-svn-id的提交消息是相同的。作者和日期也是如此。但是，生成的提交哈希值不一样。

git svn fetch && git svn rebase

工作正常。但是，如果我尝试合并我在其中一个存储库上通过两者之间的git进行的一些提交，git自然无法检测父节点并吐出合并错误。

我在想，这只能归因于哈希计算的变化。这也会破坏其他git存储库，所以这可能是与git svn相关的问题。

首次修改

git log --pretty=raw

显示所有提交的不同父级。这解释了不同的哈希，但这首先是如何发生的呢？事实证明，如果我一直回到第一次提交，他们确实有相同的父母，因此是正确的哈希。所以在某个地方，某些东西必须改变......

第二次修改

使用

找到最后一个常见的提交哈希

git merge-base branch1 branch2

以下提交是一个svn合并分支。这是预期的行为吗？

第三次修改

使用什么工作

git cherry-pick hash

并逐一申请提交......

的更新 的

我的全部错。我在工作时检查了整个svn回购，但只检查了家中的行李箱。这就是为什么提交哈希值从两个svn分支的合并开始是不同的。

Answer 1

我知道这种情况，我自己通过git-svn和一些同事一起使用SVN存储库。

您基本上有两个选择：

简单的方法是只通过SVN共享代码。这是一个简单的解决方案，因为你只使用Git作为一个具有强大本地能力的高级SVN客户端。这里唯一的警告是：永远不会变得已经进入SVN的提交！或者使用与rebase等效的操作。 Git-svn在内部使用git-rebase来同步进入SVN的更改，而无需本地副本注意，并且必须重新排序本地提交。

如果您认为通过Git共享代码是一个好主意，不涉及SVN，事情会变得更加复杂。

首先，您应该从SVN克隆存储库开始。此存储库应该是每个人的主服务器，它应该包含远程SVN分支，以及您可能需要的SVN中每个分支的本地跟踪分支。如果需要，您也可以在以后创建它们。

要将存储库存储到新计算机，请将整个repo目录（包括.git目录）复制到新计算机。

要共享代码，请在某处创建一个远程Git仓库，并将其添加为每个本地仓库中的新远程。然后你可以推。

小心不要推动跟踪SVN的分支！您现在的代码共享世界分为两种分支：分支是Git-only。然后你可以把它推到你想要的任何其他Git仓库。或者分支正在跟踪SVN分支。然后你不能把它推到任何地方共享代码。

使用Git-only分支，Git的通常规则适用：在重新定义被推送的任何内容时要小心（即不要重新绑定！）。

对于SVN分支，情况有所不同。我自己的工作流程是这样的：

git checkout master
git add stuff 
git commit 
git push                  // regular GIT workflow until here...
git checkout svntrunk     // name of the local branch tracking SVN trunk
git svn fetch             // get all updates from SVN in any branch
git svn rebase            // update trunk in local svntrunk tracking branch
git merge master --no-ff  // merge local master to SVN - fast-forward is not allowed
                          // because SVN has no way of be alike - your changes have
                          // to be a regular commit in the SVN branch
git svn dcommit           // move that commit into SVN repo
git svn tag v0.0.1-alpha  // optional, but tagging in SVN only works after dcommit
git checkout master       // back to work

更新与SVN分支相关的分支使用rebase操作。因此，应用通常的Git规则来推动一个重新分支的分支，很明显这不起作用！所以不要推动SVN跟踪分支。不要拉它们。只有它们本地并从SVN更新它们。

这个双分支工作流程不是很好。它允许您通过Git与您的同事共享代码，但它将每个必须在SVN存储库中的分支加倍。并且根据合并的人数，svn跟踪分支将包含许多实际他们的合并提交的提交，但是您的本地Git repo将不会将它们识别为合并。因此，本地Git仓库中的SVN分支只知道您的合并。

如果你的一些同事直接使用SVN，没有Git，情况会变得更糟。这样，您还必须将svntrunk中的更改合并回master。我没有这方面的经验，但我会说在这种情况下最好避免通过Git共享代码，并保持在单个git-svn repo情况下。否则它会变得非常混乱。

将两个git-svn存储库与常规git提交合并在一起

1 个答案: