在Loadrunner里面生成Vu的方式有2种，在“Runtime settings”里面有设置，具体看下图，如果选择Run Vuser as a

thread表示Vu按照一个线程生成，如果选择 Run Vuser as a process，则Vu按照进程（非多线程）方式生成

 

下面我对上述的话做一个简单的翻译：

Loadrunner支持多线程环境，使用多线程的方法能使每台负载生成器运行更多的VU，但是只有支持线程安全的协议，才能使用Loadrunner的VU并发方式

下表列出哪些协议不能支持线程并发

Sybase-Dblib,Infomix,Tuxedo,and PeopleSoft-Tuxedo

当使用进程并发是，在任务管理器中有mdrv.exe的进程，比如下图，我以10个VU用户并发，就会在任务管理器中出现10个mmdrv进程

 

如果以多线程方式并发，只会出现一个mmdrv进程，一个进程可以支持50VU的线程并发，

Loadrunner的参考帮助还说明了，如果采用多线程方式并发，Load Generator将会比多进程支持更多的用户，具体的一个VU占用内存的取值根据Loadrunner的版本不同而不同。

       

 Loadrunner8.1

Loadrunner9.0
  由于本人对操作系统底层的原理并不是特别懂，我知道如果一个VU从外部访问的话都会以一个进程的方式请求和分配系统的资源，当VU并模拟成了线程的方式，我不知道仿真度上面是否有区别，还请知道的人多多提出自己的意见。

文章最后附上进程和线程的区别，摘自baidu
进程和线程的区别：
解释一：
 

线程是一种操作系统对象，代表着一个进程中要被执行的代码的路径。每一个WIN32应用程序至少有一个线程--通常称为住线程或默认线程--但应用程序可以自由地创建其他线程来执行其他任务！

进程是程序的一次动态执行过程，它对应了从代码加载、执行到执行完毕的一个完整过程，这个过程也是进程本身从产生、发展到消亡的过程线程是比进程更小的执行单位。一个进程在其执行过程能够中，可以产生 多个线程，形成多条执行线索。每条线索，即每个线程也有它自身的产生、存在和消亡过程，也是一个动态的概念。一个程序应该只有一个进程吧，但是可以拥有多个线程。

可以说，一个执文件被运行后，就可以称为是一个进程了。但是进程只是存在内存中，实际上他是不会做任何事情的。这个时候，起作用的就是线程了。线程是程序的执行者，一个程序至少有一个线程，但是在多线程的操作系统中，可以有一个以上的线程。

 其实我们可以把线程看成是我们排队买肯德鸡吃（循环的排队，一直排下去，知道我不想买了，退出）。每人都有机会到达队伍的最前端去买东西，这个就好比是线程，都有机会被程序执行。但是线程真正起作用的时候，就是我们在队伍的最前端买东西到东西买完后，这一段时间，这是线程真正执行的阶段。

解释二：
进程和线程都是由操作系统所体现的程序运行的基本单元，系统利用该基本单元实现系统对应用的并发性。
进程和线程的区别在于：

简而言之,一个程序至少有一个进程,一个进程至少有一个线程.线程的划分尺度小于进程，使得多线程程序的并发性高。另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出 口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位. 线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源. 一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.

关于进程安全
 

如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。或者说:一个类或者程序所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性,也就是说我们不用考虑同步的问题。线程安全问题都是由全局变量及静态变量引起的。若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则就可能影响线程安全。

举例：

　比如一个 ArrayList 类，在添加一个元素的时候，它可能会有两步来完成：1. 在 Items[Size] 的位置存放此元素；2. 增大 Size 的值。

　　在单线程运行的情况下，如果 Size = 0，添加一个元素后，此元素在位置 0，而且 Size=1；

　　而如果是在多线程情况下，比如有两个线程，线程 A 先将元素存放在位置 0。但是此时 CPU 调度线程A暂停，线程 B 得到运行的机会。线程B也向此 ArrayList 添加元素，因为此时 Size 仍然等于 0 （注意哦，我们假设的是添加一个元素是要两个步骤哦，而线程A仅仅完成了步骤1），所以线程B也将元素存放在位置0。然后线程A和线程B都继续运行，都增加 Size 的值。

　　那好，现在我们来看看 ArrayList 的情况，元素实际上只有一个，存放在位置 0，而 Size 却等于 2。这就是“线程不安全”了。

test8848-谷峰

这几天看LR的中文版帮助，有一个地方总搞不明白。就是参数化file选项中sequentail+once选项的参数方式，中文版帮助如图

英文版帮助如下

业务说明：
以测试工程师的角色添加缺陷，并设置为3次迭代，设置并发为2个用户


实际结果证明英文版还是对的，呵呵，广大测试朋友注意了

 提取版本库中的数据

这是个很有用的小技巧，如果你对你现在的工作目录下的东西已经不耐烦了，随时可以取出你提交过的东西覆盖掉当前的文件，譬如：

$ git-checkout -f foo.c

在 git 中，有两种类型的标签，“轻标签”和“署名标签”。

技术上说，一个“轻标签”和一个分支没有任何区别，只不过我们将它放在了 .git/refs/tags/ 目录，而不是 heads 目录。因此，打一个“轻标签”再简单不过了。

$ git-tag my-first-tag

如果你打算针对某个commit ID来打标签，虽然该命令可以通过gitk里的右键菜单来实现，但是该命令对实际应用是很有帮助的。

$ git-tag mytag f0af6283824688f9d23426031734657661b54388

“署名标签”是一个真正的 git 对象，它不但包含指向你想标记的状态的指针，还有一个标记名和信息，可选的 PGP 签名。你可以通过 -a 或者是 -s 选项来创建“署名标签”。

$ git-tag -s <tag-name>

通常的情况下，合并其他的人的工作的情况会比合并自己的分支的情况要多，这在 git 中是非常容易的事情，和你运行 git-merge 命令没有什么区别。事实上，远程合并的无非就是“抓取（fetch）一个远程的版本库中的工作到一个临时的标签中”，然后再使用 git-merge 命令。

可以通过下面的命令来抓取远程版本库:

$ git-fetch <remote-repository>

根据不同的远程版本库所使用的通讯协议的路径来替代上面的 remoted-repository 就可以了。

Rsync

rsync://remote.machine/patch/to/repo.git/

SSH

remote.machine:/path/to/repo.git
or
ssh://remote.machine/patch/to/repo.git/

这是可以上传和下载的双向传输协议，当然，你要有通过 ssh 协议登录远程机器的权限。它可以找出两端的机器提交过的对象集之中相互缺少了那些对象，从而得到需要传输的最小对象集。这是最高效地交换两个版本库之间的对象的方式（在 git 兼容的所有传输协议当中）。

下面是个取得 SSH 远程版本库的命令例子：

$ git-fetch robin@192.168.1.168:/path/to/gittutorcn.git (1)

 

(1) 这里 robin 是登录的用户名，192.168.1.168 是保存着主版本库的机器的 IP 地址。

Local directory

/path/to/repo.git/

本地目录的情况和 SSH 情况是一样的。

git Native

git://remote.machine/path/to/repo.git/

git 自然协议是设计来用于匿名下载的，它的工作方式类似于 SSH 协议的交换方式。

HTTP(S)

http://remote.machine/path/to/repo.git/

到这里可能有些朋友已经想到，实际上，我们可以通过 Rsync, SSH 之类的双向传输方式来建立类似 CVS，SVN 这样的中心版本库模式的开发组织形式。

读过上一节之后，有的朋友可能要问，如果版本库是通过单向的下载协议发布的，如 HTTP，我们就无法将工作上传到公共的版本库中。别人也不能访问我的机器来抓取我的工作，那怎么办呢？

不必担心，我们还有 email ！别忘了 git 本来就是为了管理 Linux 的内核开发而设计的。所以，它非常适合像 Linux Kernel 这样的开发组织形式高度分散，严重依赖 email 来进行交流的项目。

下面模拟你参加到《Git 中文教程》的编写工作中来，看看我们可以怎么通过 email 进行工作交流。你可以通过下面的命令下载这个项目的版本库。

$ git-clone http://www.bitsun.com/git/gittutorcn.git

之后，你会在当前目录下得到一个叫 gittutorcn 的目录，这就是你的项目的工作目录了。默认地，它会有两个分支： master 和 origin，你可以直接在 master 下展开工作，也可以创建你自己的工作分支，但是千万不要修改 origin 分支，切记！因为它是公共版本库的镜像，如果你修改了它，那么就不能生成正确的对公共版本库的 patch 文件了。

Note	如果你的确修改过 origin 分支的内容，那么在生成 patch 文件之前，请用 git-reset --hard 命令将它逆转到最原始的，没经过任何修改的状态。

你可以直接在 master 下开展工作，也可以创建你自己的工作分支。当你对项目做了一定的工作，并提交到库中。我们用 git-show-branch 命令先看下库的状态。

* [master] your buddy's contribution

 ! [origin] degining of git-format-patch example

--

* [master] your buddy's contribution

*+ [origin] degining of git-format-patch example

上面就假设你已经提交了一个叫 "your buddy's contribution" 的工作。现在我们来看看怎么通过 email 来交流工作了。

$ git-fetch origin    (1)

$ git-rebase origin    (2)

$ git-format-patch origin     (3)

 

(1)更新 origin 分支，防止 origin 分支不是最新的公共版本，产生错误的补丁文件；

(2)将你在 master 上提交的工作迁移到新的源版本库的状态的基础上；

(3)生成补丁文件；

上面的几个命令，会在当前目录下生成一个大概名为 0001-your-buddy-s-contribution.txt 补丁文件, 建议你用文本工具查看一下这个文件的具体形式，然后将这个文件以附件的形式发送到项目维护者的邮箱： vortune@gmail.com

当项目的维护者收到你的邮件后，只需要用 git-am 命令，就可以将你的工作合并到项目中来。

$ git-checkout -b buddy-incomming

$ git-am /path/to/0001-your-buddy-s-contribution.txt

假设 Alice 在一部机器上自己的个人目录中创建了一个项目 /home/alice/project, Bob 想在同一部机器自己的个人目录中为这个项目做点什么。

Bob 首先这样开始：

$ git-clone /home/alice/project myrepo

这样就创建了一个保存着 Alice 的版本库的镜像的新目录 "myrepo"。这个镜像保存着原始项目的起点和它的发展历程。

接着 Bob 对项目做了些更改并提交了这些更改：

(编辑一些文件)

 

$ git-commit -a

 

(如果需要的话再重复这个步骤)

当他搞定之后，他告诉 Alice 将他的东西从 /home/bob/myrepo 中引入，她只需要这样：

$ cd /home/alice/project

$ git pull /home/bob/myrepo

这样就将 Bob 的版本库中的 "master" 分支的变化引入了。 Alice 也可以通过在 pull 命令的后面加入参数的方式来引入其他的分支。

在导入了 Bob 的工作之后，用 "git-whatchanged" 命令可以查看有什么信的提交对象。如果这段时间里以来，Alice 也对项目做过自己的修改，当 Bob 的修改被合并进来的时候，那么她需要手动修复所有的合并冲突。

谨慎的 Alice 在导入 Bob 的工作之前，希望先检查一下。那么她可以先将 Bob 的工作导入到一个新创建的临时分支中，以方便研究 Bob 的工作：

$ git fetch /home/bob/myrepo master:bob-incoming

这个命令将 Bob 的 master 分支的导入到名为 bob-incoming 的分支中（不同于 git-pull 命令，git-fetch 命令只是取得 Bob 的开发工作的拷贝，而不是合并经来）。接着：

$ git whatchanged -p master..bob-incoming

这会列出 Bob 自取得 Alice 的 master 分支之后开始工作的所有变化。检查过这些工作，并做过必须的调整之后， Alice 就可以将变化导入到她的 master 分支中：

$ git-checkout master

$git-pull . bob-incoming

最后的命令就是将 "bob-incoming" 分支的东西导入到 Alice 自己的版本库中的，稍后，Bob 就可以通过下面的命令同步 Alice 的最新变化。

$ git-pull

注意不需为这个命令加入 Alice 的版本库的路径，因为当 Bob 克隆 Alice 的版本库的时候， git 已经将这个路径保存到 .git/remote/origin 文件中，它将会是所以的导入操作的默认路径。

Bob 可能已经注意到他并没有在他的版本库中创建过分支（但是分支已经存在了）：

$ git branch

* master

 origin

"origin" 分支，它是运行 "git-clone" 的时候自动创建的，他是 Alice 的 master 分支的原始镜像， Bob 应该永远不要向这个分支提交任何东西。

如果 Bob 以后决定在另外一部主机上开展工作，那么他仍然需要通过 SSH 协议从新克隆和导入（ Alice 的版本库）：

$ git-clone alice.org:/home/alice/project/ myrepo

我们可以使用 git 自然协议，或者是 rsync, http 等协议的任何一种，详情请参考 git-pull。

Git 同样可以建立类似 CVS 那样的开发模式，也就是所有开发者都向中心版本库提交工作的方式，详情参考 git_push 和 git for CVS users 。

 

1d2fa05b13b63e39f621d8ee911817df0662d9b7 Some fun

d2659fcf690ec693c04c82b03202fc5530d50960 some work

found 1 common ancestor(s):

3ecebc0cb4894a33208dfa7c7c6fc8b5f9da0eda a new day for git

Auto-merging hello

CONFLICT (content): Merge conflict in hello

 

Automatic merge failed; fix up by hand

git 的提示指出，在合并作用于文件 hello 的 'Some fun' 和 'some work' 这两个对象时有冲突，具体通俗点说，就是在 master, robin 这两个分支中的 hello 文件的某些相同的行中的内容不一样。我们需要手动解决这些冲突，现在先让我们看看现在的 hello 文件中的内容。

$ cat hello

此时的 hello 文件应是这样的，用过其他的版本控制系统的朋友应该很容易看出这个典型的冲突表示格式：

Hello World

It's a new day for git

<<<<<<< HEAD/hello

Play, play, play

=======

Work, work, work

>>>>>>> d2659fcf690ec693c04c82b03202fc5530d50960/hello

我们用编辑器将 hello 文件改为：

Hello World

It's a new day for git

Play, play, play

Work, work, work

现在可以将手动解决了冲突的文件提交了。

$ git-commit -i hello

以上是典型的两路合并（2-way merge）算法，绝大多数情况下已经够用。但是还有更复杂的三路合并和多内容树合并的情况。详情可参看： git-read-tree， git-merge 等文档。

项目跟踪工具的一个重要任务之一，就是使我们能够随时逆转（Undo）和恢复（Redo）某一阶段的工作。

git-reset 命令就是为这样的任务准备的。它将当前的工作分支的 头 定位到以前提交的任何版本中，它有三个重置的算法选项。

命令形式：

git-reset [--mixed | --soft | --hard] [<commit-ish>]

命令的选项：

--mixed

仅是重置索引的位置，而不改变你的工作树中的任何东西（即，文件中的所有变化都会被保留，也不标记他们为待提交状态），并且提示什么内容还没有被更新了。这个是默认的选项。

--soft

既不触动索引的位置，也不改变工作树中的任何内容，我们只是要求这些内容成为一份好的内容（之后才成为真正的提交内容）。这个选项使你可以将已经提交的东西重新逆转至“已更新但未提交（Updated but not Check in）”的状态。就像已经执行过 git-update-index 命令，但是还没有执行 git-commit 命令一样。

--hard

将工作树中的内容和头索引都切换至指定的版本位置中，也就是说自 <commit-ish> 之后的所有的跟踪内容和工作树中的内容都会全部丢失。因此，这个选项要慎用，除非你已经非常确定你的确不想再看到那些东西了。

一个重要技巧－－逆转提交与恢复

可能有人会问，--soft 选项既不重置头索引的位置，也不改变工作树中的内容，那么它有什么用呢？现在我们介绍一个 --soft 选项的使用技巧。下面我们用例子来说明：

$ git-checkout master

$ git-checkout -b softreset

$ git-show-branch

这里我们创建了一个 master 的拷贝分支 softreset，现在我们可以看到两个分支是在同一起跑线上的。

! [master] Merge branch 'robin'

 ! [robin] some work

 * [softreset] Merge branch 'robin'

---

- - [master] Merge branch 'robin'

+ * [master^] Some fun

++* [robin] some work

我们为 文件增加一些内容并提交。

$ echo "Botch, botch, botch" >> hello

$ git-commit -a -m "some botch"

$ git-show-branch

我们可以看到此时 softreset 比 master 推进了一个版本 "some botch" 。

! [master] Merge branch 'robin'

 ! [robin] some work

 * [softreset] some botch

---

 * [softreset] some botch

- - [master] Merge branch 'robin'

+ * [master^] Some fun

++* [robin] some work

现在让我们来考虑这样的一种情况，假如我们现在对刚刚提交的内容不满意，那么我们再编辑项目的内容，再提交的话，那么 "some botch" 的内容就会留在版本库中了。我们当然不希望将有明显问题的内容留在版本库中，这个时候 --soft 选项就很有用了。为了深入了解 --soft 的机制，我们看看现在 softreset 分支的头和 ORIG_HEAD 保存的索引。

$ cat .git/refs/heads/softreset .git/ORIG_HEAD

结果如下：

5e7cf906233e052bdca8c598cad2cb5478f9540a

7bbd1370e2c667d955b6f6652bf8274efdc1fbd3

现在用 --soft 选项逆转刚才提交的内容：

git-reset --soft HEAD^

现在让我们再看看 .git/ORIG_HEAD 的中保存了什么？

$ cat .git/ORIG_HEAD

结果如下：

5e7cf906233e052bdca8c598cad2cb5478f9540a

看！现在的 .git/ORIG_HEAD 等于逆转前的 .git/refs/heads/softreset 。也就是说，git-reset --soft HEAD^ 命令逆转了刚才提交的版本进度，但是它将那次提交的对象的索引拷贝到了 .git/ORIG_HEAD 中。

我们再编辑 hello 文件成为下面的内容：

Hello World

It's a new day for git

Play, play, play

Work, work, work

Nice, nice, nice

我们甚至可以比较一下现在的工作树中的内容和被取消了的那次提交的内容有什么差异：

$ git-diff ORIG_HEAD

结果如下：

diff --git a/hello b/hello

index f978676..dd02c32 100644

--- a/hello

+++ b/hello

@@ -2,4 +2,4 @@ Hello World

 It's a new day for git

 Play, play, play

 Work, work, work

-Botch, botch, botch

+Nice, nice, nice

接着，我们可以恢复刚才被取消了的那次提交了。

$ git-commit -a -c ORIG_HEAD

注意，这个命令会打开默认的文本编辑器以编辑原来提交的版本日志信息，我们改为 "nice work" 。大家可以自行用 git-show-branch 命令来查看一下现在的分支状态。并且我们还可以不断地重复上述的步骤，一直修改到你对这个版本进度满意为止。

git-reset 命令还有很多的用途和技巧，请参考 git-reset ，以及 Everyday GIT with 20 commands or So 。

此时，我们可以再次使用组合命令 git-update-index 和 git-commit 将我们的工作提交到版本库中。

$ git-update-index hello

$ git-commit -m "new day for git"

实际上，如果要提交的文件都是已经纳入 git 版本库的文件，那么不必为这些文件都应用 git-update-index 命令之后再进行提交，下面的命令更简捷并且和上面的命令是等价的。

$ git-commit -a -m "new day for git"

直至现在为止，我们的项目版本库一直都是只有一个分支 master。在 git 版本库中创建分支的成本几乎为零，所以，不必吝啬多创建几个分支。下面列举一些常见的分支策略，仅供大家参考：

·         创建一个属于自己的个人工作分支，以避免对主分支 master 造成太多的干扰，也方便与他人交流协作。

·         当进行高风险的工作时，创建一个试验性的分支，扔掉一个烂摊子总比收拾一个烂摊子好得多。

·         合并别人的工作的时候，最好是创建一个临时的分支，关于如何用临时分支合并别人的工作的技巧，将会在后面讲述。

创建分支

下面的命令将创建我自己的工作分支，名叫 robin，并且将以后的工作转移到这个分支上开展。

$ git-branch robin

$ git-checkout robin

删除分支

要删除版本库中的某个分支，使用 git-branch -D 命令就可以了，例如：

$ git-branch -D branch-name

查看分支

运行下面的命令可以得到你当前工作目录的分支列表：

$ git-branch

如果你忘记了你现在工作在哪个分支上，运行下面的命令可以告诉你：

$ cat .git/HEAD

这一节介绍几个查看项目的版本库的发展变化以及比较差异的很有用的命令：

git-show-branch

git-diff

git-whatchanged

 

我们现在为 robin, master 两个分支都增加一些内容。

$ git-checkout robin

$ echo "Work, work, workd" >> hello

$ git-commit -m "Some workd" -i hello

$ git-checkout master

$ echo "Play, play, play" >> hello

$ echo "Lots of fun" >> example

$ git-commit -m "Some fun" -i hello example

git-show-branch 命令可以使我们看到版本库中每个分支的世系发展状态，并且可以看到每次提交的内容是否已进入每个分支。

$ git-show-branch

这个命令让我们看到版本库的发展记录。

* [master] Some fun

 ! [robin] some work

--

* [master] Some fun

 + [robin] some work

*+ [master^] a new day for git

譬如我们要查看世系标号为 master^ 和 robin 的版本的差异情况，我们可以使用这样的命令：

$ git-diff master^ robin

我们可以看到这两个版本的差异：

diff --git a/hello b/hello

index 263414f..cc44c73 100644

--- a/hello

+++ b/hello

@@ -1,2 +1,3 @@

 Hello World

 It's a new day for git

+Work, work, work

Note	关于 GIT 版本世系编号的定义，请参看 git-rev-parse 。

我们现在再用 git-whatchanged 命令来看看 master 分支是怎么发展的。

$ git-checkout master

$ git-whatchanged

diff-tree 1d2fa05... (from 3ecebc0...)

Author: Vortune.Robin

Date:   Tue Mar 21 02:24:31 2006 +0800

 

    Some fun

 

:100644 100644 f24c74a... 7f8b141... M example

:100644 100644 263414f... 06fa6a2... M hello

 

diff-tree 3ecebc0... (from 895f09a...)

Author: Vortune.Robin

Date:   Tue Mar 21 02:17:23 2006 +0800

 

    a new day for git

 

:100644 100644 557db03... 263414f... M hello

从上面的内容中我们可以看到，在 robin 分支中的日志为 "Some work" 的内容, 并没有在 master 分支中出现。

既然我们为项目创建了不同的分支，那么我们就要经常地将自己或者是别人在一个分支上的工作合并到其他的分支上去。现在我们看看怎么将 robin 分支上的工作合并到 master 分支中。现在转移我们当前的工作分支到 master，并且将 robin 分支上的工作合并进来。

$ git-checkout master

$ git-merge "Merge work in robin" HEAD robin

合并两个分支，还有一个更简便的方式，下面的命令和上面的命令是等价的。

$ git-checkout master

$ git-pull . robin

但是，此时 git 会出现合并冲突提示：

Trying really trivial in-index merge...

fatal: Merge requires file-level merging

Nope.

Merging HEAD with d2659fcf690ec693c04c82b03202fc5530d50960

Merging:

 Git --- The stupid content tracker, 傻瓜内容跟踪器。Linus 是这样给我们介绍 Git 的。

Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。

实际上内核开发团队决定开始开发和使用 Git 来作为内核开发的版本控制系统的时候，世界开源社群的反对声音不少，最大的理由是 Git 太艰涩难懂，从 Git 的内部工作机制来说，的确是这样。但是随着开发的深入，Git 的正常使用都由一些友好的脚本命令来执行，使 Git 变得非常好用，即使是用来管理我们自己的开发项目，Git 都是一个友好，有力的工具。现在，越来越多的著名项目采用 Git 来管理项目开发，例如：wine, U-boot 等，详情看 http://www.kernel.org/git

作为开源自由原教旨主义项目，Git 没有对版本库的浏览和修改做任何的权限限制。它只适用于 Linux / Unix 平台，没有 Windows 版本，目前也没有这样的开发计划。

本文将以 Git 官方文档 Tutorial， core-tutorial 和 Everyday GIT 作为蓝本翻译整理，但是暂时去掉了对 Git 内部工作机制的阐述，力求简明扼要，并加入了作者使用 Git 的过程中的一些心得体会，注意事项，以及更多的例子。建议你最好通过你所使用的 Unix / Linux 发行版的安装包来安装 Git, 你可以在线浏览本文 ，也可以通过下面的命令来得到本文最新的版本库，并且通过后面的学习用 Git 作为工具参加到本文的创作中来。

$ git-clone http://www.bitsun.com/git/gittutorcn.git

创建一个 Git 版本库是很容易的，只要用命令 git-init-db 就可以了。现在我们来为本文的写作创建一个版本库：

$ mkdir gittutorcn

$ cd gittutorcn

$ git-init-db

git 将会作出以下的回应

defaulting to local storage area

这样，一个空的版本库就创建好了，并在当前目录中创建一个叫 .git 的子目录。你可以用 ls -a 查看一下，并请注意其中的三项内容：

·         一个叫 HEAD 的文件，我们现在来查看一下它的内容：

$ cat .git/HEAD

现在 HEAD 的内容应该是这样：

ref: refs/heads/master

我们可以看到，HEAD 文件中的内容其实只是包含了一个索引信息，并且，这个索引将总是指向你的项目中的当前开发分支。

·         一个叫 objects 的子目录，它包含了你的项目中的所有对象，我们不必直接地了解到这些对象内容，我们应该关心是存放在这些对象中的项目的数据。

Note	关于 git 对象的分类，以及 git 对象数据库的说明，请参看 [Discussion]

·         一个叫 refs 的子目录，它用来保存指向对象的索引。

具体地说，子目录 refs 包含着两个子目录叫 heads 和 tags，就像他们的名字所表达的意味一样：他们存放了不同的开发分支的头的索引, 或者是你用来标定版本的标签的索引。

请注意：master 是默认的分支，这也是为什么 .git/HEAD 创建的时候就指向 master 的原因，尽管目前它其实并不存在。 git 将假设你会在 master 上开始并展开你以后的工作，除非你自己创建你自己的分支。

另外，这只是一个约定俗成的习惯而已，实际上你可以将你的工作分支叫任何名字，而不必在版本库中一定要有一个叫 master 的分支，尽管很多 git 工具都认为 master 分支是存在的。

现在已经创建好了一个 git 版本库，但是它是空的，还不能做任何事情，下一步就是怎么向版本库植入数据了。

为了简明起见，我们创建两个文件作为练习：

$ echo "Hello world" > hello

$ echo "Silly example" > example

我们再用 git-add 命令将这两个文件加入到版本库文件索引当中：

$ git-add hello example

git-add 实际上是个脚本命令，它是对 git 内核命令 git-update-index 的调用。因此上面的命令和下面的命令其实是等价的：

$ git-update-index --add hello example

如果你要将某个文件从 git 的目录跟踪系统中清除出去，同样可以用 git-update-index 命令。例如：

$ git-update-index --force-remove foo.c

Note	git-add 可以将某个目录下的所有内容全都纳入内容跟踪之下，例如： git-add ./path/to/your/wanted 。但是在这样做之前，应该注意先将一些我们不希望跟踪的文件清理掉，例如，gcc 编译出来的 *.o 文件，vim 的交换文件 .*.swp 之类。

应该建立一个清晰的概念就是，git-add 和 git-update-index 只是刷新了 git 的跟踪信息，hello 和 example 这两个文件中的内容并没有提交到 git 的内容跟踪范畴之内。

既然我们刷新了 Git 的跟踪信息，现在我们看看版本库的状态：

$ git-status

我们能看到 git 的状态提示：

#

# Initial commit

#

#

# Updated but not checked in:

#   (will commit)

#

#       new file: example

#       new file: hello

#

提示信息告诉我们版本库中加入了两个新的文件，并且 git 提示我们提交这些文件，我们可以通过 git-commit 命令来提交：

$ git-commit -m "Initial commit of gittutor reposistory"

git-diff 命令将比较当前的工作目录和版本库数据库中的差异。现在我们编辑一些文件来体验一下 git 的跟踪功能。

$ echo "It's a new day for git" >> hello

我们再来比较一下，当前的工作目录和版本库中的数据的差别。

$ git-diff

差异将以典型的 patch 方式表示出来：

diff --git a/hello b/hello

index a5c1966..bd9212c 100644

--- a/hello

+++ b/hello

@@ -1 +1,2 @@

 Hello, world

+It's a new day for git

LR的Port端口映射的视频演示

http://www.tudou.com/programs/view/MSDYcTpzrfU/

阶段三 容错性测试

你的新内核已经通过了测试的前两个阶段了吗？现在，可以开始实验了。那就是，做一些任何一个正常人在普通工作中都不会做的蠢事，因为没人会知道那些蠢事会导致内核崩溃。那到底需要做些什么事呢？好的，如果存在一个“标准的”程序的话，那它当然早就被包含在一些测试套件中了。

例如，第三阶段可以从拔掉和重插USB设备开始。从理论上讲，重插一个USB设置不应该会产生任何事情，至少从用户的角度看来。如果USB子系统存在bug,连续进行很多次这样的测试就可能会导致内核崩溃(这个测试如果出现问题，说明了之前未曾有人在类似系统配置下尝试这个测试)。
接下来，你可以编写一个脚本，连续读取/proc目录中文件的内容，等等。一句话，在这阶段，你应该做些普通用户永远不会做的事(或者极常少做：为什么有人会不断重复地挂载和卸载某个文件系统呢？)

阶段二（自动测试）

测试的下一阶段是，使用专门设计的程序来检查特定的内核子系统能否正常工作。我们还执行内核的退化以及性能测试。后者对于内核开发员（还有我们）来说，相当地重要，因为它使得我们能识别出损害性能的改变。比如，如果我们把内核从2.6.x-rc1升级到2.6.x-rc2后，有种文件系统的性能却降低了10%，查找导致这种情况发生的补丁无疑是个好主意。

关于内核的自动测试，我们推荐你使用AutoTest 套件(http://test.kernel.org/autotest/)。该套件包含了很多测试应用程序以及统计工具，而且相当简单的用户界面。

为了安装AutoTest你以root帐户可以进入到/usr/local 目录并运行

# svn checkout svn://test.kernel.org/autotest/trunk autotest

虽然通常不推荐以root帐户运行类似命令，但这个命令应该是安全的，除非你不信任你的DNS服务器，因为它只是下载一些文件，并保存到/usr/local下。除此之外，你还得以root帐户运行AutoTest，因为它的一些测试要求超级用户权限才能完成。所以，你不应该在生产系统上使用AutoTest:在极端情况下，保存在进行特权级测试的系统中的数据可能会受到损坏甚至毁坏，我们相信你不喜欢你的产品数据会发生这种情况。
根据设计，AutoTest是非交互式性的，所以一旦启动，你就不需要再关心它了(当然了，如果有坏事真的发生了，你就要不得不恢复系统了，但这是另外一个话题)。要启动测试，你可以到/usr/local/autotest/client目录下 (我们假设AutoTest被安装到了/usr/local下),然后以root身份执行：

# bin/autotest tests/test_name/control

这里，test_name是位于目录/usr/local/autotest/client/tests中的目录名称，该目录中含有你想要进行的测试。控制文件tests/test_name/control包含了为AutoTest准备的指令。最简单的情况下，只需要一个这样的指令，也就是：

job.run_test(’test_name’)

这里，test_name是包含控制文件的目录名称。更加复杂的控制文件的内容可能类似下面：

job.run_test(’pktgen’, ’eth0’, 50000, 0, tag=’clone_skb_off’)
job.run_test(’pktgen’, ’eth0’, 50000, 1, tag=’clone_skb_on’)

这里，测试名称后面的字符串表示的是应当要传递到测试程序的参数。你可以修改这些参数，但是首先要阅读测试程序的文档以及脚本tests/test_name/test_name.py(比如tests/pktgen/pktgen.py)。实际上AutoTest就是使用该脚本来启动测试的(可能你已经注意到，
AutoTest脚本是用Python语言写的)。脚本sts/test_name/test_name.py的执行结果保存在目录results/default/test_name/中，该目录中的status文件包含着标识测试是否已经成功完成的信息。想取消正在进行的测试，按Ctrl+C即可。
如果你想连续运行一串测试，最好的做法是准备单独一个文件，该文件中包含着多个AutoTest的指令。这个文件中的指令和上面提到的控制文件中的指令类似。比如，文件samples/all_tests包含有运行所有可以测试指令，其中前五行如下

job.run_test(’aiostress’)
job.run_test(’bonnie’)
job.run_test(’dbench’)
job.run_test(’fio’)
job.run_test(’fsx’)

要运行这个文件中的指令所请求的全部测试，你可以做使用命令bin/autotest samples/all_tests。但是要记得这要花很长的时间才能完成。类似地，要运行定制的一串测试，得把为AutoTest准备的指令们放到一个文件里面，然后给这个文件起个名称，这个名称将作为命令行的一个参数传递给autotest.要并行地运行几个测试，你得准备一个特殊的控制文件，这个控制文件包含的指令如下:

def kernbench():
job.run_test(’kernbench’, 2, 5)
def dbench():
job.run_test(’dbench’)
job.parallel([kernbench], [dbench])

在测试执行的过程序中，在任何时间里，你都可以通过按Ctrl+C来停止它们。
为了造福那些不喜欢命令行和配置文件的朋友，ATCC (AutoTest Control Center )已经被发明出来了。如果你运行它，比如通过命令ui/menu,将会得到一个用菜单驱动的简单界面，你可以通过界面选择测试和profiling工具，浏览测试结果，还可以通过它来限制范围，配置它们。
如果你厌烦了AutoTest套件中包含的一系列工具，可以访问站点http://ltp.sourceforge.net/tooltable.php 。该站点有可以用于linux内核测试的全面的工具清单。

通常，有多种测试linux内核的方法，但我们只关注下面这4种：

1. 在平时的工作中使用内核的测试版本.

2. 在新内核上运行专用的测试套件，比如LTP.

3. 新内核安装后，做些非常规的事情.

4. 新内核安装后，测试系统的性能.

当然，测试过程它们可以混合运用，所以可以认为它们是测试过程的不同阶段。


阶段一:内核的冒烟测试

内核测试的第一阶段很简单：我们尝试着启动内核，然后把它用在平时的工作中。

• 在以全功能配置启动系统之前，推荐先用init=/bin/bash命令行参数来启动内核。它使得内核只启动一个bash进程。这样，你可以检查在最小配置下是否能正常挂载和卸载文件系统，然后，你可以测试一些更加复杂的内核功能，比如挂起到disk或RAM的缓冲。这种情况下，唯一被挂载了的模块是位于initrd映象中的那些模块。提到 了initrd映象。通常，你可以参考你的boot loader文档来获取更多关于手工向内核传递命令行的信息(我们的观点是，如果使用的是GRUB，会更容易操作些。)

• 接着，建议以runlevel 2来启动系统(通常，是通过把数字2作为命令行参数传递给内核)，这时，网络服务器和X服务器还没启动(你的系统有可能为这个用途使用的是另一个runlevel，尽管不大可能，所以你应该查看/etc/inittab文件确认一下)。在这个配置下，你可以检查网络接口是否能工作，你还可以尝试手工启动X服务器来确认它不会崩溃掉。

• 最后，根据需要，你可以把系统启动到runlevel 5(也就是全功能)或者3（也就是除了X，全功能开启）
现在，你已经可以按平时的样子使用系统一段时间了。但是，如果想快点测试内核，你可以执行一些典型的操作，比如下载一些文件，读取邮件，浏览一些站点，抓取一些音轨(我们假设，使用的是合法买来的音频CD)，刻录一张CD或DVD等等操作来连续地检查是否有任何一项会出错。出错的话，就意味着内核有问题存在了