代码之家 › 专栏 › 技术社区 › harmic

“git svn dcommit”提交不正常是否安全

git-svn svn git

1

harmic · 技术社区 · 7 年前

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

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

使用git svn rebase将更新带到master中
git checkout -b XXXXX
提交对分支的更改
将分支合并为主分支
git svn dcommit 将更改从主服务器推送回远程SVN repo

目前,我有两个变更集已经合并到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

* 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
|

1 回复 | 直到 7 年前

1

Schwern 7 年前

我很久没有使用gitsvn了,但是处理混合提交的技术应该是相同的。只要替换一下 push 具有 dcommit .

就像在Git中一样,撤消合并。然后把你的紧急补丁放到 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...

这些是我们的承诺自从从头到尾。你可以在编辑器中根据自己的喜好重新排序。我们想要 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

现在我们得走了回到紧急任务。首先,重新创建旧分支以保持其提交的活动。

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

主人 回到紧急任务。

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中删除,那么您可以从中推送/dcommit您的紧急bug修复 主人 .

一旦完成,你就可以合并了 old_branch 进入之内再次开始 .