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

问题描述

我尝试使用git-svn的动机是毫不费力的合并和分支。然后我注意到man git-svn（1）说：

在分支上不推荐使用git-merge或git-pull计划
到dcommit。 Subversion不代表任何
合理或有用的合并方式;因此使用Subversion的用户无法看到您创建的任何
合并。此外，如果你从SVN分支的镜像git
分支合并或拉出，dcommit可能会提交给
错误的分支。

这是否意味着我无法从svn / trunk（或分支）创建本地分支，破解，合并回svn / trunk，然后dcommit？我明白，svn用户会看到svn pre 1.5.x中合并的那些混乱一直存在，但是还有其他什么缺点吗？最后一句话也让我担心。实际上，我发现了一个更好的方式来处理这样的事情吗？


解决方案

--no-ff 在git merge上的选项。
我之前使用的所有这种压扁技术不再需要。

我的新工作流程如下：

• 一个master分支，这是我承诺并克隆SVN仓库的唯一分支（ -s ）假设您在仓库中有一个标准的SVN布局 trunk / ， branches / 和 tags / ）：

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




• 我使用本地分支work（ -b 创建分支work）
  
  

    git checkout -b work 
   
    ... 
  （work）$> git commit -s -mmsg 1
   ... 
  （work）$> git commit -s -mmsg 2
   ... 
  （work）$> git commit -s -mmsg 3
    
   

现在你想提交到SVN服务器上

• [最终]隐藏你不想看到提交的修改SVN服务器（通常你在主文件中注释了一些代码，仅仅是因为你想加快编译并专注于给定的功能）
  
  

   （工作）$> git stash 
    




• 使用SVN仓库重新分配master分支（从SVN服务器更新）
  
  

   （work）$> git checkout master 
  （master）$> git svn rebase 
    




• 返回工作分支并使用master重新绑定
  
  

   （master）$> git checkout work 
  （work）$> git rebase master 
    




• 确保一切正常，例如：

   （work）$> git log --graph --oneline --decorate 
    




• 现在是合并所有三个使用这个美好的 - no-ff 选项从工作分支提交给主人

   （工作）$> git checkout master 
  （master）$> git merge --no-ff work 
    




• 您可以注意到日志的状态：

   （master）$> git log --graph --oneline --decorate 
   * 56a779b（work，master）合并分支'work'
   | \ 
   | * af6f7ae msg 3 
   | * 8750643 msg 2 
   | * 08464ae msg 1 
   | / 
   * 21e20fa（git-svn）last svn commit 
    




• 现在你可能想编辑（修改）你的SVN花花公子的最后一次提交（否则它们只会看到一条提交信息为合并分支'work'

   （master）$> git commit --amend 
    
   




• 最后在SVN服务器上提交
  
  

   （master）$> git svn dcommit 
    




• 返回工作状态并最终恢复隐藏文件：
  
  $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $> b $ b

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

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.

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?

解决方案

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:

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

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

  git checkout -b work
  

• 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"
  

Now you want to commit onto the SVN server

• [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
  

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

  (work)$> git checkout master
  (master)$> git svn 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
  

• 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
  

• 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
  

• 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屋！