git svn 工作流 - 功能分支和合并

git svn workflow - feature branches and merge

提问by Pradeep

I am using git-svn with the following workflow now

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

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

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.

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

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

提交消息被替换为“与 featureZ 合并”。这可以通过merge fmt msg 解决。

Now my question is Is there anything that can go wrong with this workflow or needs to be taken care of. I read in git-svn manualthat 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.

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

采纳答案by Fake Code Monkey Rashid

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.

SVN 不能处理非线性历史（它根本没有它的符号）。因此，您想要做的是变基而不是合并，因为它保留了 SVN 的线性历史记录（这在此处的 git-svn 手册页中指出。

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).

详细地说，线性历史是微不足道的。他们走直线（A 到 B 到 C 到 D）。而非线性历史可以从（A 到 B 到 C，B 到 D，然后 C + D 到 E——换句话说，它们发芽成分支）。

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.

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

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

然后你检出 master 并合并来自实验分支的更改。你的历史应该保持线性。

回答by Ropez

You should look at this merge option:

你应该看看这个合并选项：

git checkout master
git merge --squash featureZ

It will squash all commits on the branch into a single commit on the master branch. You will get an opportunity to edit the log message, which is initialized with a summary of what was done on the branch.

它将分支上的所有提交压缩到主分支上的单个提交中。您将有机会编辑日志消息，该消息用分支上所做操作的摘要进行初始化。

It has the disadvantage that the individual commits on the feature branch are not recorded. Furthermore, you should only do this once, and not do any more work on the branch, because it is not registered as a proper merge, and any subsequent merge might give undesired results.

它的缺点是不会记录功能分支上的单个提交。此外，你应该只做一次，不要在分支上做更多的工作，因为它没有注册为适当的合并，任何后续的合并可能会产生不想要的结果。

回答by John K

The answer given by fake-code-monkey-rashid is correct. This is less of an answer and more of a simplification.

fake-code-monkey-rashid 给出的答案是正确的。这不是一个答案，而是更多的简化。

You can svn rebase/dcommit from any git branch. The only use masterwould have is if you had other local changes you needed to merge with the changes from featureZ.

您可以从任何 git 分支执行 svn rebase/dcommit。master唯一的用途是，如果您有其他本地更改，您需要与来自featureZ的更改合并。

git branch featureZ
git checkout featureZ
#bunch of changes
git commit
git svn rebase
# solve any conflicts
git svn dcommit

If you want to keep a clean master then you can either git svn rebaseit or git merge featuresZ

如果你想保持一个干净的高手，那么你既可以git svn rebase是或git merge featuresZ

回答by vadishev

Instead of git-svn, you may use SubGit. It's a server-side tool which automatically synchronizes Subversion and Git repositories.

您可以使用SubGit代替 git-svn 。它是一个服务器端工具，可以自动同步 Subversion 和 Git 存储库。

You can use any Git workflow and any Git client available, no additional client tools needed.

您可以使用任何 Git 工作流程和任何可用的 Git 客户端，无需额外的客户端工具。

Considering your scenario:

考虑到您的情况：

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

You can proceed as follows:

您可以按以下步骤操作：

1. Push feature branch entirely.

   git merge featureZ
   git push origin refs/heads/*
   

2. Rebase a feature branch on top of master/trunk.

   git rebase featureZ
   git push
   

3. Squash commits from a feature branch.

   git merge --squash featureZ
   git commit
   git push
   

1. 完全推送功能分支。

   git merge featureZ
   git push origin refs/heads/*
   

2. 在 master/trunk 之上重新建立一个功能分支。

   git rebase featureZ
   git push
   

3. Squash 从功能分支提交。

   git merge --squash featureZ
   git commit
   git push
   

As soon as you push changes, SubGit hooks translate your changes into Subversion revisions.

只要您推送更改，SubGit 挂钩就会将您的更改转换为 Subversion 修订版。

Some more details:

更多细节：

• SubGit in many ways is more superior than git-svn — better merge-tracking translation, EOLs & mime-type support, etc.
• SubGit needs local access to Subversion repository (it uses custom hooks);
• SubGit is a commercial product with some free options (open-source and academic projects, small teams).

• SubGit 在很多方面都比 git-svn 更优越——更好的合并跟踪翻译、EOL 和 mime 类型支持等。
• SubGit 需要本地访问 Subversion 存储库（它使用自定义钩子）；
• SubGit 是具有一些免费选项（开源和学术项目、小团队）的商业产品。