我有一个父分支和子分支。
当我想将子分支合并到父分支时，据说重新建立分支是合并的最佳方式。
如果我们重新设置在另一个分支中所做的所有更改将进入当前子分支，对吗？
那么当有人想查看子分支中所做的新更改时，另一个分支的更改将太正确。
有人可以对 Rebasing vs Pull request vs Merge 有所了解吗？
我正在尝试找到合并分支的最佳方法。
问问题
617 次
2 回答
4
首先，根据我的经验，如果您的场景是团队（多人）同时开发分支。那么Rebase将不适合那个。因为如果您的一位同事执行rebase，它可以修改所有提交。同时，如果另一个人在开发这个分支，很可能找不到公共父节点，无法提交commit。
rebase可以使历史更清晰（一行），但merge不是。
变基 vs 拉取请求 vs 合并
- 拉取请求
拉取请求仅用于提出请求以决定如何“解决”分支之间的提交。提出拉取请求后，您可以决定选择哪种合并类型的策略。
为了更好地解释Rebase和Merge，这里我先设置场景：
假设您有两个分支，master和develop。develop是在（ 3.添加的merge.txt 文件）提交时从master中提取的分支：
现在，set HEAD位于6. added hello.txt file，这是 master 分支的最新提交。
- 合并
基于以上场景，执行git merge develop. 下面是显示的结果：
Git 会自动按照 两个分支的共同祖先（3.add 的merge.txt文件）、两个分支的最新提交和 . 然后根据merge中修改的内容生成一个新的commit，即commit 7. Merge branch 'develop'。这是 的效果，它简单地将两个分支合并并生成一个新的提交。(6.added hello.txt file)(5.added test.txt file)merge
- 变基：
另外，基于上述场景，执行git rebase develop. 下面是显示的结果：
可以看到develop分支和fork都消失了。
当执行一个rebase操作时，git 会(6.added hello.txt file)从当前分支(master)中提取变化，这个变化是从两个分支的共同祖先开始的(3.added merge.txt file)。
然后让master分支指向(5.added test.txt file)目标分支develop的最新提交。并将刚才提取的更改应用于此最新提交。
如果提取有多个更改，那么 git 将依次应用于最新的提交。如下图，left为初始状态，right为rebase执行后的状态：
总之，git rebase提取操作有点像git cherry-pick（只是相似，但不一样）。执行后rebase会依次cherry-pick当前提交，然后发送到目标分支。之后，原始分支上提取的提交被删除。
概括：
可以看到，结果merge可以反映时间线，但rebase会打乱时间线。两者都可以实现代码组合，只针对master等公共分支，不建议使用Rebase。
此外，合并的麻烦是回滚提交节点。但是对于 rebase 是在rebase完成之后，你将不知道你从哪里拉出开发分支，这就是我所说的破坏历史时间线。
于 2019-11-13T12:44:14.510 回答