git add .
git commit -m ""
git pull --rebase
git push
git commit --amend 覆盖上次的git commit 提交
git pull --rebase
git fetch
git stash list
git stash 提交到暂存区
git stash pop 拉取暂存区的代码
git stash show 显示最新stash中的修改内容
git stash show -p stash@{1} 次新
git log
git show XX
git cherry-pick A..B
遇到冲突：
（1）--continue
解决代码冲突后，第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 Cherry pick 过程继续执行。
git cherry-pick --continue
（2）--abort
发生代码冲突后，放弃合并，回到操作前的样子。
（3）--quit
发生代码冲突后，退出 Cherry pick，但是不回到操作前
git rebase --continue
git撤销pull命令
pull merge合并出错的时候怎么办。
还没commit：git merge --abort ，丢弃正在进行的合并
已经commit：
git revert -m 1 HEAD 新建一个commit，并且回到合并之前的状态
git reset --hard commit_id 回退到指定的commit节点
git reflog 命令查看你的历史变更记录
git reset --hard HEAD@{n}， n是你要回退到的引用位置）回退
HEAD@{5}
merge 中想修改之前某个分支的commit 信息：
切换到需要修改单个commit 的分支， 在 merge 中不合适修改；
git reset 回滚策略
--hard：重置位置的同时，直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区。就是你的没有commit的修改会被全部擦掉。
--soft：重置位置的同时，保留working Tree工作目录和index暂存区的内容，只让repository中的内容和 reset 目标节点保持一致，因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变，暂存区原有的内容也不变，只是原节点和Reset节点之间的所有差异都会放到暂存区中。
保留工作目录，并把重置 HEAD 所带来的新的差异放进暂存区
--mixed（默认）：重置位置的同时，只保留Working Tree工作目录的內容，但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致，因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。
git reset --mixed（默认）**xx **
所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。
--soft：
所以效果看起来就是工作目录的内容不变，暂存区原有的内容也不变，只是原节点和Reset节点之间的所有差异都会放到暂存区中。
--hard：
效果看起来等同于清空暂存区和工作区。就是你的没有commit的修改会被全部擦掉。
git restore --staged ： 将文件从暂存区撤出，但不会撤销 工作区 文件的更改 （即： git status 提示的 被修改 且 被加入暂存区的内容，会被撤销，工作区文件的更改 不会变）
git restore ：将不在暂存区的文件撤销更改 （即： git status 提示的 被修改 但 未被加入暂存区的内容，会被撤销）
git restore --staged : 撤销 暂存区
git restore : 撤销 本地修改
找回丢失的代码：
git fsck --lost-found |grep commit
git stash apply xxx