3

我们使用树枝来做我们的工作，并在很大程度上保持树干的原始状态。在将我的更改从我的分支合并到主干之前，我想确保我已经从 svn/trunk 获得了最新的更改到我的本地分支。我花了一点时间才弄清楚，但这是我想出的工作流程，我想知道是否有更好的方法。（在这个例子中我是这个分支上唯一的一个，所以不需要 git svn rebase 来改变这个分支）

git svn 获取
git co -b feature_branch svn/kastner/feature_branch
....工作....提交...工作...提交
git svn 获取
git 合并 svn/trunk --squash
git commit -m '前向合并 svn/trunk'
git svn dcommit

我这样做的原因是：

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

2 回答 2

1

您在这里所做的是将更改从 svn/trunk 合并到您的 git 功能分支，然后将这些更改提交到与您的功能分支等效的 svn。这意味着您在 git 和 svn 中都有分支，如果您单独处理它，这对我来说没有太大意义。

如果您还没有按照上面描述的方式将主干中的内容合并到此分支，那么将分支重新设置为 svn/trunk 应该可以正常工作。然后你应该能够只将它保存在 git 中，当需要将它合并到主干时，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
于 2009-09-06T07:00:41.003 回答
0

我工作的公司也使用 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 服务器没有太多的工作，我仍然在本地拥有完整的开发线。

于 2009-09-07T07:02:41.120 回答