😊前言
作为开发好多年关于git的问题为了面试看过，为了分享研究过，为了排查问题讨论过，但始终没有记录，今天mark一下。惭愧的很太简单知识太习以为常，以至于不屑去深究，记录一下以此为戒。下面只是简单记录一下这几点想到的，后面会持续更新。
1. merge 的参数和意义
--ff 快速合并，默认的参数
如果合并过程出现冲突，Git会显示出冲突并等待手动解决。默认是快进，在master合并feature 分支，相当于把master当前指针指向feature的某一个commit,大部分开发都这么使用并无不妥,只是如果删除feature分支时，master分支会丢失feature分支的信息。feature分支上多次提交并入master，如果master需要紧急回滚上一个版本(git reset --hard HEAD^)，只能回滚到feature的上一次commit。
--ff-only 只有能快速合并的情况才合并
是一种特殊场场景如果合并过程出现冲突，Git会自动abort此次merge
--no-ff 不使用快速合并。
会生成一次新的提交记录，这个记录只是标识在这里进行了一次merge操作。非快进模式的合并，会一直保留分支信息，把feature分支信息复制一份到master。咱们gitLab上提的pr 就是一次非快进模式的合并，使用(git reset --hard HEAD^)能快快速回到上一个稳定版本。笔者建议使用该模式
--squash 压缩合并。
合并的分支的内容压缩成一个新的提交合并进来，把多次commit并入master 的时候合并为一个并入。
2. merge 和 rebase 有无好坏
-
rebase中文是变基，改变他的根基从头合并。什么时候才会变基，master是不需要变基的，因为它就是基。 只有开发分支需要变基，因为开发分支的基master一直再合并其他功能分支。变基能保证master的线性。
-
merge中文是合并，主要是master合并feature分支。
明白场景之后其实就没有孰优孰劣的差别了，非要反正用也可以，只要接受master分支的非线性。
3. git pull 是个合成命令
git pull 的分解是 git fetch + git merge 所以不建议在开发分支使用
4. git reflog
git 的log记录git的操作，记录的每次commitId，即使 reset --hard 也能恢复。
总结
常见的命令，过于习以为常以至于一直没深究过，这里也没有过多深究，简单记录一下，知道其由来，为什么这么命名，适用于什么场景也就算掌握了。
