1

我在 git 分支中开发各种功能。当我想通过 git-svn 将我的代码签入 SVN 时，我执行以下操作：

git co feature_branch
git svn rebase
git co master
git svn rebase
git merge --no-ff feature_branch
git commit --amend
git svn dcommit

这工作得相当好，除非另一个开发人员在此过程中的任何时候提交给 SVN，在这种情况下：

  • 如果在我 rebase feature_branch 和 master 之间进行 SVN 提交，我会得到一个如下所示的日志：

*   4e6992a BUG-003 My SVN commit (containing cdb40ba and 3b18ea4)
|\
| * cdb40ba local commit 1
| * 3b18ea4 local commit 2
* | cf8a028 BUG-002 Another developer's SVN commit
|/
* 940c613 BUG-001 Another developer's SVN commit

  • 如果在我 rebase master 和 之间进行 SVN 提交svn dcommit，则后者由于合并问题而失败（在这种情况下，我会进行硬重置并重新开始）

如何在单个原子操作中完成此操作？

4

2 回答 2

3

我认为，由于 SVN 的工作方式，git-svn 无法解决这个问题（每个修订创建都是一个单独的事务，但您可以创建一个创建多个修订的事务）。也许您可以使用 SVN 锁来解决它，但是这种方法有其缺点。

Pure Git 将您所有的历史作为您需要的原子操作推送到一起。如果您有权访问您的 SVN 存储库，则可以将 SubGit 安装到其中并使用它将为您的 SVN 存储库创建的 Git 接口（纯 Git 接口，而不是 git-svn）。

于 2012-06-16T09:51:59.473 回答
0

我不明白你为什么要与--no-ff. 这总是会产生合并提交，我对您的第一个项目符号的理解是您希望避免这样做。

没有办法总是在单个原子操作中做到这一点。特别是，你的第二颗子弹几乎是不可避免的，尽管我认为你不需要回到开始来修复它。

这是我的做法：

  1. 查看包含要推送到 Subversion 的提交的分支：git checkout feature_branch。

  2. 检查我正在提交的内容以及提交到的位置：git svn dcommit --dry-run. 我通常会检查将要推出的提交的数量，并验证它们是否被提交到正确的 Subversion 分支。

  3. 如果我认为可能会有合并问题，git svn rebase. 不过，我通常不会为此烦恼，只有在第 4 步遇到错误时才这样做。

  4. 将更改推出：git svn dcommit. 如果遇到任何问题，请返回第 3 步。

注意我根本不涉及“master”分支。这大大减少了我需要做的合并量，因此在第 3 步和第 4 步之间其他人的提交可能会妨碍我自己的提交。

于 2012-06-18T09:03:36.920 回答