'git svn dcommit‘的提交是否安全？

Question

我正在一个拥有主subversion存储库的项目中工作。

我已经开始使用本地的git和git-svn桥。我的工作流程是：

• 使用git svn重基将更新带到主服务器中。
• 在处理bug之前，使用git checkout -b XXXXX创建一个分支
• 向分支提交更改
• 把分支合并成师父
• 将更改从git svn dcommit推送回远程SVN

目前，我有几个变更集已经合并到master中，但还没有提交回SVN。我还不能推送这些文件，因为它们正在等待其他依赖项，但与此同时，我需要推出另一个紧急修复程序。

我的主人中的git log现在看起来如下所示：

* 5ac10e3 (HEAD, master, b11859) Bug#1234: Urgent Bug Fix
* 2c0f704 Bug#1001 Some Large Feature
* beb3e0c Bug#1002 Another Large Feature
* c84efc2 (origin/trunk) Bug#1003 Already committed stuff

我想要提交5ac10e3，但推迟到稍后某个时候才开始使用2c0f704和beb3e0c。

看来我可以git svn dcommit --interactive，然后回答“是”，只对我现在想要做的提交。但是，我是否能够重新运行该命令，然后再提交之前的提交呢？这样做安全吗？

如果没有，使用的最佳工作流是什么？我怀疑，在我准备好将它们提交到svn之前，不应该将这两个提交合并到master中。

对于我在网上读到的关于需要保持线性git历史以避免弄糟svn回购的警告，我非常警惕。

我正在使用git 1.8.3.1开发Centos 7。

更新：git log --graph --decorate (应@schwern的请求)

* commit 5ac10e3937ef4e5b95823c73e03c893bd29b22f5 (HEAD, master, b11859)
| Author: harmic <harmic@xxxxxxxxx>
| Date:   Tue Oct 23 15:23:21 2018 +1100
|
|     Bug#1234: Urgent Bug Fix
|
* commit 2c0f7046282d4b84650b9d3a05382ad245755496
| Author: harmic <harmic@xxxxxxxxx>
| Date:   Tue Oct 23 13:36:58 2018 +1100
|
|     Bug#1001 Some Large Feature
|
* commit beb3e0c85d55450a248a277230f6a3fbbc5dc529
| Author: harmic <harmic@xxxxxxxxx>
| Date:   Mon Oct 22 12:12:17 2018 +1100
|
|     Bug#1002 Another Large Feature
|
* commit c84efc25bd9d526dafb9090a2b03fc7cfca46edd (origin/trunk)
| Author: eharmic <eharmic@44605e08-610d-0410-9c87-3f595476ec80>
| Date:   Wed Oct 24 03:38:39 2018 +0000
|
|     Bug#1003 Already committed stuff
|
|     git-svn-id: svn://svn.company.com/proj/trunk@13941 44605e08-610d-0410-9c87-3f595476ec80
|

Answer 1

我已经很长时间没有使用git-svn了，但是消除混合提交的技术应该是相同的。只需将push替换为dcommit即可。

目前，我有几个变更集已经合并到master中，但还没有提交回SVN。我还不能推送这些文件，因为它们正在等待其他依赖项，但与此同时，我需要推出另一个紧急修复程序。

就像在Git中一样，撤销合并。然后把你的紧急解决方案放到master上。现在，紧急修复已经与其他工作分离，您可以推送master。

查看您的回购没有合并提交，合并一定是一个快速转发。

首先，摆脱b11859。它只会保持旧的提交活着，而我们洗牌的东西。只是个标签。我们稍后再做。

git branch -d b11859
git log --graph --decorate --all

* 5ac10e3 (HEAD, master) Bug#1234: Urgent
* 2c0f704 Bug#1001
* beb3e0c Bug#1002
* c84efc2 (origin/trunk) Bug#1003

我们希望在origin/trunk之后立即进行紧急修复，这样我们就可以不使用所有其他方法就可以提交它。

最简单的方法是使用一个交互重基来重新排序主服务器中的提交。

git checkout master
git rebase -i origin/trunk

这样就会出现这样的编辑：

pick e881c96 Another large feature
pick c96a462 Some Large Feature
pick f848cca Urgent

# Rebase ba50aa8..f848cca onto ba50aa8 (3 commands)
#
# Commands:
...a bunch of instructions you should read...

这些是从第一次到最后在master上提交的origin/trunk。你可以根据你的喜好在编辑中重新排序。我们希望Urgent是第一位的。

pick f848cca Urgent
pick e881c96 Another large feature
pick c96a462 Some Large Feature

那就存钱退出吧。你的承诺将被重新排序。如果有任何冲突，请修复它们并按照说明进行操作。

git log --graph --decorate --all

* c96a462 (HEAD, master) Bug#1001
* e881c96 Bug#1002
* f848cca Bug#1234: Urgent
* c84efc2 (origin/trunk) Bug#1003

现在，我们需要将master移回紧急提交。首先，重新创建旧的分支，以保持其提交活动。

git branch old_branch
git log --graph --decorate --all

* c96a462 (HEAD, master, old_branch) Bug#1001
* e881c96 Bug#1002
* f848cca Bug#1234: Urgent
* c84efc2 (origin/trunk) Bug#1003

然后将master移回紧急提交。

git branch -f master f848cca
git log --graph --decorate --all

* c96a462 (HEAD, old_branch) Bug#1001
* e881c96 Bug#1002
* f848cca (master) Bug#1234: Urgent
* c84efc2 (origin/trunk) Bug#1003

现在其他更改已经从主版中删除了，您可以只从master中推送/提交您的紧急bug修复程序。

一旦完成，您可以再次将old_branch合并到master中，并启动b11859。