在这里主要想和大家分享的是，如果你想知道git相关的东西，可以到官方的文档上去查，大家可能不知道官方文档在哪里，这里是git 官方文档 这是中文的 你肯定可以看懂的
以下都是我自己觉得有用的部分，特意摘取出来，如果你觉得有意思，可以瞅一眼。
最后，我还是建议你去看官方文档
三种状态
记住 GIT 三种状态
- 已修改（modified) 【修改是在工作区域做的事情】
- 已暂存（staged)【add 之后 就到了暂存区】
- 已提交（committed)【commit之后 就到了这里】
基本的 Git 工作流程如下：
- 在工作目录中修改文件。
- 暂存文件，将文件的快照放入暂存区域。
-
提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录
image.png
配置
Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置：
/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。 如果使用带有 --system 选项的 git config 时，它会从此文件读写配置变量。
~/.gitconfig 或 ~/.config/git/config 文件：只针对当前用户。 可以传递 --global 选项让 Git 读写此文件。
当前使用仓库的 Git 目录中的 config 文件（就是 .git/config）：针对该仓库。
每一个级别覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。
查看设置 git config --list
使用
git 常用
克隆并改变名字： git clone https://github.com/libgit2/libgit2 mylibgit
git纳管的文件只有如下这几种状态 大体分为(已跟踪 和 未跟踪)
git status -s 简短的输出
git diff 本身只显示尚未暂存的改动
要查看尚未暂存的文件更新了哪些部分(执行git add前)，输入 git diff
要查看暂存的文件更新了哪些部分(执行git add后)，输入 git diff --cached 或者 git diff --staged
要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除（确切地说，是从暂存区域移除），然后提交。 可以用 git rm 命令完成此项工作，并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了。
我们想把文件从 Git 仓库中删除（亦即从暂存区域移除），但仍然希望保留在当前工作目录中。 换句话说，你想让文件保留在磁盘，但是并不想让 Git 继续跟踪。 当你忘记添加 .gitignore 文件，不小心把一个很大的日志文件或一堆 .a 这样的编译生成文件添加到暂存区时，这一做法尤其有用。 为达到这一目的，使用 --cached 选项
git rm --cached README
移动文件 git mv file_from file_to
git log
最近两次提交连带修改的地方 git log -p -2
简短一些 看看那些文件发生变化 git log --stat
还可以更好看一些 git log --pretty=oneline 可选项有 short，full 和 fuller
这个也很不错呦 git log --pretty=format:"%h %s" --graph
git 撤销操作
git commit --amed
从暂存区删除 git status 会给到提示 git reset HEAD
撤销修改 工作目录中 git checkout
git远程仓库
git remote -h
git tag
分为轻量标签和与附注标签
应用区别： 附注标签需要 git tag -a newtag -m "information"
git别名
git config --global alias.co checkout
git 分支介绍
Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支
分支新建与合并
执行如下命令 进行merge操作
$ git checkout master
$ git merge hotfix
注意 这里的merge因为没有什么冲突 由于当前 master 分支所指向的提交是你当前提交（有关 hotfix 的提交）的直接上游，所以 Git 只是简单的将指针向前移动。 换句话说，当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推进（指针右移），因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进（fast-forward）”
分支的合并
假设你已经修正了 #53 问题，并且打算将你的工作合并入 master 分支。 为此，你需要合并 iss53 分支到 master 分支，这和之前你合并 hotfix 分支所做的工作差不多。 你只需要检出到你想合并入的分支，然后运行 git merge 命令
$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
这和你之前合并 hotfix 分支的时候看起来有一点不一样。 在这种情况下，你的开发历史从一个更早的地方开始分叉开来（diverged）。 因为，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。
merge的时候 会产生一个新的提交
在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase 上面说到了merge 现在说下rebase, rebase的时候主要记住一点，不要对在你的仓库外有副本的分支执行变基。
变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交。 如果你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用 git rebase 命令重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你还要拉取并整合他们修改过的提交，事情就会变得一团糟。
所以 rebase只有在你本地(未推送前到公共仓库)合并之前使用 其他的时候 不应该使用
以上是通过merge来实现的 整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）
当然还有另外一种方法，你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
它的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master）的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。
$ git checkout master
$ git merge experiment
此时，C4' 指向的快照就和上面使用 merge 命令的例子中 C5 指向的快照一模一样了。 这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。
一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个其他人维护的项目贡献代码时。 在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。 这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。
请注意，无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。
git 重置揭密
git远程分支
