Question

我很困惑，我已经阅读了几篇帖子，博客和文章，不知道去哪里。我正在使用一个svn服务器repo，我用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

你应该合并或挑选主人而不是变基。

至于为什么，这是一个有序的问题。 Rebase意味着您要更改历史记录，以使主题分支在历史记录中显示在master之前。如果你合并或者挑选提交，那么它会在master上添加你的提交。

所以一个完整的循环就像是

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

从我的个人设置中更全面地解释rebase：除了master之外，我还维护一个本地分支工作，我将其用作本地配置out项目的基础。它有自定义属性文件之类的东西，我不想提交。我需要与主分支保持同步，所以我从master开始执行此操作：

git svn rebase
git checkout work
git rebase master

现在git重建工作分支的历史记录，将所有本地配置提交放在堆栈的头部。它通常在主分支上重新创建分支BASEd。如果我要发出

git merge master

而不是重新定位然后结果到拉面眼将是相同的，但历史将是非常不同的。这两个历史记录将被解决，可能导致合并提交，而不是基于另一个的提交。

git merge vs rebase using git svn

2 个答案: