git merge 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

还是a

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 意味着您想要更改历史记录，以使您的主题分支出现在历史记录中的 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 之外，我还维护一个本地分支工作，我将其用作项目本地配置的基础。它有一些我不想提交的自定义属性文件之类的东西。我需要使其与 master 分支保持同步，因此我从 master 开始执行此操作：

git svn rebase
git checkout work
git rebase master

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

git merge master 

而不是重新设置基准，那么对于跛脚的人来说，结果将是相同的，但历史确实会非常不同。这两个历史记录将得到解决，可能会导致合并提交，而不是一个基于另一个历史记录。