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