Git使用方法(一)

Linux项目开始后，绝大多数的Linux内核维护工作都花在了提交补丁和保存归档的 繁琐事物上(1991——2002年间)。到2002年，整个项目组开始启用分布式版本控制系统BitKeeper来管理和维护代码。到2005年的时 候，开发BitKeeper的商业公司同Linux内核开发社区的合作关系结束，他们收回了免费使用BitKeeper的权力。这就使得Linux开源社区不得不开发了自己的版本控制软件Git。

其他系统在每个版本中记录着各个文件的具体差异

Git保存每次更新的文件快照

这是Git与其他版本控制系统的主要差别，其他版本控制系统节省了磁盘空间，但增加了计算量；Git是都保存了，因为磁盘原来越便宜。

在保存到Git之前，所有数据都要进行内容的校验和(checksum)计算，并将此结 果作为数据的唯一标识和索引。Git使用SHA-1算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个SHA-1哈希值，作为指纹字符串。该 字符由40个十六个进制字符(0-9及a-f)组成，看起来就像是：

首先安装git，我是在ubuntu下，所以输入命令：

$sudo apt-get install git-core

OK!此时应该git成功安装，查看git版本：

$git --version

一：获取项目的git仓库：

1）从当前目录初始化：

$git init

创建了一个空的git仓库：

如果这个git仓库已经初始化过了，则提示exist：

如果成功创建一个空的git仓库可以看到在当前目录下出现一个.git目录，这个就是仓库了！

现在偷窥一下.git目录下都有什么：

2）从现有仓库克隆:

克隆仓库的命令为git clone [url]。比如，要克隆Ruby语言的Git代码仓库Grit，可以用下面的命令：

$git clone git://github.com/schacon/grit.git

这时在当前目录下创建一个名为“grit”的目录，其中内含一个.git目录，并从同步后的仓库中拉出所有的数据，取出最新版本的文件拷贝。如果想自己指定目录的名字：

$git clone git://github.com/schacon/grit.git mygrit

获得Linux2.6内核源码：

如果使用git clone --bared则会只clone .git仓库，而不会clone working directory和staging area。下面是对比，linux-kernel是使用git clone得到的，my-linux是使用git clone --bared得到的

二：新加文件到index中，使得git可以跟踪它：

git有3个区域,分别是:

 

• working directory
• staging area
• repository

 

任何一个git里的文件都有三种状态：

 

• 已修改（修改了某个文件，但是没有提交）
• 已暂存（把修改的文件放在下次提交时要保存的清单中）
• 已提交（该文件已经安全地保存在本地数据库中了）
   
  

基本的Git工作流如下：

1. 在工作目录中修改某些文件
2. 对这些修改了的文件作快照，并保存到暂存区
3. 提交更新，将保存在暂存区域的文件快照转储到git目录中

工作目录下面的所有文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是 指本来就被纳入版本控制管理的文件，在上次快照中有它们的记录，工作一段时间后，它们的状态可能是未更新的，已修改或者已放入暂存区。而所有其他文件都属 于未跟踪文件。它们既没有上次更新时的快照，也不在当前的暂存区里。初次克隆某个仓库时，工作目录中的所有文件都属于已跟踪文件，且状态为未修改。

使用git status检查当前文件状态：

$git status

 

说明没有跟踪任何文件

用vim修改一下工作目录下的main.c文件，再将文件git add到staging area，然后：

$git add .

git add+要跟踪文件名，可以看到这里多了一个index文件，这就是那个staging area。再次运行git status

可以看到main.c文件已经被跟踪，并处于暂存状态。

三：提交

然后再git commit进行提交，把数据提交到git仓库中：

$git commit -m "this is first commit"

注意这里通过-m 选项加一个注释，这样你就可以提交你的数据到git仓库了，也可以把两个步骤合并文一个步骤：

$git commit -a -m "this is first commit"

git有两个配置文件，一个在$HOME下，是全局的，设置时加--global，另一个在仓库配置文件里。

$git config 

设置全局的：

本地的：

文件.gitignore的格式规范如下：

 

• 所有空行或以注释符号#开头的行都会被Git忽略
• 可以使用标准的glob模式匹配
• 匹配模式最后跟反斜杠(/)说明要忽略的是目录
• 要忽略指定模式以外的文件或目录，可以在模式前加惊叹号(!)取反

 

一般时候我们总会有一些文件无需纳入Git的管理，也不希望他们总出现在未跟踪文件列表。通常都是些自主生成的文件，像是日志或者

编译过程中创建的等等。我们可以创建一个.gitignore的文件，列出要忽略的文件模式，来看一个例子：

这里忽略了工作目录下的.test文件，以.o或.a结尾的文件。

如果不使用.gitignore，可以看到，显示.test文件未跟踪，下面添加.gitignore文件

可以看到工作目录很干净的。

如果使用git下载Linux内核源码，你可以在工作目录下看到.gitignore文件，cat .gitignore，截了一段：

二：git diff 生成patch

git-diff列出自己本地的tree中已修改，但却未commit的改动，这也是产生patch的方式。注意，使用git-diff产生的patch都应该在patch(1)时

指定-p1，或者直接使用git-apply打补丁。

选项：

--clour diff 语法高亮

--ignore-space-at-eol 忽略行尾的whitespace

--ignore-space-change 忽略行尾的whitespace，并且认为所有的whitespace都是一样的

--ignore-all-space 比较两行的时候，完全忽略whitespace。这样，即使是一行有很多whitespaces，另一行文字一样但是没有whitespace，

git也认为这两行内容一致。

这里介绍一下patch文件格式：补丁头

补丁头是分别由---/+++开头的两行，用来表示要打补丁的文件。---开头表示旧文件，+++开头表示新文件。

一个补丁文件中的多个补丁

一个补丁文件中可能包含以---/+++开头的很多节，每一节用来打一个补丁。所以在一个补丁文件中可以有好多个补丁。

块

块是补丁中要修改的地方。它通常由一部分不用修改的东西开始和结束。他们只是用来表示要修改的位置。他们通常以@@开始，结束于

另一个块的开始或者一个新的补丁头。

块的缩进

块会缩进一列，而这一列是用来表示这一行是要增加还是要删除的。

块的第一列

+号表示这一行是要加上的

-号表示这一行是要删除的

没有加号也没有减号表示这里只是引用的而不需要修改

三：git apply打补丁

git-apply相当于patch(1)命令，不过git-apply专门用来apply那些用git-diff生成的补丁

选项：

--check 不真正打补丁，而只是检查补丁是否能完美的打上

-v verbose模式

-R reverse模式，也就是拉出这个补丁来

四：git log 查看提交历史记录

运行git log：

git会按提交时间列出所有的更新，最近的更新排在最上边。每次更新都会有一个SHA-1校验，作者的名字和电子邮件地址，提交时间，最

后一个段落显示提交说明。

选项说明：

-p 按补丁格式显示每个更新之间的差异

--stat 显示每次更新的文件修改统计信息

--shortstat 只显示--stat中最后的行数修改添加移除统计

--pretty 使用其他格式显示历史提交信息。可用的选项包括online，short，full，fuller和format。

下边是加-p选项，按补丁格式查看每个更新之间的差异

$git log -p