Git-demo

git-demo-direct-merge.md

Direct Merge 直接合并PR

1 新建仓库git-demo，分支为main

2 在GitHub新建分支feature

3 本地fetch GitHub仓库，将feature分支同步到本地，获取后的状态是：main和feature分支的commit是同一个。

4 添加三个文件，分别提交三个commit到本地的feature分支。 请注意：提交后 本地 的feature分支向前步进三次，但 origin（即GitHub上的feature分支）仍旧是停留在"initial commit"的那一次提交上

5 推送本地feature分支到GitHub。

6 在确认code review通过后，使用提交GitHub pull request请求合并（Merge）入main分支。

Asterism/git-demo#1

7 合并相关pull request请求。

请注意：这里的合并使用的是Direct merge（直接合并），而不是Squash Merge（聚合合并，即将feature分支上的所有提交压缩成一次提交后合并），也不是Rebase 合并（变基合并）。

8 确认 git 仓库的commit树。（注，图中的本地git客户端是已经git fetch并git pull过的，并checkout到了最新的commit上）

9 （很重要）在线的feature分支上是没有任何pull request的内容的。

但实际在重新针对feature分支执行git fetch并git pull之后，本地的feature分支是比在线的feature分支往前一步进的（即最新commit落在了merge pr的地方）

重新克隆仓库后该问题消失。怀疑是git fetch并git pull两个都执行不行，应该只针对feature分支执行git pull就足够。

事实上，当Merge完成后，feature分支确实是比main分支落后一次提交的（既然feature分支是基于main分支创建的，而刚刚的Merge实际上就是给main分支新增了一个提交，自然GitHub会提醒）

我的建议是，虽然两个分支不存在文件差异，但应该将main分支的东西同步到feature分支上，以便于后续继续在feature分支上开发。

---

至此，feature分支合并完成并可继续基于main分支开发。

git-demo-rebase-merge.md

Rebase Merge 先变基再合并PR

在上文仓库的基础上，在保持feature分支是与main分支的同步的情况下，我们先在feature分支新增几个提交，之后在main分支添加一个新的文件并提交 模拟main分支步进，feature分支需要先git rebase才能git merge的情况

---

0 前置准备：将feature分支与main分支进行同步，准备开发。（从main同步至feature）（上文提到的第9点）

可以看到，这次合并是没有任何文件差异的（下方对比栏是空的），仅仅是同步commit进度。

1 添加三个文件，分别提交三个commit到本地的feature分支。

请注意：提交后 本地 的feature分支向前步进三次，但 origin（即GitHub上的feature分支）仍旧是停留在“进度同步”的那一次提交上

2 在main分支添加一个文件info.md并添加一次提交至GitHub仓库。

3 推送本地feature分支到GitHub仓库。

请注意：这时候GitHub仓库中的feature分支是没有info.md提交的，该提交仅存在于main分支中。

可以看到，feature分支是落后1（即没有main分支的info.md），前进4（PR #2，即“0 前置准备”一个提交+3个md文件提交一共四次）

---

4 在确认code review通过后，使用提交GitHub pull request请求并合并（Merge）入main分支。

在这里同样可以看到刚刚提到的前进4（feature分支上4个新增的提交）

5 合并相关pull request请求。

请注意：这里是可以直接使用Direct merge（直接合并）的，前提是：源分支（feature分支）和目标分支（main分支）修改的文件完全不冲突。

如果有任意冲突则不能进行Direct merge（直接合并），请使用Rebase 合并（变基合并）。

我们在这里使用Rebase 合并（变基合并）。

6 （很重要）合并后的分支文件结构

可以看到，虽然我们使用的是Rebase 合并（变基合并），但这个git rebase操作是GitHub自动帮我们处理了，feature分支上是没有任何关于git rebase的提交的。

并且，显而易见的，feature分支是没有info.md这个文件的。

这也是为什么我在上文的第9点提到，哪怕是合并了PR，开发分支（feature分支）合并后想要继续开发，也尽量在继续前同步一下源头分支（main分支）。

同时，由于我们使用的是Rebase 合并（变基合并），GitHub仓库的commit树会变得非常的诡异。 是的，Rebase操作会直接将我们在feature分支上的commit原封不动的复制到main分支上。

---

7 同步feature分支以便继续在feature分支上开发

由于源头分支（main分支）与开发分支（feature分支）在commit同步上差异巨大，我们不得不进行同步以便接下来在开发分支（feature分支）上继续工作。

既然是commit同步，我们就不使用Rebase 合并（变基合并）复制来复制去了，以免差异越来越大。我们直接使用Direct merge（直接合并）即可。

Asterism/git-demo#4

8 确认 git 仓库的commit树。

我们可以看到，现在feature分支在文件差异上与main分支完全同步了，但的确因为Rebase 合并（变基合并）导致的commit复制，我们在feature分支上的提交确实出现了两次。

可以确认，commit复制的原因就是Rebase 合并（变基合并）导致的。

---

至此，feature分支合并完成并可继续基于main分支开发。

https://docs.github.com/zh/enterprise-server@3.7/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#rebase-and-merge-your-commits

简而言之，GitHub的Rebase跟git rebase不太一样，确实是”直接把commit复制过去“。