作用 命令 解释
本地 - 基础操作
初始化新仓库 git init
暂存（跟踪）新文件 git add 文件名 常用 .来表示暂存所有文件
提交更新 git commit -m "注释信息"
查看历史记录 git log
查看当前文件状态 git status 文件状态有：1.未跟踪
2.已跟踪（a.已提交 2.以修改 3.以暂存）
给命令配置别名 git config --global alias.ci 其他命令 当要输入git 其他命令 时，只需要输入 git ci 即可
本地 - 分支操作
新建分支 git branch 新分支名
查看所有分支 git branch
新建分支并切换 git checkout -b 新分支名
删除已合并的分支 git branch -d 分支名
强制删除分支（无论是否合并） git branch -D 分支名
切换分支 git checkout 分支名
合并分支-快速合并 git merge 分支名 没有冲突的情况下可直接使用
典型合并 git mege 新分支名
查看未合并文件 git status
解决冲突后，使用 git add 来将其标记为冲突已解决 git add

- 查看每个分支的最后一次提交 git branch -v
- 查看哪些分支已经合并到当前分支 git branch -merged
- 查看所有包含未合并工作的分支 git branch --no-merged
- 查看当前分支所指提交对象 git log --oneline --decorate
- 查看项目分支历史 git log --oneline --decorate --graph --all
远程仓库
将远程仓库克隆到本地 git clone 仓库链接 （克隆不需要git init）
推送提交到远程仓库 git push 远程仓库名 本地分支名
删除远程分支 git push origin --delete 分支名

- 列出仍在远程跟踪但是远程已被删除的无用分支 git remote prune origin --dry-run
- 列出仍在远程跟踪但是远程已被删除的无用分支 git remote prune origin
本地 - 存储
解释：有时，当你在项目的一部分上已经工作一段时间后，所有东西都进入了混乱的状态，而这时你想要切换到另一个分支做一点别的事情。 问题是，你不想仅仅因为过会儿回到这一点而为做了一半的工作创建一次提交。 针对这个问题的答案是:git stash 命令

- 将未完成修改保存到一个栈上 git stash
- 查看存储 git stash list
- 来应用存储然后立即从栈上扔掉它 git stash pop
- 加上将要移除的存储的名字来移除它 git stash drop
- 指定存储 git stash apply stash@{2} 如果不指定一个储藏，Git 认为指定的是最近的储藏
本地 - 撤销
撤销 git commit --amend
本地 - tag
创建轻量标签 git tag v1.4
创建附注标签 git tag v1.4 commitHash ,git tag -a v1.4 commitHash -m 'my version 1.4'
查看特定标签 git show 标签名
远程标签 git push origin 标签名 默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到 共享服务器上。
一次性推送多个tag标签 git push origin --tags
删除标签 git tag -d 标签名
远程删除标签 git push origin **:refs/tags/v1.4** 应该注意的是上述命令并不会从任何远程仓库中移除这个标签，你必须使用git push :refs/tags/ 来更新你的远程仓库：
标出标签 git checkout 标签名

详解典型分支

当前的合并和你之前合并 hotfix 分支的时候不一样。 在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。
如图:

image.png

和之前将分支指针向前推进所不同的是，Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交，它的特别之处在于他有不止一个父提交。

image.png
需要指出的是，Git 会自行决定选取哪一个提交作为最优的共同祖先，并以此作为合并的基础；这和更加古老的 CVS 系统或者 Subversion （1.5 版本之前）不同，在这些古老的版本管理系统中，用户需要自己选择最佳的合并基础。 Git 的这个优势使其在合并操作上比其他系统要简单很多

冲突:
有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们。 如果你对 #53 问题的修改和有关 hotfix 的修改都涉及到同一个文件的同一处，在合并它们的时候就会产生合并冲突此时 Git 做了合并，但是没有自动地创建一个新的合并提交。 Git 会暂停下来，等待你去解决合并产生的冲突。 你可以在合并冲突后的任意时刻使用 git status 命令来查看那些因包含合并冲突而处于未合并（unmerged）状态的文件

任何因包含合并冲突而有待解决的文件，都会以未合并状态标识出来。

  1. <<<<<<< HEAD:index.html
  3. <div id="footer">contact : email.support@github.com</div>
  5. =======
  7. <div id="footer">
  9. please contact us at support@github.com
  11. </div>
  13. \>>>>>>> iss53:index.html

在你解决了所有文件里的冲突之后，对每个文件使用 git add 命令来将其标记为冲突已解决。
一旦暂存这些原本有冲突的文件，Git 就会将它们标记为冲突已解决

撤销 - 后悔药

  • 撤销 git commit --amend

这个命令会将暂存区中的文件提交。如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令），那么快照会保持不变，而你所修改的只是提交信息如果你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作

  1. git commit -m 'initial commit'
  2. git add forgotten_file
  3. git commit –amend

最终你只会有一个提交 - 第二次提交将代替第一次提交的结果

  • 将文件从暂存区中撤回到工作目录 git reset HEAD 文件名
  • 将在工作目录中对文件的修改撤销 git checkout --文件名

HEAD指针

HEAD 是当前分支引用的指针，它总是指向该分支上的最后一次提交。这表示 HEAD将是下一次提交的父结点。通常，理解 HEAD 的最简方式，就是将它看做 当前提交的快照。

  • 查看当前提交对象 git ls-tree -r HEAD
  • 查看暂存区 git ls-files -s