git基础
stash 命令能够将还未 commit 的代码存起来，让你的工作目录变得干净。
命令使用
你只需要：
git stash
就这么简单，代码就被存起来了。
当你修复完线上问题，切回 某个分支，想恢复代码也只需要：
git stash apply
相关命令
# 保存当前未commit的代码
git stash
# 保存当前未commit的代码并添加备注
git stash save "备注的内容"
?
# 列出stash的所有记录
git stash list
?
# 删除stash的所有记录
git stash clear
?
# 应用最近一次的stash
git stash apply
?
# 应用最近一次的stash，随后删除该记录
git stash pop
?
# 删除最近的一次stash
git stash drop
描述
完全不接触索引文件或工作树（但会像所有模式一样，将头部重置为）。这使您的所有更改的文件更改为“要提交的更改”。
回退你已提交的 commit，并将 commit 的修改内容放回到暂存区。
一般我们在使用 reset 命令时，git reset --hard会被提及的比较多，它能让 commit 记录强制回溯到某一个节点。而git reset --soft的作用正如其名，--soft(柔软的) 除了回溯节点外，还会保留节点的修改内容。
应用场景
回溯节点，为什么要保留修改内容？
应用场景1：有时候手滑不小心把不该提交的内容 commit 了，这时想改回来，只能再 commit 一次，又多一条“黑历史”。
应用场景2：规范些的团队，一般对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现问题排查。本来属于两块不同功能的修改，一起 commit 上去，这种就属于不规范。这次恰好又手滑了，一次性 commit 上去。
命令使用
学会reset --soft之后，你只需要：
# 恢复最近一次 commit
git reset --soft HEAD^
reset --soft相当于后悔药，给你重新改过的机会。对于上面的场景，就可以再次修改重新提交，保持干净的 commit 记录。
以上说的是还未 push 的commit。对于已经 push 的 commit，也可以使用该命令，不过再次 push 时，由于远程分支和本地分支有差异，需要强制推送git push -f来覆盖被 reset 的 commit。
还有一点需要注意，在reset --soft指定 commit 号时，会将该 commit 到最近一次 commit 的所有修改内容全部恢复，而不是只针对该 commit。
描述
给定一个或多个现有提交，应用每个提交引入的更改，为每个提交记录一个新的提交。这需要您的工作树清洁（没有从头提交的修改）。
将已经提交的 commit，复制出新的 commit 应用到分支里
应用场景
commit 都提交了，为什么还要复制新的出来？
应用场景1：有时候版本的一些优化需求开发到一半，可能其中某一个开发完的需求要临时上，或者某些原因导致待开发的需求卡住了已开发完成的需求上线。这时候就需要把 commit 抽出来，单独处理。
应用场景2：有时候开发分支中的代码记录被污染了，导致开发分支合到线上分支有问题，这时就需要拉一条干净的开发分支，再从旧的开发分支中，把 commit 复制到新分支。
命令使用
复制单个
需要把 b 复制到另一个分支，首先把 commitHash 复制下来，然后切到 master 分支。
复制多个
以上是单个 commit 的复制，下面再来看看 cherry-pick 多个 commit 要如何操作。
git cherry-pick commit1 commit2
上面的命令将 commit1 和 commit2 两个提交应用到当前分支。
git cherry-pick commit1^..commit2
上面的命令将 commit1 到 commit2 这个区间的 commit 都应用到当前分支（包含commit1、commit2），commit1 是最早的提交。
（***1）切到 master 分支，使用区间的cherry-pick。发现代码冲突，cherry-pick中断了。这时需要解决代码冲突，重新提交到暂存区。
然后使用cherry-pick --continue让cherry-pick继续进行下去。最后 e 也被复制进来，整个流程就完成了。
以上是完整的流程，但有时候可能需要在代码冲突后，放弃或者退出流程：
git cherry-pick --abort
回到操作前的样子，就像什么都没发生过。
git cherry-pick --quit
不回到操作前的样子。即保留已经cherry-pick成功的 commit，并退出cherry-pick流程。
描述
给定一个或多个现有提交，恢复相关提交引入的更改，并记录一些这些更改的新提交。这就要求你的工作树是干净的（没有来自头部的修改）。
将现有的提交还原，恢复提交的内容，并生成一条还原记录。
应用场景
应用场景：有一天测试突然跟你说，你开发上线的功能有问题，需要马上撤回，否则会影响到系统使用。这时可能会想到用 reset 回退，可是你看了看分支上最新的提交还有其他同事的代码，用 reset 会把这部分代码也撤回了。由于情况紧急，又想不到好方法，还是任性的使用 reset，然后再让同事把他的代码合一遍（同事听到想打人），于是你的技术形象在同事眼里一落千丈。
命令使用
revert 普通提交
学会 revert 之后，立马就可以拯救这种尴尬的情况。
现在 master 记录如下：
git revert 21dcd937fe555f58841b17466a99118deb489212
revert 掉自己提交的 commit。
因为 revert 会生成一条新的提交记录，这时会让你编辑提交信息，编辑完后 :wq 保存退出就好了。
再来看下最新的 log，生成了一条 revert 记录，虽然自己之前的提交记录还是会保留着，但你修改的代码内容已经被撤回了。
描述
此命令管理重录中记录的信息。
如果说reset --soft是后悔药，那 reflog 就是强力后悔药。它记录了所有的 commit 操作记录，便于错误操作后找回记录。
应用场景
应用场景：某天你眼花，发现自己在其他人分支提交了代码还推到远程分支，这时因为分支只有你的最新提交，就想着使用reset --hard，结果紧张不小心记错了 commitHash，reset 过头，把同事的 commit 搞没了。没办法，reset --hard是强制回退的，找不到 commitHash 了，只能让同事从本地分支再推一次（同事瞬间拳头就硬了，怎么又是你）。于是，你的技术形象又一落千丈。
命令使用
分支记录如上，想要 reset 到 b。
误操作 reset 过头，b 没了，最新的只剩下 a。
这时用git reflog查看历史记录，把错误提交的那次 commitHash 记下。
再次 reset 回去，就会发现 b 回来了。
git?push?-f
作用场景：
当第一次把本地代码提交到你一个新建的远程空仓库，如果有冲突，推送不上去，第一次的时候可以使用强制推送命令，直接覆盖远程仓库所有东西
（1）先切换到layout分支 推送当前最新代码到远程仓库
git?checkout?layout
git?add?.
git?commit?-m?'fest: 【项目名称】推送内容'
git?pull?//拉取代码下来后，如果有冲突，解决冲突
git?push
(2) 再切换回到需要合并代码的master分支（就是把layout分支代码合并到maste的分支），并且拉取该分支的最新代码，查看是否有冲突，假设有冲突就解决冲突
git?checkout?master
git?pull?//拉取代码下来后，如果有冲突，解决冲突
(3) master分支没有冲突代码后，就可以合并分支了
目前是在master分支，就是在合并代码的时候，需要把代码合并到某个分支，当前就应当位于某个分支内，然后再把另一个分支的代码，合并到当前所处的分支
git?merge?layout
上面的merge命令就合并代码了，假设代码合并后有冲突，就解决冲突
（4）再把合并代码后的master分支，推送上远程仓库
git?add?.
git?commit?-m?'fest: 【项目名称】推送内容'
git?pull?//拉取代码下来后，如果有冲突，解决冲突
git?push