git核心功能合并git merge和git rebase

重点

理解git merge的基础上，再去理解git rebase.本博客着重是根据官方文档里理解，做的实验。如果想深入理解git merge和git rebase还是看官方文档，什么博客，都不好使，没有官方文档牛逼。相关文档，在文章尾部，都已经附上。

实验环境介绍

在gitee上创建一个空的仓库，然后在电脑端使用git clone同步这个仓库，然后再电脑端新建一个version.txt文件，分别在version.txt文件中，添加verison1,verison2，并且提交和push，这样这个仓库就有2个提交版本。
然后再增加common.txt文件，并且在文件中，添加version3，并且在version.txt文件中，增加version3，提交和push
1.在gitee上创建一个空的仓库

2.在电脑端，增加version.txt文件，并且在该文件中增加，version1,version2这个字符串，并且提交2次，第三次的时候，在version.txt文件中增加version3字符串，新增common.txt文件，并且增加version3字符串。操作成功的样子，大概就是这种情况。


3.新建3个分支，分别是work,hotfix,bugfix222，这样他们的父节点都是第三次提交

Git merge

合并场景1：两个合并的分支，父节点一样，合并新的文件

（master和work分支合并，master和work的分支的父节点都是master，work节点添加新的文件）
step1:切换到work分支

step2.在工作区增加文件work.txt,并且提交

step3:切换到master分支，合并work分支，并且push到服务器

4.查看服务器的变化

合并场景2：两个合并的分支，父节点不一样，合并新的文件

（master和hotfix分支合并，work的分支的父节点上一个master，而当前的master分支就是他自己，这样他们的父节点不一样，hotfix节点添加新的文件）
step1.切换到hotfix分支

step2.在工作区增加文件hotfix.txt,并且提交

step3:切换到master分支，合并hotfix分支，会出现无法合并的情况

图中的1，是在合并前，获取仓库中的工作区，暂存区的状态，没有需要提交的文件
图中的2，运行合并分支的命令
图中的3，是在合并后，获取相关的状态
图中的4，我们发现hotfix分支中的文件，现在已经进入暂存区，接着我们按照正常的流程，去提交和push，就可以啦。
Step4.提交并且push合并的文件

Step5.查看服务器的变化

合并场景3：两个合并的分支，父节点一样，合并共同文件，增加文件内容

（在做完场景1和场景2的实验后，新增分支merge1，这样master和merge1的父节点都是master,将merge1分支中的version.txt文件增加一行内容）
Step1:在做完场景1和场景2的实验后，新增分支merge1

Step2.在merge1的工作区中的version文件中，增加第四行，内容为“merge1”

3.添加，提交

4.切换到master分支，合并merge1分支，并且push

5.查看服务器

合并场景4：两个合并的分支，父节点不一样，合并共同的文件，修改的位置不一样

（做完场景1，2，3后，hotfix的父节点是当前master的上一个节点，而当前master的父节点就是它自己，它们的父节点不一样，在hotfix分支中的version.txt文件中，修改第1行和第4行，增加第5行内容）
Step1.查看master和hotfix节点中的version.txt的文件内容

Step2.将hotfix节点中的version.txt中的第一行的后面添加hotfix,在第5行中，也添加hotfix

Step3.添加和提交

Step4.切换到master分支，并且进行合并，我们发现无法进行合并

Step5.合并的冲突解决，出现合并冲突的文件，git会自动产生冲突的位置

master节点中的version.txt中第4行为“merge1”，第5行无内容。
hotfix节点中的version.txt中第4行为空行，第5行为“hotfix”.
我们手动合并
Step6.添加，提交，push，服务器查看

Git rebase

合并提交记录

我们仅仅是做实验，就产生了这么多的提交记录,详见下图，如果是在真实的应用中，提交的记录会非常非常多，而且如果再没有命名规范，那估计以后想找版本回退啥的，真是非常的麻烦。
-------->造成分支污染，项目中充满了许多commit记录，当出现紧急问题需要回滚代码时，就只能一条条的查看了。
-------->代码review不方便，当你要做code review时，一个很小的功能却提交了很多次，看起来就不是很方便了。

Step1.运行命令git rebase -i HEAD~2

Step2.执行步骤1指令后会自动弹出vim编辑模式,如下图：

关于上面的用法，请看中文的解释，功能很多，后面需要的时候，再来研究一下

Step3.根据指令，我们做如下修改：

修改好后，我们点击保存退出，就会进入注释界面:

Step4.合并成一条

分支合并

关于git rebase分支的合并，还是看官方文档比较稳妥，解释的非常清晰。
https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

Git merge 和Git rebase的区别

1.假如现在出现如下情况，现在需要将mywork合并到origin分支，我们来看一下git merge和git rebase是如何进行合并的。

2.Git merge
1.切换到origin分支，git checkout origin
2.然后直接运行git merge mywork
（如果遇到冲突，解决完冲突，再提交一次即可，如果没有冲突，就直接合并成功，最后均会生成C7）

3.Git rebase
1.切换到mywork分支，git checkout mywork
2. git rebase origin
这个命令会把你的"mywork"分支里的每个提交(commit，这里指的是C5和C6)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。
3.切换到origin分支，运行git checkout origin,然后再运行git merge，就好了，C5和C6会被丢弃掉

产生的历史区别

参考链接：

分支合并的原理
https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6

变基的博客
https://blog.csdn.net/qq_39397165/article/details/108967289?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-2.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-2.control

https://blog.csdn.net/hudashi/article/details/7664631

变基的原理
https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA