git的基本概念

git的四种对象

• blob对象。即文件。注意只包含内容，没有名字，权限等属性（但包含大小）
• tree对象。相当于文件夹。所包含的文件（blob对象）/文件夹（tree对象）的名字及其基本属性（比如权限、是否符号链接等）的列表。
• commit对象。表示修改历史。commit对象可以视为类似矢量的概念，由父commit（可能不只一个，合并情形下）指向新的tree对象。子commit的直接父commit，使用“子commit^n“来引用。
• tag对象。可以指向blob、tree、commit并包含签名，最常见的是指向commit的PGP签名的标签。

blob，tree，commit 都是用其存储内容的 SHA-1 值命名的（不是简单的对整个文件取 SHA-1 值），tag 自然使用的是普通名字。

git快速上手三步曲

创建一个目录，建立一个版本库（进入目录，运行 git-init-db ）

一个版本库是就是一组代码或文本的集合。一般来说，在文件系统的层面上，通常是将其放入同一个目录下。与之相适应，我们让一个版本库与一个文件目录相对应，将一组相关（一个工程的）代码建立版本库，并储存于一个目录中。

mkdir gittutorcn
cd gittutorcn
git-init-db

放入要加入版本库中的文件，并植入跟踪系统（git-add）

执行了git-init-db后，只是做了一些版本库的初始化工作，还没有任何实质性的内容加进里面去。下面我们就要将一些代码文件拷到刚才建立的那个目录中去（更通常的方式是先拷入这些文件，再运行上面的 git-init-db），然后运行git-add *（*也可以替换成具体的文件名或目录名）， 就将那些文件加入到git的版本跟踪库里面去了。不过此时还只是告诉git“我们有哪些（新）文件要加入”（会自动进行修改时间比较，然后自动判断哪些文件该加入），并没有提交这些文件的具体内容到版本库中去。

git-add *

提交内容到版本库中去（git-commit）

现在我们要把内容提交到版本库中去。用

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

可以将工程目录下的文件全部提交（当然最好当前的位置处于工程根目录下）。

一些常用的命令

查看当前版本库的状态（git-status）

 

分支管理命令（git-branch）

前面的所有操作都没有涉及到版本管理的一个重要方面──多人协作开发所带来的分支管理。git上有一个默认的分支名master，之前所有的操作都是在master分支上进行，即你是以这个版本库的管理员的身份来操作的。引入分支管理基于如下情况：

• 创建一个属于自己的个人工作分支，以避免对主分支 master 造成太多的干扰，也方便与他人交流协作。
• 当进行高风险的工作时，创建一个试验性的分支，扔掉一个烂摊子总比收拾一个烂摊子好得多。
• 合并别人的工作的时候，最好是创建一个临时的分支，关于如何用临时分支合并别人的工作的技巧，将会在后面讲述。

创建分支

#创建了一个名叫“b1"的分支。
git-branch b1

#把刚才创建的那个叫"b1"的分支给删除了。
git-branch -D b1

查看分支

git-branch

会把所有的分支名称列出来。前面打“*”号的就是你当前所在的分支。

导出分支内容，切换分支（git-checkout）

运行git-checkout后，会将当前所在的分支的最新版本内容导出来（如果你在修改后还没有提交的话，那种这种导出将直接覆盖你的修改）。 而如果运行

git-checkout master

那么，就会从当前分支切换到master分支上去。

查看版本库中每个分支的世系发展状态（git-show-branch）

git-show-branch 命令可以使我们看到版本库中每个分支的世系发展状态，并且可以看到每次提交的内容是否已进入每个分支。不过格式不敢恭维，眼花缭乱的。

查看差别（git-diff）

查看当前工作与版本库中的差别 运行 git-diff 将给出当前工作目录中的文件与版本库的头节点（最新提交的）数据的差别，差异将以典型的 patch 方式表示出来：

git-diff master b2

可查看master和b2两个分支的差别。

查看某个分支的发展过程（git-whatchanged）

运行 git-whatchanged 可以显示当前所在分支的发展状况（版本提交状况）。

分支合并与冲突解决方式

git-checkout master
git-merge "Merge work in robin" HEAD b2

和

git-checkout master
git-pull . b2

作用都是将b2这个分支的最新版本内容（提交后的）合并到master分支中去。如果在合并的过程中出现了冲突（具体通俗点说，就是在master, b2这两个分支中的某个文件的某些相同的行中的内容不一样），我们就需要手动解决这些冲突，用编辑器把发生冲突的那个文件的内容编辑一下（会在里面看到 diff的文件格式）。然后再执行

 git-commit -i XXXX （XXXX就是发生冲突的那个文件名）

就可以提交此冲突文件，并且将未合并完的过程继续做完。

逆转与恢复命令（git-reset）

项目跟踪工具的一个重要任务之一，就是使我们能够随时逆转（Undo）和恢复（Redo）某一阶段的工作。git-reset 命令就是为这样的任务准备的。它可以将当前的工作分支的“头”定位到以前提交的任何版本中。

git-reset 参数 版本标号

其中，参数项可以有以下3个。
--mixed
    	仅是重置索引的位置，而不改变你的工作树中的任何东西（即，文件中的所有变化都会被保留，也不标记他们为待提交状态），并且会提示什么内容还没有被更新了。这个是默认的选项。 
--soft
    	既不触动索引的位置，也不改变工作树中的任何内容。这个选项使你可以将已经提交的东西重新逆转至“已更新但未提交（Updated but not Check in）”的状态。就像已经执行过 git-add 命令，但是还没有执行git-commit 命令一样。 
--hard
	将工作树中的内容和头索引都切换至指定的版本位置中，也就是说自“版本标号”项之后的所有的跟踪内容和工作树中的内容都会全部丢失。因此，这个选项要慎用，除非你已经非常确定你的确不想再看到那些东西了。 
其中，版本标号通常可以用 HEAD, HEAD^ 之类的标号表示。

与其它人交换代码

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

项目克隆命令（git-clone）

此命令会将项目库中的所有内容（包括版本数据记录和所有的文件）都拷贝到本地。 它支持5种协议：

**本地目录**： git-clone /root/workspace/projects/kernel/kernel-2f/ 
    下载，单向操作

**SSH服务**： git-clone git@172.16.2.56:/root/workspace/projects/kernel/kernel-2f/
    上传下载，双向操作

**GIT服务**： git-clone git://172.16.2.56/root/workspace/projects/kernel/kernel-2f/
    下载，单向操作

**Rsync**： git-clone rsync://172.16.2.56/root/workspace/projects/kernel/kernel-2f/
    上传下载，双向操作

**HTTP**： git-clone http://172.16.2.56/root/workspace/projects/kernel/kernel-2f/
    下载，单向操作

抓取版本记录（git-fetch）

将远程版本库中相对于本地库的origin的版本更新信息下载下来。更新索引。 与 git-clone 一样，它也支持上面5种协议。如 git-clone git@172.16.2.56:/root/workspace/projects/kernel/kernel-2f/

获取实际文件（git-pull）

git-pull与git-fetch的区别在于git-pull将版本记录下载下来后，还要与本地分支进行合并。所以相当于 git-pull = git-fetch + git-merge。

利用服务器进行协同开发工作（代码管理模式探讨）

一个团队进行项目开发，必须要有清晰的开发交互管理模式。一般来讲，一个团队总是要用一个服务器来做为代码的存储和下载中心。如何将基于分布式概念的git用活成为一个方便的团队版本管理工具，是一个值得研究的问题。下面以一个实例来探讨一下： 现有A，B，C，D四个员工，一台服务器。服务器IP为172.16.1.50，A的计算机IP为172.16.1.51，B的计算机IP为172.16.1.52，C的计算机IP为172.16.1.53，D的计算机IP为172.16.1.54。有一个项目，名叫GOD，A是管理员。可以有如下几种工作方式。 一： A在本地机器上建立GOD的代码库。其他三位员工直接从A的机器上克隆（利用SSH，需要知道用户和密码）代码和版本信息。然后，B，C，D分别在各自的master分支里进行工作。等到要提交的时候，比如说B要提交，则B给A发封邮件，提醒一下，我这儿有些工作要提交给你。A收到提示后，就主动去B的机器（通过SSH）上去取（需要知道用户名，密码）master分支，取的时候，将取回的版本信息存放到本地的一个新的分支中去。然后，再将这个新的分支与自己的工作分支（可能是master分支）进行合并，产生新的代码。合并完成后，再通知B，我已经合并完成了，请你同步到最新的代码来。于是，B用git-fetch或git-pull将A的合并后的代码同步到本地机器上来。这样就完成了一个交互。C，D也类似。 这样做的特点就是：

1. 没有使用独立的服务器；
2. 需要B，C，D和A知道互相知道对方的机器帐号，密码；
3. 不需使用邮件来交互；
4. 需要管理员A来主动取各个员工的代码。

二： A在服务器上建立一个GOD的公开版本库。利用git协议，或http协议（匿名的）。A在本机上工作的内容，首先是推到服务器上去（git-push）。其它员工，从服务器上去克隆（git-clone）代码。B，C，D在下载代码后，在各自的master分支上开发。B做了一些工作后，再提醒A来我这里取代码，A主动去取。取回后，再合并。最后，把合并好的代码再Push到服务器上去。其他员工从服务器上来pull代码，进行同步更新。这样做的特点是：

1. 使用了独立的服务器；
2. 需要A知道B，C，D的机器帐号，密码。不需要B，C，D知道A的机器帐号，密码；
3. 不需使用邮件来交互；
4. 需要管理员A来主动取各个员工的代码。

三： A在服务器上建立一个GOD的公开版本库。利用git协议，或http协议（匿名的）。A在本机上工作的内容，首先是推到服务器上去（git-push）。其它员工，从服务器上去克隆（git-clone）代码。B，C，D在下载代码后，在各自的master分支上开发。B做了一些工作后，利用 git-format-patch origin 打自己的版本与origin版本的补丁（最好在打补丁之前运行一下git-fetch origin，跟进的最新的版本记录），生成后，通过Email的形式，将补丁发给A。A收到后，对自已的工作代码打补丁。最后，把打补丁（合并）好的代码再Push到服务器上去。其他员工从服务器上来pull代码，进行同步更新。这样做的特点是：

1. 使用了独立的服务器；
2. 不需要A知道B，C，D的机器帐号，密码。不需要B，C，D知道A的机器帐号，密码。只需要知道各自的邮箱即可。
3. 需使用邮件来交互；
4. 不需要管理员A来主动取各个员工的代码。由员工主动向管理员发送补丁文件。

trac概述

 

概念

• wiki
• ticket：用于Bug报告、系统增强请求。
  • 报告者
  • 类型（缺陷？增强？...）
  • 相关项目哪个部分（Component）
  • 相关项目哪个版本
  • 关键字，便于检索
  • 优先级
  • 相关哪个待发布版（blocking that release）
  • 属于谁：谁负责解决之
  • Cc：逗号分隔的用户或电子邮件地址，他们需要获得ticket变更的通知
  • 解决方案：总结为何此ticket被关闭
  • 状态：该ticket所处的状态
  • 简述：简述该ticket
  • 详细描述
• Roadmap：列出系统中未来的发布，与这些发布相关的tickets
• Milestones：系统（待）发布版。Milestones可以给出描述和目标日期
• Timeline：按发生的顺序，列出所有trac中已发生的事件（以事件简述、适用哪里、事件触发者的形式）。下述类型的事件被列出：
  • Wiki页事件：创建和改变
  • Ticket事件：创建和解决/关闭（以及其他改变）
  • 源代码改变事件：Repository check-ins
  • Milestone：里程碑版相关变动

开发流程

 

增加新特性

1. Wiki上开一页的新特性提议列表
2. 开发者根据上表，Wiki上开一页新特性计划实现列表
3. 新建ticket（类型为enhancement）
4. ticket附加到milestone
5. ticket指派给一个开发者，该开发者负责解决此ticket
6. （版本管理程序中）创建一个分支（每个ticket对应一个分支）
7. 进行代码修改
8. （版本管理程序中）融合
9. 解决ticket

 

修正Bug

1. 新建ticket（类型为defeat）
2. <重复ticket？>——>解决为“duplicate”，增加评论：“该ticket为xxx的重复”
3. <含有足够的信息进行处理？>——>要求报告者提供更多信息
4. <可重现？>
5. 分优先级
6. <是否修正之？> 否——>解决为“wontfix”
7. 附加到合适milestone上
8. 指派给开发者修正
9. （版本管理程序中）在相关的发布标记的支中分支
10. 进行修改
11. （版本管理程序中）融合相关修改到对应支中
12. 解决ticket

trac链接

Trac链接是Trac的一个基础特性。通过它，可以轻松地在支持任何wiki语法之处，超链接系统的不同实体——任务单（tickets)、报表（reports）、变更集（changesets）、wiki页面、里程碑（milestones）和源代码文件。 Trac链接通常以type:id（id代表实体的数字、名字或路径）的形式，但一些经常用到的实体有缩记符号。

适用场合

可在如下场合使用：

• 源代码（Subversion）提交的日志信息
• Wiki页
• 任务单（tickets）、报表（reports）和里程碑（milestones）的详细描述。

还有其他明确的标明支持wiki语法的文本域。 一些例子：

• 任务单（tickets）：#1 或 ticket:1
• 任务单评论（ticket comments）：comment:ticket:1:2
• 报表（reports）：{1} 或 report:1
• 变更集（Changesets）：!r1, ![1], changeset:1 或 (有限使用) ![1/trunk], changeset:1/trunk, [2:5/trunk]
• 修订日志（revision log）：r1:3, [1:3] 或 log:@1:3, log:trunk@1:3
• 差异（diffs） (需要Trac版本0.10以上）：diff:@1:3, diff:tags/trac-0.9.2/wiki-default//tags/trac-0.9.3/wiki-default 或 diff:trunk/trac@3538//sandbox/vc-refactoring@3539
• Wiki页面：CamelCase 或 wiki:CamelCase
• 父页面：[..]
• 里程碑（milestones）：milestone:1.0
• 附件（attachment）：attachment:ticket:944:attachment.1073.diff
• 软件版本仓库中的文件：source:trunk/COPYING
• 软件版本仓库中文件的某个特定修正版： source:/trunk/COPYING@200
• 软件版本仓库中文件的某个特定修正版的某行：source:/trunk/COPYING@200#L25

trac链接的高级用法

相对链接

创建指向页面的某个锚（anchor），使用"#"，比如 [#Relativelinks relative links] 提示：当你移动鼠标到段的标题上，一个“¶”字符将会显现。这是一个只向该段的链接，用它可以拷贝该段的锚（anchor）。 创建指向一个子wiki页面，只要使用“/”，比如 WikiPage/SubWikiPage 或 ./SubWikiPage 在子wiki页面创建指向父wiki页面的链接，使用“..”，比如 [..] 链接到兄弟页面，使用“../”，比如[../Sibling see next sibling]

wiki内的互链

其他前缀可以任意定义，用来指向其他web应用的资源。这些前缀的定义和指向web应用的URL在此说明。

trac互链

trac互链是专门面向链接其他trac项目中的资源。 任何类型的trac链接可以写成trac环境和实际指向那个trac环境资源的引用，之间用冒号隔开。

新建wiki

新建wiki页的步骤

1. 决定wiki页的名字。
2. 编辑某个存在的wiki页面 (或其他支持 Wiki语法的资源），增加一个只向你新的wiki页的链接。保存更改。
3. 点击指向你新wiki页的链接。Trac将会显示一个 "describe PageName here" 的信息。
4. 点击 "Edit this page" 按钮，来增加、编辑新wiki页的内容。保存更改。
5. 现在，你的新wiki已经发布了。

你也可以在页面顶端的搜索框，输入CamelCase方式的名字，来跳过第二步。但是当心，这样做，该wiki页将成为“孤儿”页，直到你在别的地方建立指向它的链接。 （在浏览器地址栏中，直接输入URL：dev.lemote.com/code/{当前项目名}/wiki/新的wiki页名称，也可以达到类似的效果)

wiki页的命名

Wiki页命名一般遵循CamelCase规范。Wiki文本中, 任何符合CamelCase形式的单词自动转换为一个指向以此单词命名的wiki页。 CamelCase的wiki页名必须符合以下规则：

1. 名子必须只能含有字母。不能含数字、空格、标点符号或下划线。
2. 名字必须至少含两个大写字母。
3. 名字首字母必须大写。
4. 每个大写的字母其后必须是一个以上的小写字母。
5. 在wiki页命名中，可以使用斜杠（/）（可能是代表一种层次关系）

如果你想创建不遵循CamelCase规则命名的wiki页，你可以使用如下语法：

• [wiki:Wiki_page], [wiki:ISO9000]
• [wiki:"Space Matters"] 这个页名内含空格
• 或更简单的： ["WikiPageName"]s (!MoinMoin的内部自由链接风格)

从Trac 0.11版开始，可以指定到Wiki页的一个特定版本，比如：WikiStart@1 另外，可以在Wiki名后尾随一个锚（anchor），来指向wiki页的某个特定段。是否有锚，可以简单的通过移动鼠标指针到段头，看到其后出现的“¶”标志，也可以明确指定。 

CamelCase

CamelCase是最初的wiki创建超链接的规范，额外要求大写的字母其后为小写字母。于是，“AlabamA” 与 “ABc”不是链接。

自定义Wiki行为

某些人不喜欢通过CamelCase进行链接这种方式。 虽然Trac仍旧忠实的遵循最初wiki风格，但其提供了一组满足不同喜好用户的链接方式。
• 一种方式 （[wiki]中的ignore_missing_pages） 是，当链接是CamelCase方式时，简单地忽略不存在的wiki页，而非此单词灰显后跟问号。
• 另一种方式（[wiki]中的split_page_names），显示时，在CamelCase风格的链接的多个单词间自动插入空格符。
• 明确地创建Wiki链接也很容易，见wiki页的命名
• 另外，Wiki格式化显示可以在某些地方禁用。 (例如显示提交日志时)