本文介绍了git svn 工作流 - 功能分支和合并的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我现在使用 git-svn 和以下工作流程

I am using git-svn with the following workflow now

git clone <SVN TRUNK URL> #done once

随后当我处理一个功能时

subsequently when I work on a feature

git branch featureZ
git checkout featureZ
#make edits for featureZ
git commit

git checkout master
git svn rebase # fetch changes from server

git checkout featureZ #go back to branch
#git merge master
git rebase master #get the changes from SVN->master onto the branch now. Optional if I want the branch to be current. (EDITED: Got from the answer given below)

#make edits for featureZ
git commit #featureZ completed

git checkout master
git merge featureZ #getting featureZ onto master. Prepare to send to SVN

git svn dcommit #push featureZ back to SVN

现在,当我将特性 git 合并到 master 时,有一些注意事项,featureZ 分支中的所有单独提交都合并为一个,这对我来说很好.

Now some points of note when I do git merge of feature onto master, all the individual commits in featureZ branch gets merged as one which is fine with me.

提交消息被替换为与 featureZ 合并".这可以通过 merge fmt msg.

The commit message is replaced as "merged with featureZ". That can be fixed with merge fmt msg.

现在我的问题是此工作流程是否有任何问题或需要处理.我在 git-svn 手册 中读到,在使用 git svn 时不应进行合并.我在我的工作流程中所做的是他们所指的吗?如果是这样会导致什么样的问题?一件事是我不想做一些与 SVN 主线混乱的事情.

Now my question isIs there anything that can go wrong with this workflow or needs to be taken care of. I read in git-svn manual that merge should not be done when working with git svn. Is what I am doing in my workflow is what that they are referring to? if so what kind of problem will it cause? One thing is I don't want to do something that messes with the SVN mainline.

推荐答案

SVN 无法处理非线性历史(它只是没有表示法).所以你想要做的是一个 rebase 而不是合并,因为它保留了 SVN 的线性历史(这在 git-svn 手册页 这里.

SVN cannot handle non-linear history (it simply has no notation of it). So what you want to do is a rebase instead of a merge as it preserves linear history with SVN (this is indicated in on the git-svn man page here.

详细来说,线性历史是微不足道的.他们走直线(A 到 B 到 C 到 D).而非线性历史可以从(A 到 B 到 C,B 到 D,然后 C + D 到 E——换句话说,它们会发芽成分支).

To elaborate, linear histories are trivial. They go in a straight line (A to B to C to D). Whereas non-linear histories can go from (A to B to C, B to D then C + D to E--in other words, they off sprout into branches).

变基会给你一个线性的历史.请记住,rebase 应该从您的本地私有分支完成.例如,如果您有 2 个分支:主分支和实验分支.您将检查实验并最好使用 -i 标志执行git rebase master".反过来做可能会导致不良副作用.

Rebasing will give you a linear history. Remember that rebases should be done from your private local-only branches. For instances, if you have 2 branches: master and experimental. You would checkout experimental and do 'git rebase master' preferably with the -i flag. Doing it the other way around may result in undesirable side effects.

然后您检查 master 并合并来自实验分支的更改.您的历史记录应该保持线性.

It is then you checkout master and merge in the changes from the experimental branch. Your history should remain linear.

这篇关于git svn 工作流 - 功能分支和合并的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

05-19 00:35