GIT命令大全
git 常用
git查看只commit没有push的文件或者提交记录
git status 查看有多少次 提交了 没有push到版本库 git cherry -v 查看已经提交 但是未传送到远程代码库的提交描述/说明 git log master ^origin/master 查看已经提交但是未传送到远程代码库的提交详情（可能不止一次） git diff HEAD..origin/dev --name-status 查看已经提交但是未传送到远程代码库的提交文件详情
未使用git add缓存代码时，放弃本地修改
git checkout -- filepathname (比如： git checkout -- readme.md） 不要忘记中间的 “--” ，不写就成了检出分支了！！ git checkout . 放弃所有的文件修改
git 代码已经add 但是未commt，撤销git add .
git reset HEAD filepathname （比如： git reset HEAD readme.md）来放弃指定文件的缓存 git reset HEAD . 放弃所以的缓存 此命令用来清除 git 对于文件修改的缓存。相当于撤销 git add 命令所在的工作。在使用本命令后，本地的修改并不会消失，而是回到了git add .之前的状态。继续上面的git checkout .操作，就可以放弃本地的修改。
git 代码已经add 和commit，但未 push推送，如何撤销提交缓存区代码
git reset HEAD^ 撤销commit，撤销git add . ，不删除工作空间改动代码 git reset --soft HEAD^ 撤销commit，不撤销git add . ,不删除工作空间改动代码 git reset--hard HEAD^ 撤销commit，撤销git add .，删除工作空间改动代码
git commit 修改某次的提交描述
git commit --amend 例如： git commit --amend -m "修改后的提交描述" 这样就会把上一次的描述替换了 git commit --amend --no-edit 不改变提交的描述，即多次提交文件采用一次的commit描述
git pull 后恢复到原来版本
git pull 后发现此版本不是想要的版本，但pull后的版本， 在我的当前分支版本基础上又迭代了N个版本。 1、git reflog master (查看本地master分支历史变动纪录) 2、git reset --hard <COMMIT_ID> （恢复到之前位置） git reset --hard master@{1} 例如：撤销本次pull git reflog 然后，reset 到某个版本 git reset --hard dcaf47d
git merge 撤销操作， 撤销本次merge
如果merge了其他分支代码造成了大量的冲突 想撤销本次merge如果操作 1、使用第一点中的reset命令撤销到上一个提交版本 2、执行以下命令直接撤销了本地合并 git merge --abort
git add .的文件想撤销变成红色状态
git rm --cached xxx.txt 来放弃该文件的暂存,即已经git add .的绿色状态文件回到红色新增状态 例如： git add . // 添加所有文件 git commit -m "此次提交描述" 执行完commit之后，想要撤回commit，怎么办？ 可以这样： git reset --soft HEAD^ 这样就成功的撤销了你的commit 注意，仅仅是撤回commit操作，您写的代码仍然保留 HEAD^的意思是上一个版本，也可以写成HEAD1 如果你进行了2次commit，想都撤回，可以使用HEAD2
至于其他参数 -mixed 撤销commit，并且撤销git add . ，不删除工作空间改动代码 这个为默认参数，git reset --mixed HEAD^ 和git rest HEAD^效果是一样的 --soft 撤销commit，不撤销git add . ,不删除工作空间改动代码 --hard 撤销commit，撤销git add .，删除工作空间改动代码
再例如：
(1)、Mixed是默认方式。只保留源码，会回退 commit 和 index 的信息；
(2)、Soft 回退到某个版本。只回退了 commit 的信息，之前写的代码还是保留的，不会恢复到 index file 一级。如果还要提交，直接 commit；
(3)、Hard 彻底回退，本地源码也会变成上一个版本内容，不保留之前 commit 的代码。
打个比方：
版本一：增加文件a.txt，并写下内容 “版本一”
版本二：修改文件a.txt，并增加内容，写下 “版本二”
在版本二的基础上，增加了b.txt文件，并添加内容“版本三”（并git add），然后commit；
一、用Mix方式回到版本一：
增加的b.txt文件则会变成红色的状态（未git add的状态），表示此文件不被git版本追踪控制
二、用Soft 方式回到版本一：
增加的b.txt文件则会变成绿色的状态（git add的状态），表示此文件被git版本追踪控制了
三、用Hard方式回到版本一：
版本二以及版本三的内容全部消失，只剩下版本一的内容
用Mix方式或者Soft方式 都可以撤销commit操作，同时自己做修改过的代码重置为未commit的状态，再次重新commit即可。
注：HEAD~ 和 HEAD^ 都可，HEAD~1 即撤销最新一次的本地提交；HEAD~ 和 HEAD~1 是一个意思。HEAD~~和 HEAD^^ 都是指次次新版本，也就是倒数第三个版本，以此类推，数字同理。
git clone 克隆代码
git clone xxx.git 这样就能轻松把一个仓库代码拉到本地了，但仅仅知道这一点似乎还不太够。一般我们直接 clone 下来不带参数的话，它会默认停留在 master 分支，有的时候我们依旧需要一些其他诉求，比如怎么拉到本地之后自动切到指定分支呢？ git clone xxx.git -b branch1
git init 初始化GIT仓库
除了我们从远端建仓库，有的时候我们自己本地也是可以自己初始化一个 Git 仓库来操作的，这个时候我们就直接使用 git init 就能轻松为当前目录创建一个 git 仓库，也就能开始对当前目录的改动纳入版本管理库了。 不过本地 init 的仓库没法和远端进行交互，所以我们还是需要去 github/gitlab 创建一个远端仓库，然后关联一下，也就是 git remote 命令了。
git remote 用于和远程仓库进行关系绑定处理等等操作
用于和远程仓库进行关系绑定处理等等操作。
git remote add: 添加一个远程版本库关联 git remote rm: 删除某个远程版本库关联
比如我们本地有个初始化好的仓库，同时还有一个创建好的远程空仓库，那么我们就可以执行一下操作让他们关联起来：
git remote add origin xxx.git先添加到本地仓库 git push -u origin master：表示把当前仓库的 master 分支和远端仓库的 master 分支关联起来，后面我们执行 push 或者 pull 都可以非常方便的进行操作了。
git remote set-url origin xxx.git 为项目重新设置git remote url
git fetch 用于从另一个存储库下载对象和引用
git fetch 更新所有分支的简写
git config 配置文件
git config --list 查看配置列表 git config -e 编辑 git 配置文件 # 针对当前仓库 git config -e --global 编辑 git 配置文件# 针对系统上所有仓库
git config --global user.email test@outlook.com 设置邮箱 如果去掉 --global 参数只对当前仓库有效。
清除用户密码，触发推送或者拉取等时候重新输入账号密码即可
git config --system --unset credential.helper
禁止SSL
git config --global http.sslVerify false
记住用户密码
git config --global credential.helper store
换行符
GNU/Linux和Mac OS使用换行(LF)或新行作为行结束字符，而Windows使用换行和回车(LFCR)组合来表示行结束字符。 为了避免这些行结尾的差异的不必要提交，我们必须配置Git客户端写入与Git仓库使用相同的行结束符。 对于Windows系统，可以将Git客户端配置为将行结束符转换为CRLF格式，同时退出，并在提交操作时将其转换回LF格式。以下可根据您的需要来设置。 git config --global core.autocrlf input
配置编缉器
可以配置默认的文本编辑器，Git在需要你输入一些消息时会使用该文本编辑器。缺省情况下，Git使用系统的缺省编辑器，这通常可能是 vi 或者 vim 。如果想使用一个不同的文本编辑器，例如：Emacs，可以按照如下操作： $ git config --global core.editor emacs
配置比较工具
另外一个你可能需要配置的有用的选项是缺省的比较工具它用来解决合并时的冲突。例如，想使用 vimdiff 作为比较工具: $ git config --global merge.tool vimdiff
git status 查看在你上次提交之后是否有对文件进行再次修改
-s 参数来获得简短的输出结果 git status -s
git add 将文件添加到暂存区
git add [file1] [file2] ... 添加一个或多个文件到暂存区 git add [dir] 添加指定目录到暂存区，包括子目录 git add . 添加当前目录下的所有文件到暂存区 git add --no-verify to bypass 防止github提交代码时报husky错误（俗称跳过代码钩子检查）
git commit 提交的描述
git commit -m "某次提交的描述"
一般是git add . 然后需要进行git commit操作，最后才能进行提交
git commit --amend 修改某次的提交描述
例如： git commit --amend -m "修改后的提交描述" 这样就会把上一次的描述替换了
git commit --amend --no-edit 不改变提交的描述
例如： 正常提交 git add * git status // 可省略 git commit -m "2020-11-21 21:30" git push -u origin master 然后又添加或者修改了文件，继续提交，此时正常会让新增一个commit才让提交，使用--no-edit 就会不用新增一个commit了 git add * git status git commit --amend --no-edit git push -f origin master // 这里我直接用了强制提交
git merge -- squash (多个commit记录合并成一个提交记录)
例如： git checkout master git merge --squash feature
git squash 的用法 -- 将多个commit 记录合并成一个，可用于
本地提交测试后合并至远程分支，只留下一个commit 记录 develop分支merge至主线分支时，只有一个 commit 记录，代码整洁
-- 将develop分支代码合并至 master分支，只保留一个commit记录
1、 切换至 master分支
2、 git merge origin/develop --squash
3、 git commit -m "问题修改--测试ok"
git branch 操作分支
在拿到一个项目之后，你首先还是应该看一下当前仓库现在有哪些分支，不要待会创建新分支发现名字重复之类的问题，那这个时候我们就可以使用 git branch 来查看一下相关的分支了。 一般来说如果分支太多的话，还是建议使用可视化工具来查看分支信息，比如 idea、vscode 或者 source tree 等软件等等。
查看分支
git branch // 列出 "本地" 已经存在的分支，当前分支会用 * 标记 git branch -r // 查看 "远程" 仓库的分支列表 git branch -a // 查看所有分支列表（包含 "本地和远程" 分支） git branch -vv // 查看 "本地分支对应的远程分支" (包含最新一次提交的信息) git branch -v // 查看一个分支的最新一次提交 git branch --merged // 查看哪些分支已经合并到当前分支（即哪些分支是当前分支的直接上游） git branch --no-merged // 查看所有未合并工作的分支
创建分支
git branch dev // 创建名为dev的本地分支，创建dev分支后还是指向原来的分支 git branch -b dev // 创建名为dev的本地分支，创建dev分支后指向dev这个新分支 git checkout -b dev_local origin/dev(作用：创建本地分支dev_local并指向远程分支dev)
删除分支
git branch -d dev_lcoal 删除名为dev_lcoal的本地分支，如果该分支有提交未进行合并，则会删除失败。 git branch -D dev_lcoal 强制删除名为dev_lcoal的本地分支，如果该分支有提交未进行合并，则会删除失败。 git push origin --delete dev 删除远程dev分支
给分支重命名
git branch -m oldName newName // 给本地分支重命名
恢复被删除的分支
Git会自行负责分支的管理，所以当我们删除一个分支时，Git只是删除了指向相关提交的指针，但该提交对象依然会留在版本库中。
因此，如果我们知道删除分支时的散列值，就可以将某个删除的分支恢复过来。在已知提交的散列值的情况下恢复某个分支：
git branch <branch_name> <hash_val> 如果我们不知道想要恢复的分支的散列值，可以用reflog命令将它找出来。如：
reflog命令：
显示整个本地仓储的commit，包括所有branch的commit，甚至包括已经撤销的commit。
只要HEAD发生了变化， 就会在reflog里面看得到。
这时恢复分支a_branch分支如下：
git branch <branch_name> HEAD@{4}
git checkout 切出操作
git checkout . 撤销本地所有的修改，没有提交的，都返回到原来的状态 git checkout -- xxx. 撤销单个文件 git checkout -b (branchname) 命令来创建新分支并立即切换到该分支下，从而在该分支中操作
注意：git chekcout 是让文件回到最近一次该文件git commit或git add时的状态。 git rm --cached xxx.txt 来放弃该文件的暂存,即已经git add .的绿色状态文件回到红色新增状态
git stash 储存代码
git stash save 'xxx': 储存变更 git stash list: 查看储存区所有提交列表 git stash pop: 弹出并应用最近的一次储存区的代码提交 git stash drop stash@{n}: 删除某次储存记录 git stash clear: 清除所有 stash 信息 它的数据将被存在你仓库 .git 文件下的 refs/stash 里。
未使用 git add 缓存代码时，可以使用 git checkout -- filepathname (比如： git checkout -- readme.md ，不要忘记中间的 “--” ，不写就成了检出分支了！！)。放弃所有的文件修改可以使用 git checkout . 命令。
从stash创建分支
如果你储藏了一些工作，暂时不去理会，然后继续在你储藏工作的分支上工作，你在重新应用工作时可能会碰到一些问题。如果尝试应用的变更是针对一个你那之后修改过的文件，你会碰到一个归并冲突并且必须去化解它。如果你想用更方便的方法来重新检验你储藏的变更，你可以运行 git stash branch，这会创建一个新的分支，检出你储藏工作时的所处的提交，重新应用你的工作，如果成功，将会丢弃储藏。 这是一个很棒的捷径来恢复储藏的工作然后在新的分支上继续当时的工作。
git reflog 查看提交记录
查看提交记录
撤销一些命令汇总
# 恢复暂存区的指定文件到工作区
$ git checkout [file]
# 恢复某个commit的指定文件到暂存区和工作区
$ git checkout [commit] [file]
# 恢复暂存区的所有文件到工作区
$ git checkout .
# 重置暂存区的指定文件，与上一次commit保持一致，但工作区不变
$ git reset [file]
# 重置暂存区与工作区，与上一次commit保持一致
$ git reset --hard
# 重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变
$ git reset [commit]
# 重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致
$ git reset --hard [commit]
# 重置当前HEAD为指定commit，但保持暂存区和工作区不变
$ git reset --keep [commit]
# 新建一个commit，用来撤销指定commit
# 后者的所有变化都将被前者抵消，并且应用到当前分支
$ git revert [commit]
# 暂时将未提交的变化移除，稍后再移入
$ git stash
$ git stash pop
git rebase 变基
git rebase命令在另一个分支基础之上重新应用，用于把一个分支的修改合并到当前分支 使用语法
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
[<upstream> [<branch>]]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
--root [<branch>]
git rebase --continue | --skip | --abort | --quit | --edit-todo
示例 假设你现在基于远程分支”origin“，创建一个叫”mywork“的分支。 $ git checkout -b mywork origin 结果如下所示 - 现在我们在这个分支(mywork)做一些修改，然后生成两个提交(commit). git commit git commit ... ... 但是与此同时，有些人也在”origin“分支上做了一些修改并且做了提交了，这就意味着”origin“和”mywork“这两个分支各自”前进”了，它们之间”分叉”了。
在这里，你可以用”pull“命令把”origin“分支上的修改拉下来并且和你的修改合并； 结果看起来就像一个新的”合并的提交”(merge commit):
但是，如果你想让”mywork“分支历史看起来像没有经过任何合并一样，也可以用 git rebase，如下所示: git rebase origin 这些命令会把你的”mywork“分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到”.git/rebase“目录中),然后把”mywork“分支更新 到最新的”origin“分支，最后把保存的这些补丁应用到”mywork“分支上。
当’mywork‘分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除.
现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别：
在rebase的过程中，也许会出现冲突(conflict)。在这种情况，Git会停止rebase并会让你去解决冲突；在解决完冲突后，用”git add“命令去更新这些内容的索引(index), 然后，你无需执行 git commit,只要执行:
git rebase --continue 这样git会继续应用(apply)余下的补丁。 在任何时候，可以用--abort参数来终止rebase的操作，并且”mywork“ 分支会回到rebase开始前的状态。 $ git rebase --abort
其他： git rebase -i HEAD~3 将Commit-3、Commit-2和Commit-1的提交合并成一次提交 -i 指的是 --interactive ，HEAD~3 指的是最近三次commit。 当然我们也可以直接指定最新的一个想保留的 Commit的ID，在上面的例子中就是Commit-0的ID，因此我们也可以写成 git rebase -i d2b9b78 执行该命令后，我们会进入到这么如下一个界面 pick：使用该commit squash：使用该 Commit，但会被合并到前一个 Commit 当中 fixup：就像 squash 那样，但会抛弃这个 Commit 的 Commit message
git cherry-pick 优选所选提交
对于多分支的代码库，将代码从一个分支转移到另一个分支是常见需求。
这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并（git merge）。另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 Cherry pick。
一、基本用法
git cherry-pick命令的作用，就是将指定的提交（commit）应用于其他分支。
$ git cherry-pick <commitHash>
上面命令就会将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样。
举例来说，代码仓库有master和feature两个分支。
a - b - c - d Master
\
e - f - g Feature
现在将提交f应用到master分支。
# 切换到 master 分支
$ git checkout master
# Cherry pick 操作
$ git cherry-pick f
上面的操作完成以后，代码库就变成了下面的样子。
a - b - c - d - f Master
\
e - f - g Feature
从上面可以看到，master分支的末尾增加了一个提交f。
git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交。
$ git cherry-pick feature
上面代码表示将feature分支的最近一次提交，转移到当前分支。
二、转移多个提交
Cherry pick 支持一次转移多个提交。
$ git cherry-pick <HashA> <HashB>
上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
如果想要转移一系列的连续提交，可以使用下面的简便语法。
$ git cherry-pick A..B
上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。
注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。
$ git cherry-pick A^..B
三、配置项
git cherry-pick命令的常用配置项如下。
（1）-e，--edit
打开外部编辑器，编辑提交信息。
（2）-n，--no-commit
只更新工作区和暂存区，不产生新的提交。
（3）-x
在提交信息的末尾追加一行(cherry picked from commit ...)，方便以后查到这个提交是如何产生的。
（4）-s，--signoff
在提交信息的末尾追加一行操作者的签名，表示是谁进行了这个操作。
（5）-m parent-number，--mainline parent-number
如果原始提交是一个合并节点，来自于两个分支的合并，那么 Cherry pick 默认将失败，因为它不知道应该采用哪个分支的代码变动。
-m配置项告诉 Git，应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号。
$ git cherry-pick -m 1 <commitHash>
上面命令表示，Cherry pick 采用提交commitHash来自编号1的父分支的变动。
一般来说，1号父分支是接受变动的分支（the branch being merged into），2号父分支是作为变动来源的分支（the branch being merged from）。
四、代码冲突
如果操作过程中发生代码冲突，Cherry pick 会停下来，让用户决定如何继续操作。
（1）--continue
用户解决代码冲突后，第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 Cherry pick 过程继续执行。
$ git cherry-pick --continue
（2）--abort
发生代码冲突后，放弃合并，回到操作前的样子。
（3）--quit
发生代码冲突后，退出 Cherry pick，但是不回到操作前的样子。
五、转移到另一个代码库
Cherry pick 也支持转移另一个代码库的提交，方法是先将该库加为远程仓库。
$ git remote add target git://gitUrl
上面命令添加了一个远程仓库target。
然后，将远程代码抓取到本地。
$ git fetch target
上面命令将远程代码仓库抓取到本地。
接着，检查一下要从远程仓库转移的提交，获取它的哈希值。
$ git log target/master
最后，使用git cherry-pick命令转移提交。
$ git cherry-pick <commitHash>
git diff 比较文件的不同
git diff 命令比较文件的不同，即比较文件在暂存区和工作区的差异。
git diff 命令显示已写入暂存区和已经被修改但尚未写入暂存区文件的区别。
git diff 有两个主要的应用场景。
尚未缓存的改动：git diff [file] 查看已缓存的改动： git diff --cached [file] 或者 git diff --staged [file] 查看已缓存的与未缓存的所有改动：git diff HEAD 显示摘要而非整个 diff：git diff --stat
git diff origin/dev origin/sit 比较远程dev分支和远程sit分支的区别
git log 查看提交历史
git log - 查看历史提交记录。
git blame <file> - 以列表形式查看指定文件的历史修改记录。
git log --oneline 选项来查看历史记录的简洁的版本
git log --reverse --oneline 参数来逆向显示所有日志
如果你要指定日期，可以执行几个选项：--since 和 --before，但是你也可以用 --until 和 --after。
例如，如果我要看 Git 项目中三周前且在四月十八日之后的所有提交，我可以执行这个（我还用了 --no-merges 选项以隐藏合并提交）
git log --oneline --before={3.weeks.ago} --after={2010-04-18} --no-merges
git shortlog 命令用于汇总git日志输出
场景假设一个开发小组有10个程序员，他们用 Git 做版本控制，某一天程序员A push了当天的几个commit之后，突然在想“我在这个项目到底一共进行过多少次commit？谁比我commit更多？多多少？谁是组里面进行最多 commit的？谁是最少的？” Git 非常人性化地支持这样一个命令： $ git shortlog
这个命令会返回这个 git repository 底下每个用户进行 commit 的次数，以及每次 commit 的注释。 -s 参数省略每次 commit 的注释，仅仅返回一个简单的统计。-n 参数按照 commit 数量从多到少的顺利对用户进行排序 例如： git shortlog -s git shortlog -s -n
git describe命令显示离当前提交最近的标签
该命令查找从提交可访问的最新标记。 如果标签指向提交，则只显示标签。 否则，它将标记名称与标记对象之上的其他提交数量以及最近提交的缩写对象名称后缀。 默认情况下(不包括--all或--tags)git描述只显示注释标签。
git show 查看某一次提交详细信息
git show命令采用SHA-1提交ID作为参数 例如：git show be24e214620fa072efa877e1967571731c465884 显示的结果中，可以看到符号 “+“ ，表示添加的内容。如果有 “-”则表示删除的内容
git reset 回退版本
git reset [--soft | --mixed | --hard] [HEAD] --mixed 为默认，可以不用带该参数，用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。 git reset [HEAD]
git reset HEAD^ # 回退所有内容到上一个版本 git reset HEAD^ hello.php # 回退 hello.php 文件的版本到上一个版本 $ git reset 052e # 回退到指定版本
--soft 参数用于回退到某个版本： git reset --soft HEAD $ git reset --soft HEAD~3 # 回退上上上一个版本 --hard 参数撤销工作区中所有未提交的修改内容，将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交 git reset --hard HEAD
git reset --hard HEAD~3 # 回退上上上一个版本 git reset –hard bae128 # 回退到某个版本回退点之前的所有信息。 $ git reset --hard origin/master # 将本地的状态回退到和远程的一样
git reset HEAD git reset HEAD 命令用于取消已缓存的内容 git reset HEAD hello.txt 就是把git add 但还没git commit 的内容取消添加，回到新增红色状态 简而言之，执行 git reset HEAD 以取消之前 git add 添加，但不希望包含在下一提交快照中的缓存
git clean 清除操作
git clean命令用来从你的工作目录中删除所有没有track过的文件 git clean命令用来从你的工作目录中删除所有没有track过的文件 git clean经常和git reset --hard一起使用. 记住reset只影响被track过的文件, 所以需要clean来删除没有track过的文件. 结合使用这两个命令能让你的工作目录完全回到一个指定的的状态
git clean -n 是一次clean的演习, 告诉你哪些文件会被删除. 记住它不会真正地删除文件, 只是一个提醒。
git clean -f 删除当前目录下所有没有track过的文件. 它不会删除 .gitignore 文件里指定的文件夹和文件, 不管这些文件有没有被track过
git clean -f 删除指定路径下的没有被track过的文件
git clean -df 删除当前目录下没有被track过的文件和文件夹
git clean -xf 删除当前目录下所有没有track过的文件. 不管它是否是 .gitignore 文件里面指定的文件夹和文件
git reset --hard 和 git clean -f 是一对好基友. 结合使用它们能让你的工作目录完全回退到最近一次commit的时候（唯一有效的一句，其他都是废话一点用没有）
git reset --hard 1 git clean 对于刚编译过的项目也非常有用. 如, 它能轻易删除掉编译后生成的 .o 和 .exe 等文件. 这个在打包要发布一个release的时候非常有用
下面的例子要删除所有工作目录下面的修改, 包括新添加的文件. 假设你已经提交了一些快照了, 而且做了一些新的开发
git reset --hard
git clean -df 运行后, 工作目录和缓存区回到最近一次commit时候一摸一样的状态，git status会告诉你这是一个干净的工作目录, 又是一个新的开始了！
git rm 用于从工作区和索引中删除文件
git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…
从索引中删除文件，或从工作树和索引中删除文件。 git rm不会从您的工作目录中删除文件。 (没有任何选项只能从工作树中删除文件，并将其保留在索引中;)要删除的文件必须与分支的提示相同，并且在索引中不能对其内容进行更新，尽管可以使用-f选项覆盖(默认行为)。 当给出--cached时，暂存区内容必须与分支的提示或磁盘上的文件相匹配，从而仅将文件从索引中删除。
使用 git rm 来删除文件，同时还会将这个删除操作记录下来；而使用 rm 来删除文件，仅仅是删除了物理文件，没有将其从 git 的记录中剔除。
直观的来讲，git rm 删除过的文件，执行 git commit -m "commit message or mark" 提交时，会自动将删除该文件的操作提交上去。
而对于用 rm 命令直接删除的文件，执行 git commit -m "commit message or mark"提交时，则不会将删除该文件的操作提交上去。不过不要紧，即使你已经通过 rm 将某个文件删除掉了，也可以再通过 git rm 命令重新将该文件从 git 的记录中删除掉，这样的话，在执行 git commit -m "commit message or mark" 以后，也能将这个删除操作提交上去。
如果之前不小心用 rm 命令删除了一大批文件呢？如此时用 git rm 逐个地再删除一次就显得相当卵痛了。可如下的方式做提交： git commit -am "commit message or mark"
git mv 命令用于移动或重命名文件，目录或符号链接
git mv <options>… <args>…
描述移动或重命名文件，目录或符号链接。
git mv [-v] [-f] [-n] [-k] <source> <destination>
git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
Shell
在第一种形式中，它将重命名<source>为<destination>，<source>必须存在，并且是文件，符号链接或目录。 在第二种形式中，最后一个参数必须是现有的目录; 给定的源(<source>)将被移动到这个目录中。
索引在成功完成后更新，但仍必须提交更改。
示例以下是一些示例 -
把一个文件：text.txt 移动到 mydir，可以执行以下操作 -
$ git mv text.txt mydir
运行上面的 git mv 其实就相当于运行了3条命令：
$ mv test.txt mydir/
$ git rm test.txt
$ git add mydir
git rev-list 按时间倒序列出 commit（即 reverse-list）
git rev-list A git rev-list B..D
git archive 生成一个可供发布的压缩包
git symbolic-ref 可以读取、修改和删除符号引用
git symbolic-ref --short HEAD 查看当前分支名称 什么是符号引用呢？它表示一个以 refs 开头的文件（比如 refs/heads/develop），这个文件保存着本地每个分支当前所处 commit。 我们可以打开 git 项目的 .git 文件夹，在其中的 refs/heads 文件夹中会保存各个分支当前所指向的 commit: HEAD 指的是 .git/HEAD，就是一个文件，保存着当前指向的符号引用： 因此 git symbolic-ref --short HEAD 的含义就是读取 .git/HEAD 文件的内容，我这里就是 refs/heads/develop 文件，因此就得出当前分支是 develop 分支。
Git 工作区、暂存区和版本库
基本概念 我们先来理解下 Git 工作区、暂存区和版本库概念：
工作区：就是你在电脑里能看到的目录。 暂存区：英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。 版本库：工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。 下面这个图展示了工作区、版本库中的暂存区和版本库之间的关系：
图中左侧为工作区，右侧为版本库。在版本库中标记为 "index" 的区域是暂存区（stage/index），标记为 "master" 的是 master 分支所代表的目录树。
图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。
图中的 objects 标识的区域为 Git 的对象库，实际位于 ".git/objects" 目录下，里面包含了创建的各种对象及内容。
当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。
当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。
当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。
当执行 git rm --cached <file> 命令时，会直接从暂存区删除文件，工作区则不做出改变。
当执行 git checkout . 或者 git checkout -- <file> 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区中的改动。
当执行 git checkout HEAD . 或者 git checkout HEAD <file> 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。
git help 获取帮助
若在使用 Git 时需要获取帮助，有三种方法可以找到 Git 命令的使用手册：
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
例如，要想获得 config 命令的手册，执行
$ git help config
这些命令很棒，因为随时随地可以使用而无需联网。
其他问题
Git操作失败并提示Another git process seems to be running in this......
Git操作的过程中突然显示Another git process semms to be running in this repository, e.g. an editor opened by ‘git commit’. Please make sure all processes are terminated then try again. If it still fails, a git process remove the file manually to continue… 翻译过来就是git被另外一个程序占用，重启机器也不能够解决。
原因在于Git在使用过程中遭遇了奔溃，部分被上锁资源没有被释放导致的。
解决方案： 进入项目文件夹下的 .git文件中（显示隐藏文件夹或rm .git/index.lock）删除index.lock文件即可。
