Git 使用快速入门，图解Git中的最常用命令。这里只讲命令和原理，有些图形化工具会让操作变得很简单。

基本说明

版本控制

什么是版本控制

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 除了项目源代码，你可以对任何类型的文件进行版本控制。

为什么要版本控制

有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。

认识 Git

Git 简史

Linux  内核项目组当时使用分布式版本控制系统 BitKeeper 来管理和维护代码。但是，后来开发 BitKeeper 的商业公司同 Linux  内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 Linux 开源社区（特别是 Linux  的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统，而且对新的版本控制系统做了很多改进。

Git 与其他版本管理系统的主要区别

Git 在保存和对待各种信息的时候与其它版本控制系统有很大差异，尽管操作起来的命令形式非常相近，理解这些差异将有助于防止你使用中的困惑。

下面我们主要说一个关于 Git 其他版本管理系统的主要差别：对待数据的方式。

Git采用的是直接记录快照的方式，而非差异比较。我后面会详细介绍这两种方式的差别。

大部分版本控制系统（CVS、Subversion、Perforce、Bazaar 等等）都是以文件变更列表的方式存储信息，这类系统将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

具体原理如下图所示，理解起来其实很简单，每个我们对提交更新一个文件之后，系统记录都会记录这个文件做了哪些更新，以增量符号Δ(Delta)表示。下图来源于Git官网。

我们怎样才能得到一个文件的最终版本呢？

很简单，高中数学的基本知识，我们只需要将这些原文件和这些增加进行相加就行了。

这种方式有什么问题呢？

比如我们的增量特别特别多的话，如果我们要得到最终的文件是不是会耗费时间和性能。

Git  不按照以上方式对待或保存数据。 反之，Git 更像是把数据看作是对小型文件系统的一组快照。 每次你提交更新，或在 Git  中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效，如果文件没有修改，Git  不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。下图来源于Git官网。

Git 的三种状态

Git 有三种状态，你的文件可能处于其中之一：

•已提交（committed）：数据已经安全的保存在本地数据库中。•已修改（modified）：已修改表示修改了文件，但还没保存到数据库中。•已暂存（staged）：表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

由此引入 Git 项目的三个工作区域的概念：Git 仓库(.git directoty) 、工作目录(Working Directory) 以及 暂存区域(Staging Area) 。下图来源于Git官网。

基本的 Git 工作流程如下：

•在工作目录中修改文件。•暂存文件，将文件的快照放入暂存区域。•提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

Git 使用快速入门

获取 Git 仓库

有两种取得 Git 项目仓库的方法。

•在现有目录中初始化仓库: 进入项目目录运行 git init 命令,该命令将创建一个名为 .git 的子目录。•从一个服务器克隆一个现有的 Git 仓库: git clone [url] 自定义本地仓库的名字: git clone [url] directoryname

记录每次更新到仓库

•检测当前文件状态 : git status•提出更改（把它们添加到暂存区）：git add filename (针对特定文件)、git add *(所有文件)、git add *.txt（支持通配符，所有 .txt 文件）•忽略文件：.gitignore 文件•提交更新: git commit -m "代码提交信息" （每次准备提交前，先用 git status 看下，是不是都已暂存起来了， 然后再运行提交命令 git commit）•跳过使用暂存区域更新的方式 : git commit -a -m "代码提交信息"。 git commit 加上 -a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤。•移除文件 ：git rm filename （从暂存区域移除，然后提交。）•对文件重命名 ：git mv README.md README(这个命令相当于mv README.md README、git rm README.md、git add README 这三条命令的集合)

推送改动到远程仓库

• 如果你还没有克隆现有仓库，并欲将你的仓库连接到某个远程服务器，你可以使用如下命令添加：·git remote add origin ,比如我们要让本地的一个仓库和 Github 上创建的一个仓库关联可以这样git remote add origin https://github.com/Snailclimb/test.git将

• 将这些改动提交到远端仓库：git push origin master (可以把 master 换成你想要推送的任何分支)

  
  

如此你就能够将你的改动推送到所添加的服务器上去了。

远程仓库的移除与重命名

•将 test 重命名位 test1：git remote rename test test1•移除远程仓库 test1:git remote rm test1

查看提交历史

在提交了若干更新，又或者克隆了某个项目之后，你也许想回顾下提交历史。 完成这个任务最简单而又有效的工具是 git log 命令。git log 会按提交时间列出所有的更新，最近的更新排在最上面。

可以添加一些参数来查看自己希望看到的内容：

只看某个人的提交记录：

git log --author=bob

撤销操作

有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 --amend 选项的提交命令尝试重新提交：

git commit --amend

取消暂存的文件

git reset filename

撤消对文件的修改:

git checkout -- filename

假如你想丢弃你在本地的所有改动与提交，可以到服务器上获取最新的版本历史，并将你本地主分支指向它：

git fetch origingit reset --hard origin/master

分支

分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”分支。在其他分支上进行开发，完成后再将它们合并到主分支上。

我们通常在开发新功能、修复一个紧急 bug 等等时候会选择创建分支。单分支开发好还是多分支开发好，还是要看具体场景来说。

创建一个名字叫做 test 的分支

git branch test

切换当前分支到 test（当你切换分支的时候，Git 会重置你的工作目录，使其看起来像回到了你在那个分支上最后一次提交的样子。 Git 会自动添加、删除、修改文件以确保此时你的工作目录和这个分支最后一次提交时的样子一模一样）

git checkout test

你也可以直接这样创建分支并切换过去(上面两条命令的合写)

git checkout -b feature_x

切换到主分支

git checkout master

合并分支(可能会有冲突)

git merge test

把新建的分支删掉

git branch -d feature_x

将分支推送到远端仓库（推送成功后其他人可见）：

git push origin

图解

基本用法

上面的四条命令在工作目录、暂存目录(也叫做索引)和仓库之间复制文件。

• 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.

• 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分支的祖父节点。此时，合并 (或者 衍合) 是必须的。

如果想更改一次提交，使用  git commit --amend。git会使用与当前提交相同的父节点进行一次新提交，旧的提交会被取消。

另一个例子是分离HEAD提交,后文讲。

Checkout

checkout命令用于从历史提交（或者暂存区域）中拷贝文件到工作目录，也可用于切换分支。

当给定某个文件名（或者打开-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来创建一个新的分支。

Reset