Question

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

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

使用git svn rebase将更新带入主版本
在处理错误之前，请使用git checkout -b XXXXX
将更改提交到分支机构
将分支合并为master
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，然后仅对我现在想进行的提交回答“是”。但是我是否可以重新运行该命令并在以后取消提交较早的提交？这样做安全吗？

如果不是，那么最佳的工作流程是什么？我怀疑我不准备将这两个提交合并到master中，直到准备将它们提交给svn。

对于在网上阅读的有关保持线性git历史记录以避免混淆svn repo的警告，我保持警惕。

我正在使用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之后，以便我们可以在没有其他所有情况的情况下将其提交。

最简单的方法是interactive rebase对主控中的提交进行重新排序。

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推送/取消提交紧急的错误修复程序。

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

git svn dcommit提交不按顺序提交是否安全

1 个答案: