git合并VS rebase使用git svn

Question

我很困惑，我已经阅读了几篇文章，博客和文章，不知道该去哪里。我正在使用svn服务器回购，我用git svn下拉并开始工作。我目前是唯一一个开发这个（即没有上游变化）的人。

所以我有一个当地的git主题分支vacation，我需要合并回到master到dcommit，但我不想将所有提交压缩到一个大的分支。

我试图做一个git rebase -i master它消除了90％的变化。

办一个

git checkout master 
git rebase vacation 
git svn docmmit 

还是一个

git checkout vacation 
git rebase master 
git checkout master 
git merge vacation --ff-only 
git svn docmmit? 

恐怕这样B/C发生了什么事时，我 尝试过有人可以请简单介绍一下我应该怎么做，为什么我必须这样做？

Answer 1

所以我想我想通了。

git checkout vacation 
git rebase master 
[ masters's chages put behind this branches, replay every commit ] 
git checkout master 
git merge --ff-only vacation 
git svn dcommit 
[ each change goes into svn as seperate commit ] 

我没有上游的变化，但这正是我想要的。

Answer 2

你应该合并或樱桃采摘成master不rebase。

至于为什么，它的订购问题。 Rebase意味着你想修改历史记录，使你的主题分支出现在历史中的主人之前。如果您合并或挑选提交，那么它会将您的提交添加到主控制器上。

因此，一个完整的周期会是这样的

git checkout -b vacation 
[make changes] 
git commit -a -m "Commit message" 
git checkout master 
git merge vacation 
git svn dcommit 

为了解释从我个人的设置底垫更充分的例子：除了掌握我还保持我的基地使用本地分行的工作我的out项目的本地配置。它有自定义属性文件，我不想提交的东西。我需要与主分支保持这种同步，所以我这样做，从主开始：

git svn rebase 
git checkout work 
git rebase master 

现在git的重建工作分支把所有的本地配置的历史承诺在堆栈的头。它根据主分支重新创建分支。如果我发行

git merge master 

而不是rebabil然后结果lamen眼将是相同的，但历史将是非常不同的确实。这两个历史将被解决，可能导致合并提交，而不是基于另一个的提交。