git：更有效的方法来做到这一点 [英] git: more efficient way to do this

问题描述

$ b

1. 为问题创建分支


2. 在分支机构完成一些工作后提交
   
3. 结帐大师


4. svn rebase


5. li>
   
6. rebase master


7. 结帐大师


8. 合并分支
   
9. dcommit

我的目标是让我的历史记录保持在一条直线上，并尽量减少合并的头痛。 b
$ b

有没有办法用更少的步骤来做到这一点？

解决方案

没有必要在中间做你的rebase，当然不需要交换到master分支去做。我的工作流达到了相同的效果，因此：

1. 为问题创建分支： git checkout - 如果我已经在我感兴趣的分支上，可以省略 remotes / trunk >




2. 将它直接推送到Subversion存储库： git svn dcommit 。如果您编辑的文件已被更改，这只会失败。如果他们有，你会得到一个错误，所以做一个 git svn rebase 然后再次尝试你的 git svn dcommit 。

   
   
   

   请注意，无需先将它合并到您的主分支中。
   

3. 分支： git checkout master 。




4. 重建master分支： git svn rebase 。

   
   
   

   或者，删除问题分支;那么master和issue分支现在应该是相同的，因为紧接着 git svn dcommit 做了一个 git svn rebase 您可以从任何分支执行 git svn 命令;系统将根据Subversion Subversion分支计算出承诺的位置或基准位置。如果你想检查它感兴趣的Subversion分支，运行 git svn dcommit --dry-run

   
   
   

   特别是主分支没有特别的特殊之处。事实上，我经常忽略它并跳过上面的步骤4-5。我将从一个问题分支交换到另一个问题分支，并且永远不会把主分支带到Subversion的提示。

   
   

   This is my normal workflow with git-svn:

   1. create a branch for an issue
   2. commit after doing some work on branch
   3. checkout master
   4. svn rebase
   5. checkout branch
   6. rebase master
   7. checkout master
   8. merge branch
   9. dcommit

   My goal here is to keep my history in a straight line, and also trying to minimize the headache of merges.

   Is there a way to do this with less steps?

   解决方案

   There's no need to do your rebase in the middle, and certainly no need to swap to the master branch to do so. My workflow achieves the same and is thus:

   1. Create a branch for an issue: git checkout -b issue remotes/trunk (that remotes/trunk can be omitted if I'm already on the branch I'm interested in).

   2. Do some work, and commit it.

   3. Push it straight to the Subversion repository: git svn dcommit. This will only fail if files you've edited have been changed. If they have, you'll get an error, so do a git svn rebase then try your git svn dcommit again.

      Note there's no need to merge this into your master branch first.

   4. Checkout the master branch: git checkout master.

   5. Rebase the master branch: git svn rebase.

      Optionally, delete the issue branch; the master and issue branches should now be identical, as git svn dcommit does a git svn rebase immediately afterwards.

   You can do your git svn commands from any branch; the system will work out where to commit to or rebase from based on the parent Subversion branch. If you want to check what Subversion branch it's interested in, run git svn dcommit --dry-run

   In particular, there's nothing particularly special about the master branch. Indeed, I frequently ignore it and skip steps 4–5 above. I'll just swap from one issue branch to another and never bother bringing the master branch up to the Subversion tip.

   这篇关于git：更有效的方法来做到这一点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！