Question

我们使用分支机构来完成我们的工作，并在大多数情况下保持主干原始状态。在将我的更改从我的分支合并到主干之前，我想确保从svn / trunk到我的本地分支的最新更改。我花了一些时间来弄明白，但这是我提出的工作流程，我想知道是否有更好的方法。（在这个例子中，我是这个分支上唯一的一个，所以没有必要git svn rebase来改变这个分支）

git svn fetch
git co -b feature_branch svn/kastner/feature_branch
....work....commit...work...commit
git svn fetch
git merge svn/trunk --squash
git commit -m 'forward merge of svn/trunk'
git svn dcommit

我这样做的原因是：

没有壁球的git merge会添加一个指向trunk的git-svn-id，所以dcommit会推到那里
重新定位到svn / trunk会使这个分支完全脱离轨道

Answer 1

您在此处执行的操作是将svn / trunk中的更改合并到您的git功能分支，然后将这些更改提交给svn等效的功能分支。这意味着你在git和svn中都有分支，如果你单独使用它，这对我来说没什么意义。

如果你还没有按照上面描述的方式将trunk中的东西合并到这个分支，那么再次对svn / trunk重新分配分支应该可以正常工作。然后你应该只能将它保存在git中，并且当它在trunk中合并时，svn dcommit会将所有更改推送到那里，保留确切的提交。（这应该是保存历史的最佳方式。）

总而言之，这就是我最常使用的：

git svn fetch
git checkout -b my_branch svn/trunk
...work...commit...work...commit...
git svn fetch && git rebase svn/trunk
...see if it still works
git svn dcommit # commits all of this to svn trunk

Answer 2

我工作的公司也使用Subversion进行源代码管理。我正在使用不同的方法：我经常提交给我的本地Git存储库，但不想使用我的提交来淹没Subversion服务器，因为我有几个本地分支，每个分支最多提交2000个。将其提交给Subversion可能需要一个工作日的大部分时间。：）

# git svn fetch
# git checkout -b some-feature remotes/trunk
# (work, work, work, commit, commit, commit)
# git svn fetch
# git rebase remotes/trunk
# git checkout master
# git merge remotes/trunk    # updates to latest trunk
# git merge --squash some-feature
# git svn dcommit

通过这种方式，我的同事将我的结果视为单个（虽然相当大）的提交，Subversion服务器没有太多的工作，我仍然在本地完成我的完整开发。

我做错了吗？将SVN更改从trunk更改为git分支。使用merge --squash

2 个答案: