'git svn dcommit' 乱序提交是否安全

Question

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

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

使用 git svn rebase
在处理错误之前，使用 git checkout -b XXXXX
提交对分支的更改
将分支合并到 master
git svn dcommit 将更改从 master 推送回远程 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，然后仅针对我现在想进行的提交回答 'yes'。但是我是否能够重新运行该命令并稍后重新提交较早的提交？这样做安全吗？

如果不是，最好的工作流程是什么？我怀疑在我准备好将它们提交到 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.

At the moment, I have a couple of changesets that have been merged into master but not yet dcommitted back to SVN. I can't push these just yet because they are waiting on other dependencies, but meanwhile I need to push out another urgent fix.

就像在 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 之后立即进行紧急修复，这样我们就可以提交它而无需其他所有内容。

最简单的做法是 interactive rebase 重新排序 master 中的提交。

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 中删除，您可以 push/dcommit 只是 master 的紧急错误修复。

完成后，您可以再次将 old_branch 合并到 master 并开始 b11859。

'git svn dcommit' 乱序提交是否安全

Is it safe to 'git svn dcommit' commits out of order

git

svn

git-svn