今天写了一堆代码，git add .后推送到远程，发现远程有更新，需要git pull,此时git pull --rebase后发现有冲突
此时脑袋短路加抽风!!! 执行了git rebase --skip，之前的代码一下子全没有了，心里发慌，后背发凉，又要重写一遍了！！！
google之后发现可以执行git reflog命令
git rebase 误操作导致文件丢失撤销并恢复文件
第一步
执行 git reflog查看本地操作记录
找到本次rebase之前的操作id 例如：01b6bb4
第二步 执行恢复命令
git reset --hard 01b6bb4
出现提示则输入y确认
找回代码后，果断的git push --force了
git rebase使用场景一:合并多次提交记录
1.实际操作提交了三个commit之后，合并最近的两次提交为一个commit，那么我们输入如下命令git rebase -i 两个要合并的commitId的前一个commitId
执行git rebase -i HEAD~2后，可以看到其中分为两个部分，上方未注释的部分是填写要执行的指令，而下方注释的部分则是指令的提示说明。指令部分中由前方的命令名称、commit hash 和 commit message 组成。
当前我们只要知道 pick 和 squash 这两个命令即可。
pick 的意思是要会执行这个 commit
squash 的意思是这个 commit 会被合并到前一个commit
将out_yuv420p.yuv这次提交合并到in.png上,我们将 e2eb289 这个 commit 前方的命令改成 squash 或 s，然后输入:wq以保存并退出
这是我们会看到 commit message 的编辑界面
其中, 非注释部分就是两次的 commit message, 你要做的就是将这两个修改成新的 commit message。
输入wq保存并推出, 再次输入git log查看 commit 历史信息，你会发现这两个 commit 已经合并了。
注意事项：如果这个过程中有操作错误，可以使用 git rebase --abort来撤销修改，回到没有开始操作合并之前的状态。
以上是合并最近两次提交信息，若合并多次呢，比如三次,五次呢
执行git rebase -i HEAD~5
合并五次提交信息为一次提交信息，git log发现前面五次提交信息已经变化为一次提交信息
git push --force将合并后的提交信息推送到远程
若遇到报错git LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
则将代理关掉，重新换个节点
git rebase使用场景二:分支合并
详情参考文章《彻底搞懂Git-Rebase》
假设你和同事分别从master上面拉了两个分支，feature-1.0.0和feature-2.0.0,同事的分支feature-1.0.0提交了三次代码后，合并到了master分支，此时master已经领先于你的feature-2.0.0分支了，我们想要同步master分支的改动
首先想到的是执行git merge master,此时
就会在记录里发现一些 merge 的信息，但是我们觉得这样污染了 commit 记录，想要保持一份干净的 commit，怎么办呢？这时候，git rebase 就派上用场了。
在feature-2.0.0分支上执行:git rebase master
这里补充一点：rebase 做了什么操作呢？
首先，git 会把 feature-2.0.0 分支里面的每个 commit 取消掉；
其次，把上面的操作临时保存成 patch 文件，存在 .git/rebase 目录下；
然后，把 feature-2.0.0 分支更新到最新的 master 分支；
最后，把上面保存的 patch 文件应用到 feature-2.0.0 分支上；
从 commit 记录我们可以看出来，feature-2.0.0 分支是基于 feature-1.0.0 合并后的 master ，自然而然的成为了最领先的分支，而且没有 merge 的 commit 记录，是不是感觉很舒服了。
以上是本地分支并没有提交到远程的例子，我们再试一个提交到远程的例子
feature-1.0.0是同事的分支，我们先合并到master,推送到远程
自己的分支feature-2.0.0执行git rebase master
在 rebase 的过程中，也许会出现冲突 conflict。在这种情况，git 会停止 rebase 并会让你去解决冲突。在解决完冲突后，用 git add 命令去更新这些内容。
git rebase --continue
这样 git 会继续应用余下的 patch 补丁文件。
在任何时候，我们都可以用 --abort 参数来终止 rebase 的行动，并且分支会回到 rebase 开始前的状态。
git rebase —abort
根据上文来看，git-rebase 很完美，解决了我们的两个问题：
1.合并 commit 记录，保持分支整洁；
2.相比 merge 来说会减少分支合并的记录；
如果你提交了代码到远程，提交前是这样的：
提交后远程分支变成了这样：
而此时你的同事也在 feature1 上开发，他的分支依然还是：
那么当他 pull 远程 master 的时候，就会有丢失提交纪录。这就是为什么我们经常听到有人说 git rebase 是一个危险命令，因为它改变了历史，我们应该谨慎使用。
feature-2.0.0执行git rebase master后将分支feature-1.0.0上面合并到
master的代码拉取到feature-2.0.0分支提交记录的前面
此时同事在feature-2.0.0分支上有提交记录，执行git pull操作后，拉取不到in_32.png这一条提交记录
in_32.png这条提交记录就丢失了
除非你可以肯定该 feature-1.0.0 分支只有你自己使用，否则请谨慎操作。
