GIT常见命令(一) git merge 与 git rebase的区别 git merge和git rebase的区别
参考：
https://blog.csdn.net/liuxiaoheng1992/article/details/79108233
https://www.cnblogs.com/rainboy2010/p/12671633.html
https://www.cnblogs.com/marblemm/p/7161614.html
https://segmentfault.com/a/1190000018580144?utm_source=tag-newest
https://www.jianshu.com/p/4079284dd970
https://www.cnblogs.com/runnerjack/p/9342362.html
git merge 与 git rebase的区别
git fetch & pull详解
前言
其实这个问题困扰我有一段时间，相信也有人和我一样有这个困扰，网上已有很多这种解释了，但是要么就是无图，要么就是解释的很乱，没太看懂，经过自己对git的使用，加上向同事请教，算是理解了这个问题，所以写下来分享一下，我尽量详细说明
merge与rebase的区别
假设我们有如下图一所示仓库，该仓库有master和develop两个分支，且develop是在（3.added merge.txt file）commit处从master拉出来的分支。
merge
假设现在HEAD在（6.added hello.txt file）处，也就是在master分支最近的一次提交处，此时执行git merge develop, 结果如下图所示。
工作原理就是：git 会自动根据两个分支的共同祖先即 (3.added merge.txt file)这个 commit 和两个分支的最新提交即 (6.added hello.txt file) 和 (5.added test.txt file) 进行一个三方合并，然后将合并中修改的内容生成一个新的 commit，即图二的(7.Merge branch ‘develop’)。
这是merge的效果，简单来说就合并两个分支并生成一个新的提交。
rebase
那rebase是这么工作的呢？
假设初始状态也是图一所显示的。两个分支一个master，一个develop，此时HEAD在（6.added hello.txt file）处，现在执行git rebase develop,结果如下图三所示。
可以看见develop分支分出来分叉不见了，下面来解释一下它的工作原理：
在执行git rebase develop之前，HEAD在（6.added hello.txt file）处，当执行rebase操作时，git 会从两个分支的共同祖先 (3.added merge.txt file)开始提取 当前分支（此时是master分支）上的修改，即 （6.added hello.txt file）这个commit，再将 master 分支指向 目标分支的最新提交（此时是develop分支）即（5.added test.txt file） 处，然后将刚刚提取的修改应用到这个最新提交后面。如果提取的修改有多个，那git将依次应用到最新的提交后面，如下两图所示，图四为初始状态，图五为执行rebase后的状态。
简单来说，git rebase提取操作有点像git cherry-pick一样，执行rebase后依次将当前的提交cherry-pick到目标分支上，然后将在原始分支上的已提交的commit删除。
注：图中6没有的原因：因为5和6不小心搞成一样的修改了，然后它就合并了
merge OR rebase
那什么时候用merge，什么时候用rebase呢？
再举个例子：
初始状态如下图六所示：
和之前一样的是，develop分支也是在 (3.added merge.txt file)处从master分支拉取develop分支。不一样的是两个分支各个commit的时间不同，之前develop分支的4和5commit在master分支3之后6之前，现在是develop分支的4提交早于master分支的5提交，develop分支的6提交晚于master的5提交早于master的7提交。
在上图情况下，在master分支的7commit处，执行git merge develop，结果如下图七所示：
执行git rebase develop，结果如下图八所示：
- 可以看出merge结果能够体现出时间线，但是rebase会打乱时间线。
- 而rebase看起来简洁，但是merge看起来不太简洁。
- 最终结果是都把代码合起来了，所以具体怎么使用这两个命令看项目需要。
还有一点说明的是，在项目中经常使用git pull来拉取代码，git pull相当于是git fetch + git merge，如果此时运行git pull -r，也就是git pull --rebase，相当于git fetch + git rebase
最后推荐一些git可视化工具，我用的是gitkraken，这些工具功能基本一样，看个人喜欢好使用
git merge和git rebase的区别
在分支合并时，有两种方式：git merge 和git rebase
举个例子，当前有一个master分支，日志信息如下：
现在在master分支上创建一个dev分支，然后在dev分支上进行两次提交，添加dev1.txt,dev2.txt,日志信息如下：
同时在master分支上进行两次提交，添加master1.txt,master2.txt，日志信息如下：
现在要把dev分支合并到master分支
使用merge命令合并：git merge dev
使用rebase命令合并：git rebase dev
Git 会从两个分支的共同祖先8eda20d开始提取 master 分支（当前所在分支）上的修改，即 e0779e1、ae0decb，再将 master 分支指向 dev的最新提交（目标分支）即 e45d38f处，然后将刚刚提取的修改依次应用到这个最新提交后面。操作会舍弃 master 分支上提取的 commit，同时不会像 merge 一样生成一个合并修改内容的 commit，相当于把 master 分支（当前所在分支）上的修改在 dev分支（目标分支）上原样复制了一遍
总结
-
merge 是一个合并操作，会将两个分支的修改合并在一起
-
merge 的提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面
-
rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面
【Android】Android处理Home键方法小结
【Android】spannableStringBuilder
【Android】Android 4.0 Launcher2源码分析——启动过程分析
【Android】android文件的写入与读取---简单的文本读写context.openFileInput() context.openFileOutput()
【Android】Android取消EditText自动获取焦点
android在view.requestFocus(0)返回false的解决办法
Android中创建倒影效果的工具类
android布局layout中的一些属性
android中巧妙更改spinner、AutoCompleteTextView分割线的颜色值（spinner AutoCompleteTextView divider color）