使用 git-svn：拉取、合并还是变基？

Question

我一直在努力克服git/git-svn的学习曲线，昨晚在这个过程中犯了一个非常非常糟糕的错误。虽然后来已经纠正了它，但我希望能够理解我所犯的错误。

我有一个svn仓库，从中克隆了主干和分支（由于我们不处理标签，所以忽略了标签）。使用git，我为每个我目前需要处理的分支创建了本地分支：

$ git checkout -b trunk svn/trunk
$ git checkout -b feature1 svn/branches/development/feature1
$ git checkout -b maint svn/branches/maintenance/previous-version

我将feature1分支设置为活动分支，并在离开几天前进行了一些更改。昨天回来后，我希望将任何已经应用到主干的更改整合到feature1分支中，以便使用最新版本进行工作。首先，我通过 git svn rebase 对所有分支进行了完整的更新（没有其他人对feature1分支进行过修改）。从我的svn仓库中，我把所有内容都更新到了最新状态，然后尝试进行变基。

当feature1为我的活动分支时，我执行了“git rebase trunk”，以为我将会从主干中将更改合并到feature1分支中。结果证明我非常、非常之错。在合并所有冲突后，我执行了git svn dcommit，发现我的更改已应用于主干上。

我的第一个问题很简单，我的思路出了什么核心错误？我的第二个问题是，在阅读和搜索了很多资料之后，我看到有些人推崇拉取（pulls）、合并（merges）和变基（rebases）。考虑到我想要将一个本地分支中应用的更改合并到另一个本地分支中，我应该做什么？在这种情况下，什么是最佳实践？

感谢您的帮助。

- Rob Wilkerson

Answer 1

你遇到的问题是由于 rebase 命令行语法与你（我认为非常合理的）期望不匹配。

$ git checkout feature1
$ git rebase trunk

这个序列将未共享的feature1提交添加到trunk的HEAD上，而您期望它将新的trunk提交放到feature1的HEAD上。 实际的语法在你知道Git数据模型是如何实现的时候还是有一定意义的（这无疑就是为什么它是这样的方式）。但对我来说，它的功能效果与我相反。最好把它当作任意构造学习，不要试着有所期待。

你理解如何使用git-svn与SVN存储库交互是正确的。因此，请忽略您在Google搜索中找到的关于推送、拉取和合并的信息 - 很多人几乎都认为在git和svn中推送、拉取和合并是相同的。但"几乎正确"仍是错误的。

- Paul

---

你说得对，我不熟悉数据模型的实现（有好的URI吗？）。如果我要阅读我的变基语句，应该将其理解为“git rebase [从活动分支到]主干”，还是这样太过局限了？谢谢。 - Rob Wilkerson

“从底层开始学习Git”（http://www.newartisans.com/blog_assets/git.from.bottom.up.pdf）和“Git内部原理”（http://peepcode.com/products/git-internals-pdf）对了解Git的结构非常有帮助。（“Git内部原理”售价9美元；我不建议在同一站点购买关于Git的屏幕录像）。 - Paul

这是对命令的很好理解。由于在许多git命令中，被操作的对象是已检出的分支，因此我发现很难记住。 - Paul

我发现最酷的是：计算机科学家的Git http://eagain.net/articles/git-for-computer-scientists，但我猜你在此期间已经找到了它。 - inger

Answer 2

你应该使用git svn clone -s来克隆完整的svn树，包括所有分支。从那时起，在主分支中使用git svn rebase和git svn dcommit来处理svn，你可以为自己的私人使用创建常规的git分支。

- Marko

---

但这并没有真正回答问题。我知道如何使用git-svn从Svn获取和提交代码。我正在尝试理解在将代码提交回去之前如何在本地分支上移动它。我认为这与svn连接无关，都是git的内容。 - Rob Wilkerson

我发现这很有用 :) 我不知道我应该使用 git svn rebase 而不是 git svn pull。 - Sridhar Sarnobat