2

这是我使用 git-svn 的正常工作流程：

  1. 为问题创建分支
  2. 在分支上做一些工作后提交
  3. 结帐大师
  4. svn 变基
  5. 结帐分行
  6. 变基大师
  7. 结帐大师
  8. 合并分支
  9. 提交

我的目标是让我的历史保持直线，并尽量减少合并带来的麻烦。

有没有办法用更少的步骤做到这一点？

4

3 回答 3

1

你在这里有两件事不一致。为了使您的历史保持在一条直线上，您需要重新设置基准。但是，变基意味着您必须在不同的代码库之上重新应用更改。这会引发一连串的冲突解决方案，您可能需要为每一个变基的提交执行这些解决方案。

我唯一能帮助你的是，如果你已经重新设置基准，你知道你将有一个快进合并。在这种情况下，您无需签出该分支即可将其向前移动。因此，要更新参考，您可以：

git push . my-branch:master

这将更新 master 以指向 my-branch 指向的位置，并且仅在它可以快速转发时才有效。不幸的是，它在这里对您没有帮助，因为您需要在分支上执行所需的操作。

回到您的工作流程问题，与简单合并相比，您将遇到更多冲突问题。

于 2012-06-08T12:06:44.967 回答
1

没有必要在中间做你的变基，当然也不需要交换到主分支来这样做。我的工作流程达到了同样的效果，因此是：

  1. 为问题创建一个分支：（如果我已经在我感兴趣的分支上git checkout -b issue remotes/trunk，可以省略）。remotes/trunk

  2. 做一些工作，然后提交。

  3. 将其直接推送到 Subversion 存储库：git svn dcommit. 仅当您编辑的文件已更改时，此操作才会失败。如果他们有，你会得到一个错误，所以做一个git svn rebase然后再试git svn dcommit一次。

    请注意，无需先将其合并到您的主分支中。

  4. 签出主分支：git checkout master.

  5. 重新设置主分支：git svn rebase.

    （可选）删除问题分支；master 和 issue 分支现在应该是相同的，就像之后git svn dcommit一样。git svn rebase

您可以git svn从任何分支执行命令；系统将根据父 Subversion 分支计算出提交或变基的位置。如果你想检查它感兴趣的 Subversion 分支，运行git svn dcommit --dry-run

特别是，master 分支并没有什么特别之处。事实上，我经常忽略它并跳过上面的步骤 4-5。我只是从一个问题分支交换到另一个问题分支，并且从不费心将主分支带到 Subversion 提示。

于 2012-06-08T13:12:45.957 回答
1

你可以试试SubGit而不是 git-svn。

SubGit 是一个服务器端解决方案。它允许 Git 访问您的 Subversion 存储库以及 Subversion 访问 Git 存储库。必须将 SubGit 安装到 Subversion 存储库中，即基本上添加必要的钩子，在每次推送和提交时进行转换：

$ subgit configure $SVN_REPOS
$ # Adjust $SVN_REPOS/conf/subgit.conf 
$ #     to specify your branches and tags
$ # Adjust $SVN_REPOS/conf/authors.txt 
$ #     to introduce svn author names to their git counterparts
$ subgit install $SVN_REPOS

之后，在 $SVN_REPOS/.git 有一个 Git 存储库，它与 Subversion 对应物不断同步。当为这个 Git 存储库配置远程访问时（例如通过git-http-backend），可以使用任何 Git 工作流和任何具有现有 Subversion 存储库的 Git 客户端。

对于您的情况，它看起来像这样：

$ git checkout -b foo
$ git commit
$ git checkout master
$ git merge foo or git rebase foo
$ git push

更多细节：

  • SubGit 在合并跟踪、行尾、mime 类型支持等方面比 git-svn 优越得多；
  • SubGit 是一个带有一些免费选项的商业工具；
  • 我是 SubGit 开发人员之一。
于 2012-06-18T15:59:51.370 回答