合并 git 后 git-svn dcommit 是否危险? [英] Is git-svn dcommit after merging in git dangerous?

问题描述

我尝试 git-svn 的动机是轻松的合并和分支.然后我注意到 man git-svn(1) 说:

My motivation for trying out git-svn is the effortless merging and branching. Then I noticed that man git-svn(1) says:

不建议在您计划的分支上运行 git-merge 或 git-pulldcommit 从.Subversion 不代表任何合并合理或有用的时尚；所以使用 Subversion 的用户看不到任何您所做的合并.此外，如果您从 git 合并或拉取SVN 分支的镜像分支，dcommit 可能会提交到错误的分支.

Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you've made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.

这是否意味着我不能从 svn/trunk(或一个分支)创建一个本地分支，破解，合并回 svn/trunk，然后 dcommit?我知道 svn 用户会看到在 svn pre 1.5.x 中合并的混乱情况一直是这样，但是还有其他缺点吗?最后一句话也让我很担心.人们经常做这些事情吗?

Does this mean I cannot create a local branch from svn/trunk (or a branch), hack away, merge back into svn/trunk, then dcommit? I understand that svn users will see the same mess that merges in svn pre 1.5.x have always been, but are there any other drawbacks? That last sentence worries me, too. Do people routinely do these kinds of things?

推荐答案

实际上，我在 git merge 上使用 --no-ff 选项找到了更好的方法.我以前使用的所有这些壁球技术都不再需要了.

Actually, I found an even better way with the --no-ff option on git merge. All this squash technic I used before is no longer required.

我现在的新工作流程如下:

My new workflow is now as follows:

• 我有一个master"分支，它是我提交的唯一分支，它克隆了 SVN 存储库(-s 假设您在存储库中有一个标准的 SVN 布局 trunk/、branches/ 和 tags/):

• I have a "master" branch that is the only branch that I dcommit from and that clone the SVN repository (-s assume you have a standard SVN layout in the repository trunk/, branches/, and tags/):

git svn clone [-s] <svn-url>

我在本地分支work"上工作(-b 创建分支work")

I work on a local branch "work" (-b creates the branch "work")

git checkout -b work

在本地提交到工作"分支(-s 以签署您的提交消息).在续集中，我假设您进行了 3 次本地提交

commit locally into the "work" branch (-s to sign-off your commit message). In the sequel, I assume you made 3 local commits

...
(work)$> git commit -s -m "msg 1"
...
(work)$> git commit -s -m "msg 2"
...
(work)$> git commit -s -m "msg 3"

• [最终] 将您不想在 SVN 服务器上看到的修改隐藏起来(通常您在主文件中注释一些代码只是因为您想加速编译并专注于给定的功能)

• [Eventually] stash the modifications you don't want to see committed on the SVN server (often you commented some code in the main file just because you want to accelerate the compilation and focus on a given feature)

(work)$> git stash

使用 SVN 存储库 rebase master 分支(从 SVN 服务器更新)

rebase the master branch with the SVN repository (to update from the SVN server)

(work)$> git checkout master
(master)$> git svn rebase

返回到工作分支并使用 master 进行 rebase

go back to the work branch and rebase with master

(master)$> git checkout work
(work)$> git rebase master

确保一切正常，例如:

Ensure everything is fine using, for instance:

(work)$> git log --graph --oneline --decorate

现在是时候使用这个美妙的 --no-ff 选项将work"分支中的所有三个提交合并到master"分支中

Now it's time to merge all three commits from the "work" branch into "master" using this wonderful --no-ff option

(work)$> git checkout master
(master)$> git merge --no-ff work

您可以注意到日志的状态:

You can notice the status of the logs:

(master)$> git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|  
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/  
* 21e20fa (git-svn) last svn commit

现在您可能想要编辑(amend)为您的 SVN 伙计们的最后一次提交(否则他们只会看到一个带有消息合并分支'工作'"的提交>

Now you probably want to edit (amend) the last commit for your SVN dudes (otherwise they will only see a single commit with the message "Merge branch 'work'"

(master)$> git commit --amend

最终在SVN服务器上提交

Finally commit on the SVN server

(master)$> git svn dcommit

回去工作并最终恢复您隐藏的文件:

Go back to work and eventually recover your stashed files:

(master)$> git checkout work
(work)$> git stash pop

这篇关于合并 git 后 git-svn dcommit 是否危险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！