git merge VS git rebase

1.git merge

如下图，图片中每一个节点都代表着一个commit，他们从下往上看，直到最新。图片最左边代表着，B分支从A分支拉出来的一个时间节点，在commit C提交后拉出的B分支

当我们处于A分支时，执行git merge B分支会发生什么事情呢？可以看到图片中间，相当于将commit X、commit Y两次提交，作为了新的commit Z提交到了A分支上。

上图中这个新的commit Z提交节点，也被称为合并提交点

这就代表着B分支代码的提交已经合并到了A分支上，简单明了

如果后面A分支要是还有提交，那就如上面图片右边展示的那样，最新的提交在最上方。

下面来看一个具体的例子：

初始化项目:

新建并且切换到b分支,并且在b分支提交两次记录:

切换到a分支,并且在a分支再提交两次记录:

打印当前a分支的版本记录:

切换到b分支，打印版本记录:

再切换到a分支，合并b分支代码:

如上图，b-333和b-444的提交的hash值没有发生改变。并且有一条新的记录提交到了a分支上

2.git rebase

rebase的使用方式与merge,类似它就相当于插队：

git checkout feature
git rebase main

与merge不同的是,rebase并不会保留原有的提交,而是会创建当前分支比目标分支更新的所有提交的副本,在上述例子中（将feature变基到main）就是2'和4'(两个分支的2和2',4和4'虽然提交的代码一样，但提交的时间信息，提交的hash值都是不同的。),然后将2'和4'按次序插入目标分支末尾：

这样就完成了一个rebase的过程（注意，这条分支是feature分支而不是main分支，原先的提交2和提交4已经被抛弃了），feature分支实际的样子是：

你可以理解为，把feature分支rebase（变基）到main分支的意思是：让你现在的feature分支基于最新的main分支重新开发（创建副本并且移动到末尾）

下面来看一个具体的例子：

初始化项目:

新建并且切换到b分支,并且在b分支提交一次记录:

切换到a分支,并且在a分支再提交一次记录:

切换到b分支,并且在b分支再提交一次记录:

切换到a分支,并且在a分支再提交一次记录:

切换到b分支:



我们发现变基后的b分支的b:222和b:444提交的hash值发生了变化。

切换到a分支:

3.git rebase的注意点

rebase 有一个非常大的坑，那就是它会改变提交历史。

想象一下你和你同事都在开发 main 分支，然后在你开发的时候，你的同事突然把 main 变基了，假设你们之前是这样的：

结果现在变成了这样子：

原来的提交5直接消失了，你的分支已经跟 main 分支匹配不上了，那现在你还能正常把你的分支合入到 main 分支中吗？显然不可以。

所以，main 分支是万万不能使用 rebase 的！！！

在你打算 rebase 的时候，一定要想想是否还有别人也在开发这个分支。

4.总结

	git merge	git rebase
特点	合并分支将展示完整的commit历史记录	会丢失commit节点源信息，合并日志是单线性的
缺点	分支多了，日志会比较繁琐	无法溯源
使用场景	如果我们是多人协同开发同个分支，建议使用merge	如果是私有分支，使用rebase即可