镜像：http://marklodato.github.io/visual-git-guide/index-zh-cn.html
责任编辑要量Git中的最常用指示。假如你稍稍认知Git的组织工作基本上原理，这首诗能够让你认知的更有条理。基本上用语
下面的三条指示在组织工作产品目录、存贮产品目录（也叫作检索）和库房间拷贝文档。git add files把现阶段文档放进存贮地区。
git commit给存贮地区聚合镜像并递交。
git reset – files用以撤消最终一场git add files，你也能用git reset撤消大部份存贮地区文档。
git checkout – files把文档从存贮地区导入到组织工作产品目录，用以弃置邻近地区修正。
你能用git reset -p，git checkout -p，or git add -p步入可视化商业模式。也能埃唐佩县存贮地区间接从库房抽出文档或是间接递交标识符。
git commit -a相当于运行git add把大部份现阶段产品目录下的文档加入存贮地区再运行。
git commit files进行一场包含最终一场递交加上组织工作产品目录中文档镜像的递交。并且文档被添加到存贮地区。
git checkout HEAD – files回滚到拷贝最终一场递交。
约定后文中以下面的形式使用图片。
绿色的5位字符表示递交的ID，分别指向父节点。分支用橘色显示，分别指向特定的递交。现阶段分支由附在其上的HEAD标识。这张图片里显示最终5次递交，ed489是最新递交。master分支指向此次递交，另一个maint分支指向祖父递交节点。指示详解Diff有许多种方法查看两次递交间的变动，下面是一些示例。
Commit递交时，Git用存贮地区的文档创建一个新的递交，并把此时的节点设为父节点。然后把现阶段分支指向新的递交节点。下图中，现阶段分支是master。在运行指示之前，master指向ed489，递交后，master指向新的节点f0cec并以ed489作为父节点。
即便现阶段分支是某次递交的祖父节点，git会同样操作。下图中，在master分支的祖父节点maint分支进行一场递交，聚合了1800b。这样，maint分支就不再是master分支的祖父节点。此时，合并[1]（或是衍合[2]）是必须的。
假如想更改一场递交，使用git commit –amend。Git会使用与现阶段递交相同的父节点进行一场新递交，旧的递交会被取消。
另一个例子是分离HEAD递交[3]，后文讲。CheckoutCheckout指示用于从历史递交（或是存贮地区）中拷贝文档到组织工作产品目录，也可用于切换分支。当给定某个文档名（或是打开-p选项，或是文档名和-p选项同时打开）时，Git会从指定的递交中拷贝文档到存贮地区和组织工作产品目录。比如，git checkout HEAD~ foo.c会将递交节点HEAD~（即现阶段递交节点的父节点）中的foo.c导入到组织工作产品目录并且加到存贮地区中。（假如指示中没有指定递交节点，则会从存贮地区中拷贝内容。）注意现阶段分支不会发生变化。
当不指定文档名，而是给出一个（邻近地区）分支时，那么HEAD标识会移动到那个分支（也就是说，我们“切换”到那个分支了），然后存贮地区和组织工作产品目录中的内容会和HEAD对应的递交节点一致。新递交节点（下图中的a47c3）中的大部份文档都会被拷贝（到存贮地区和组织工作产品目录中）；只存在于老的递交节点（ed489）中的文档会被删除；不属于上述两者的文档会被忽略，不受影响。
假如既没有指定文档名，也没有指定分支名，而是一个标签、远程分支、SHA-1值或是是像master~3类似的东西，就得到一个匿名分支，称作detached HEAD（被分离的HEAD标识）。这样能很方便地在历史版本间互相切换。比如说你想要编译1.6.6.1版本的Git，你能运行git checkout v1.6.6.1（这是一个标签，而非分支名），编译，安装，然后切换回另一个分支，比如说git checkout master。然而，当递交操作涉及到“分离的HEAD”时，其行为会略有不同，详情见在下面。
HEAD标识处于分离状态时的递交操作当HEAD处于分离状态（不依附于任一分支）时，递交操作能正常进行，但是不会更新任何已命名的分支。（你能认为这是在更新一个匿名分支。）
一旦此后你切换到别的分支，比如说master，那么这个递交节点（可能）再也不会被引用到，然后就会被弃置掉了。注意这个指示之后就不会有东西引用2eecb。
但是，假如你想保存这个状态，能用指示git checkout -b name来创建一个新的分支。
ResetReset指示把现阶段分支指向另一个位置，并且有选择的变动组织工作产品目录和检索。也用以在从历史库房中拷贝文档到检索，而不动组织工作产品目录。假如不给选项，那么现阶段分支指向到那个递交。假如用–hard选项，那么工作产品目录也更新，假如用–soft选项，那么都不变。
假如没有给出递交点的版本号，那么默认用HEAD。这样，分支指向不变，但是检索会回滚到最终一场递交，假如用–hard选项，组织工作产品目录也同样。
假如给了文档名（或是-p选项），那么组织工作效果和带文档名的checkout差不多，除了检索被更新。
MergeMerge指示把不同分支合并起来。合并前，检索必须和现阶段递交相同。假如另一个分支是现阶段递交的祖父节点，那么合并指示将什么也不做。另一种情况是假如现阶段递交是另一个分支的祖父节点，就导致fast-forward合并。指向只是简单的移动，并聚合一个新的递交。
否则就是一场真正的合并。默认把现阶段递交（ed489 如下所示）和另一个递交（33104）以及他们的共同祖父节点（b325c）进行一场三方合并[4]。结果是先保存现阶段产品目录和检索，然后和父节点33104一起做一场新递交。
Cherry Pickcherry-pick指示“拷贝”一个递交节点并在现阶段分支做一场完全一样的新递交。
Rebase衍合是合并指示的另一种选择。合并把两个父分支合并进行一场递交，递交历史不是线性的。衍合在现阶段分支上重演另一个分支的历史，递交历史是线性的。本质上，这是线性化的自动的 cherry-pick。
下面的指示都在topic分支中进行，而不是master分支，在master分支上重演，并且把分支指向新的节点。注意旧递交没有被引用，将被回收。要限制回滚范围，使用–onto选项。下面的指示在master分支上重演现阶段分支从169a6以来的最近几个递交，即2c33a。
同样有git rebase –interactive让你更方便的完成一些复杂操作，比如弃置、重排、修正、合并递交。没有图片体现这些，细节看这里：git-rebase(1)[5]。技术说明文档内容并没有真正存储在检索（.git/index）或是递交对象中，而是以blob的形式分别存储在数据库中（.git/objects），并用SHA-1值来校验。检索文档用识别码列出相关的blob文档以及别的数据。对于递交来说，以树（tree）的形式存储，同样用对于的哈希值识别。树对应着组织工作产品目录中的文档夹，树中包含的 树或是blob对象对应着相应的子产品目录和文档。每次递交都存储下它的上一级树的识别码。假如用detached HEAD递交，那么最终一场递交会被the reflog for HEAD引用。但是过一段时间就失效，最终被回收，与git commit –amend或是git rebase很像。相关镜像：http://marklodato.github.io/visual-git-guide/index-zh-cn.html#merge
http://marklodato.github.io/visual-git-guide/index-zh-cn.html#rebase
http://marklodato.github.io/visual-git-guide/index-zh-cn.html#detached
http://en.wikipedia.org/wiki/Three-way_merge
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_interactive_mode
良许个人微信
添加良许个人微信即送3套程序员必读资料
→ 精选技术资料共享
→ 高手如云交流社群
m
推荐阅读：
“华为天才少年”自制百大Up奖杯，网友：技术难度不高侮辱性极强
我劝你不要再留QQ邮箱了
万万没想到，“红孩儿”竟然做了程序员，还是CTO!
5T技术资源大放送！包括但不限于：C/C++，Linux，Python，Java，PHP，人工智能，单片机，树莓派1024
