Question

我在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，在这种情况下：

如果在我改变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 dcommit之间进行SVN提交，后者由于合并问题而失败（在这种情况下我会进行硬重置并重新开始）

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

Answer 1

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

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

Answer 2

我不理解您与--no-ff合并的原因。这总是会产生合并提交，而我对你的第一颗子弹的理解是你想避免这样做。

在单个原子操作中无法始终执行此操作。特别是，你的第二颗子弹几乎是不可避免的，虽然我不认为你需要马上回到开始修复它。

以下是我的表现：

查看包含要推送到Subversion的提交的分支：git checkout feature_branch。
检查我提交的内容以及我提交的内容：git svn dcommit --dry-run。我通常会理智地检查要推出的提交数量，并验证它们是否已提交到正确的Subversion分支。
如果我认为可能会出现合并问题git svn rebase。不过，我通常不会为此烦恼，只有在第4步遇到错误时才会这样做。
推送更改：git svn dcommit。如果遇到任何问题，请返回第3步。

注意我不会涉及＆＃34;主人＆＃34;分支。这大大减少了我需要做的合并量，从而缩短了第3步和第4步之间的时间，其他人的提交可能会妨碍我自己。

如何使用原子git-svn dcommit操作保留本地分支历史记录？

2 个答案: