最常用的git命令，这篇文章通通say good bye！！！

“

    这是本人第 49 篇原创博文，每周至少两篇更新，谢谢赏脸阅读文章

最近一直在做项目，然后，每天都和git打交道，俗话说：一来生二来熟，每天相拥，不熟也难啊，所以，最近就去看看了两个有趣的git命令，这两个命令可能每个人使用的时候都是不一样的，最开始，我也没有注意这么多，最近才去认认真真的思考了这两个命令的区别，发现了其中的一些奥妙，这篇文章就简单的聊一聊吧。

git merge

最开始的时候，我还是习惯用git merge这个命令的，但是，后来发现很多人其实也用git rebase，所以，就想看看为啥有这两种用法的区别，到底区别在哪里？

先来看看git merge的用法。

我们首先在master的基础上新建分支，然后做一些修改，并且提交。

git checkout -b feat/work
vim service.go
git add .
git commit -m '提交feat/work'
vim service2.go
git add .
git commit -m '提交新增修改'

通过上面的操作，我们在master的基础上进行了分支feat/work创建，并且进行了两次提交，所以，目前的git分支情况应该是下面这样的。

好了，这个时候，这个分支已经开发完了，那么，我们就需要合并分支了，我们进行下面的git merge操作。

但是，这个时候，别人开发完了他的分支之后，也进行了提交，并且merge到了master，这个时候情况如下图。

这个时候，我们再进行merge 的时候就会发现，会有conflict需要我们解决。

git merge解决冲突的方式是一次全部进行递归合并，如果有冲突的文件进行提示，然后需要我们进行修改。修改完了之后，我们再用git add和git commit提交就ok了。

git merge master

我们进行了合并master的操作，这时的情况应该是这样的。

然后，我们再进行master合并feat/work进行快进就可以完成整个过程了。

通过上面的这个实例我们会发现，如上图git merge的操作，是会保留在分支上的所有的提交记录的，这样的好处就是可以保留所有的历史的提交的记录，方便查看历史的log。

ok，下面我们再来看看git rebase的操作是怎么样的。

git rebase

终于等到你，我们来看看git rebase是什么神仙。

同样的，我们还是创建一个新的分支，然后进行一些操作。

git checkout -b feat/work //新建分支
vim service3.go
git add .
git commit -m '提交修改'

同时，别人也新建了一个新的分支进行开发，相当于有两个分支同时进行开发。

git checkout -b feat/work2 //新建分支
vim service3.go
git add .
git commit -m '提交修改'

我们同时对一个文件中的一个方法进行修改，这个时候，然后，另外一个小伙伴进行了merge操作，这个时候的git情况就变成下面这样的了。

这个时候我们进行git rebase会发现有冲突，所以我们需要解决冲突，前面说过，git merge解决冲突是递归合并，然后有冲突的文件全部显示出来，然后自己去解决。而git rebase的解决冲突方式则是一次解决一个，解决完一个再下一个。

比如，我们解决第一个，解决完了之后，我们用先用git status查看目前的git情况，然后再添加刚刚解决的冲突   git add u。

git status //查看git状态
git add -u

接着，我们用git rebase --continue继续解决冲突。如此反复，最终把全部冲突解决。

另外，如果想中途退出，可以用git rebase --abort命令，退出rebase，这样就会回到rebase之前。

rebase的解决冲突过程可以用如下图表示。

rebase的整个过程，首先会类似将C5、C6复制一份，然后放入到最新的master之后。

然后，再将feat/work分支上的commit全部删除。

整个过程可以用如下图表示。

所以说，rebase会将原来的分支的commit的全部清除掉。

小小对比

通过这两个操作的过程，我们会发现这两个命令的区别。

第一个，git merge一次全部解决冲突，git rebase一次解决一个，这种方式会发现，git rebase一次解决一个，不容易漏掉，思路清晰，而git merge的话更快解决。

第二个，git merge会保留合并之前分支的所有提交，历史记录更加完整，而git rebase则是直接放到master之后，会清除分支上的所有commit记录，这样好处就是可以使得整个master更加整洁。

那到底用哪一个呢，其实没有最好的办法，两种都是可以的，看你怎么选择，一种可以记录历史分支的提交，另外一种则不记录，但是使得master更加清晰，所以，就看自己的取舍。

git rebase缺陷

最主要的意思就是说，我们在用git rebase的时候，需要注意一点：只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作。

具体的问题描述可以看看git的官方文档，非常详细，不过多描述：https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA