变基是合并分支的最佳策略

Question

我有一个父分支和子分支。

当我想将子分支合并到父分支时，据说重新建立分支是最好的合并方法。

如果我们重新调整另一个分支中所做的所有更改都会进入当前的子分支，对吗？

然后，当有人想查看子分支中所做的新更改时，其他分支的更改就会太正确。

有人可以解释一下 Rebasing、Pull request 和 Merge 吗？

我正在尝试找到合并分支的最佳方法。

Answer 1

首先，根据我的经验，如果你的场景是团队（多人）同时开发分支。那么Rebase就不适合那个了。因为如果您的一位同事执行rebase，它可以修改所有提交。同时，如果另一个人正在开发这个分支，很可能找不到公共父节点，无法提交commit。

rebase可以让历史更清晰（一行），但merge不行。

变基、拉取请求、合并

• 拉取请求

拉取请求只是用来提出请求来决定如何“解决”分支之间的提交。提出拉取请求后，您可以决定选择合并类型的策略。

为了更好地解释Rebase和Merge，这里我先设定了场景：

假设你有两个分支，master和development。develop是在（3.added merge.txt 文件）commit 处从master拉取的分支：

现在， set HEAD位于6.added hello.txt file，这是 master 分支的最新提交。

• 合并

根据以上场景，执行git merge develop. 下面是显示的结果：

Git 将通过跟踪 两个分支的共同祖先（3.added merge.txt 文件）、两个分支的最新提交和 来自动进行三向合并。然后会根据merge中修改的内容生成一个新的commit，即commit 7. Mergebranch 'develop'。这就是 的效果，它只是合并两个分支并生成一个新的提交。(6.added hello.txt file)(5.added test.txt file)merge

• 变基：

另外，根据上述场景，执行git rebase develop. 下面是显示的结果：

可以看到develop分支和fork都消失了。

当执行操作时，git会从当前分支中rebase提取更改，并且此更改是从两个分支的共同祖先开始的。(6.added hello.txt file)(master)(3.added merge.txt file)

然后让master分支指向(5.added test.txt file)目标分支develop的最新提交。并将刚才提取的更改应用到最新的提交。

如果提取有多个更改，那么 git 会依次应用到最新的提交。如下所示，左边是初始状态，右边是执行rebase后的状态：

总而言之，git rebase提取操作有点像git cherry-pick（只是相似，但不一样）。执行后rebase，会依次cherry-pick当前的commit，然后发送到目标分支。之后，原始分支上提取的提交将被删除。

概括：

可以看到结果merge可以反映时间线，但是rebase会打乱时间线。两者都可以实现代码合并，只是针对公共分支，比如master，不建议使用Rebase。

另外，合并的麻烦是回滚提交节点。但是对于rebase来说， rebase完成后，你不会知道你把开发分支拉到哪里了，这就是我说的打乱历史时间线。