在版本控制工具大行其道的今天，作为程序员，势必要每天与各种版本控制系统（比如Subversion、Git、Mercurial等）打交道， 每天不commit几次代码都不好意思说自己是专业程序员^_^。不过commit代码可不止敲入commit命令这么简单，对于一个专业程序员 来说，我们还要关注每次commit所携带的背景信息，这里暂且称之为“commit context”。在每次commit时，这些上下文信息只能通过commit log来体现。

一、Commit Context

今日的软件复杂度日益增加，软件开发模式也早已从单打独斗的英雄模式变成了团队协作模式了，而在团队模式下，版本控制系统发挥着至关重要的作用， 它让开发过程变得有序，将冲突解决的成本尽可能地降低到最低。但版本控制系统毕竟不是智能的，它只是机械地记录着每次提交前后的内容的raw差 异，至于这个差异究竟代表了什么，版本管理系统是不得而知的，这就需要我们开发者们来提供，这就算是产生commit context的动机吧。即便是一个人开发维护的项目，个人的记忆也是有时效性的，时间久了，以前的代码变更context势必也就淡忘了，良好且规范的 commit context有助于更好的维护项目，追踪历史思路和行为，甚至在查找bug时也是能帮得上大忙的，比如确认bug引入的时段边界、代码范围等。

前面说了，commit context最终是以commit log形式提供的，这才是我在这篇文章中真正要说的内容^_^。评价一个项目的好坏，无论是商业项目，还是开源项目，代码本身质量是一个重要的方面，代码 维护的规范性则是另外不可忽略的一个重要因素，而在代码维护规范性方面，commit log的规范是一项重要内容。做了这么多年Coding工作，到目前为止部门内部还没有哪一个项目在commit log规范方面是让我满意和欣赏的。另外本人在亲为commit log方面也是不能让自己满意的，这也是促使我思考commit log这块内容的一个初衷。

commit log承载着每次commit动作的context。一般来说context中至少要有一项内容，那就是此次代码变更的summary，这是最基本的要 求。如果你的commit log还是空着的，那你真该反思反思了，那是对自己和他人的不负责任。但无论是商业公司内部开发还是开源项目，commit context涉及到的因素往往不止一个，很多情况下commit context还与项目过程、质量保证流程以及项目使用的一些工具系统有 关联。我们来看两个知名开源项目的commit log样例吧。

[example1 - Linux Kernel]

audit: catch possible NULL audit buffers
It's possible for audit_log_start() to return NULL.  Handle it in the
various callers.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Julien Tinnes <jln@google.com>
Cc: Will Drewry <wad@google.com>
Cc: Steve Grubb <sgrubb@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

这是Linux Kernel项目的一个commit log的内容。从这个log携带的context信息来看，我们能够清楚地了解如下一些内容：

- 修改的内核模块范围audit
- 修改的原因summary: to catch possible NULL audit buffers
- 这个patch从诞生到被merge到trunk过程中涉及到的相关的人员列表
- 这个patch由Who sign-off的。

将mail list放入到commit log中，这是Linux Kernel开发过程规范所要求的，同样也是质量保证的一个方法。在《如何加入Linux内核开发社区》系列文章中你可以了解到一些有关Linux Kernel开发过程的内容。从这个例子中我们主要可以看出commit context与Project过程、质量保证链条方面的相关性。

[example2 - Apache Subversion]

Fix issue #3498 – Subversion password stores freeze Eclipse

* subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
  (simple_gnome_keyring_first_creds, simple_gnome_keyring_save_creds,
   ssl_client_cert_pw_gnome_keyring_first_creds,
   ssl_client_cert_pw_gnome_keyring_save_creds): If the keyring is locked
    and we are in interactive mode but have no unlock prompt function, don't
    throw a "GNOME Keyring is locked and we are non-interactive" error;
    instead, continue without unlocking it, so that the unlocking may be
    handled by the default GNOME Keyring unlock dialog box.

这是Apache Subversion项目的一个commit log的内容。同样从这个log携带的context信息来看，我们能够清楚地了解如下一些内容：

- 修改的代码范围subversion/libsvn_auth_gnome_keyring/gnome_keyring.c，包括括号中的函数名列表， 这个显然更为细致。
- 修改的原因summary: Fix issue #3498 – Subversion password stores freeze Eclipse
- 这个patch与问题跟踪系统的关联性 -issue #3498。

通过这个commit log，我们可以快速找到此patch对应的问题跟踪系统中的条目#3498，这样可以查看到一些更为细致的context信息。从这个例子我们主要能够 看出commit context与项目所使用的一些工具系统的关联。

综合以上可以看出良好的commit log是可以清楚全面反映commit context的。这里的“全面”是project-dependent的，是需要能够体现出涉及project的一切必要信息的：过程的、质量的、工具 的。

二、Commit log格式

Commit log没有放之四海而皆准的统一格式，而是project-dependent的。就我个人而言，我会在下面的几个问题上有纠结。

* 语言

不得不承认在创造编程语言方面，西方文化占了主导，语言中的关键字也多取自英语。虽然目前主流的语言以及新兴的语言都号称源码原生支持utf8或 unicode其他字符集格式，但却是很少见到在源文件中使用非英语命名变量或函数的，这也影响了我在commit log中对语言的选择 – 我基本上都是用英文编写commit log的。目前主流的版本控制工具都是支持unicode字符集的，你用中文提交也是没有任何问题的，尤其是在国内商业项目中，使用中文描述起来，理解上快且歧义少。我是不反对用中文写commit log的，但反感的是中英文混合写commit log（有些人用中文，有些人用英文）。每当批量看commit log时，中英文混在一起，一点美感都没有了。

commit log不是给最终用户看的，而是给开发维护人员看的。因此选择语言种类时要看这种语言是否能给开发维护人员的工作带来便利，精确全面地传达context。即便 应用是要发布给非洲人民，但若开发人员都是中国人，一样可以用中文编写commit log。

* 地道

说到“地道”，主要是针对你选择外语（大多数情况是英语）作为你commit log的承载语言时。就像生活在国外要用外国人熟悉的语言习惯与人交流似的，我们在用英语编写commit log时也要学会选用“地道”的词汇，远离Chinglish。当然想立即做到“地道”也不是那么容易，毕竟我们一直以来就按照Chinglish的思维去学 习英语的，一个比较好的方式就是多看看知名开源项目（比如linux kernel）的commit log，看看人家是如何选择词汇和组织句子的。其实Commit log中用到的词汇和句型很少，看多了也就找猫画虎的学会了。

* 规范

“没有规矩，不成方圆”，无论是商业软件项目，还是大型开源项目，莫不如此。如果要想很好的传达commit context，一个设计规范，内容全面的commit log格式是必不可少的。我们无需从头做起，很多开源项目在这方面都已经有一些良好的实践，比如上面提到的linux kernel的commit log convention，再比如这里有Apache Subversion的Commit log要求。TYPO3和FLOW3也有自己详细的Commit log说明。

制定规范时总体来说，注意以下几点：
– 格式简明扼要，只保留必要的项；
– 注意与项目过程、质量保证流程的结合，以及与第三方工具的关联（注意序号或ID的唯一性）；
– 对于规模较大的系统，可以考虑在log中体现影响的涉及的“子模块”或“子目录”名字或者逻辑功能的名字（比如前面linux kernel例子中的audit），这样便于快速定位本地commit的影响范畴。

三、Commit模板

如果像linux kernel或subversion那样涉及到过程、质量控制以及第三方工具的集成（比如问题跟踪系统、代码评审系统等）时，建议设置Commit log template(模板)以简化开发者commit log编写的工作。

* Subversion命令行客户端支持commit log模板

Subversion在命令行客户端侧暂无对模板的支持。不过可以通过一些trick模拟实现这个功能：

- 创建commit log模板log.tmpl，放在特定目录下，本例中放在用户的$HOME目录下
- 添加并导出环境变量SVN_EDITOR
         export SVN_EDITOR="rm svn-commit.tmp && cp ~/log.tmpl svn-commit.tmp && vi "

svn commit时，svn客户端会在当前路径下会执行类似$SVN_EDITOR svn-commit.tmp的命令，而svn-commit.tmp文件已经被替换为我们的模板文件，开发者只需按模板填写内容，并保存退出即可。如果 commit成功，svn客户端会删除当前目录下的svn-commit.tmp，否则svn-commit.tmp不会被删除，这将导致下次再提交 时，svn客户端检测到svn-commit.tmp的存在，从而新建立一个svn-commit.2.tmp的新文件，导致模板失效，这也是这个方法的 一个瑕疵。

* Git命令行支持commit log模板

Git是目前very hot的分布式版本管理工具，起步晚，但起点高，因此已经内置了对模板的支持，只需将模板文件配置一下即可。
         git config –global commit.template ~/log.tmpl

四、良好格式commit log的实施

即便有了良好格式的commit log的模板定义，但就我经验而言，实施起来也还会遇到诸多问题。commit行为是客户端发起的，要让所有开发者都能很好的使用模板并主动按模板提交需 要一些流程以及工具支持。比如在server段部署pre-commit hook，对提交的log格式进行检查，不符合模板格式的予以拒绝等。

对于与问题跟踪系统有关联的log格式，还要注意保持问题跟踪系统id或序号的唯一性，这显然是管理和过程方面的工作。

对于开源项目，一般merge到trunk需要owner的检查，所以反倒实施起来容易了些，只要有一篇内容丰富的 developer/community guide或convention之类的文档即可，多数知名的opensource project(比如linux kernel、subversion、apache httpd server、python等)都是有这类文档的，为这些project提交patch前是要好好阅读这些文档的，不能坏了规矩^_^。     
 

相信很多人和我一样，top是自己日常使用最多的linux资源查看工具。不过仅限于一些简单的日常场景罢了：敲入top命令，看看哪些进程占用 CPU较多，然后对这些CPU占用较多的进程逐一处理一下。显然这样使用top有些大才小用了。

以前在监控工具使用方面总是浅尝辙止，并未做过多深入研究。近来愈来愈觉得有必要针对几种常用工具好好学习一下了。而top便首当其冲。top是一款 以查看进程(task)信息为中心的Linux系统性能监控工具，通过top我们可以查看到进程相关的cpu和内存占用相关的实时采样信息，因此 top尤其适合用于持续跟踪分析某些进程对系统cpu和内存的占用情况以及对系统负荷的影响。

入门

top的入门使用极其简单，就像前面所说的简单地的输入"top"，我们就能看到top的输出了。

top – 06:35:47 up 7 min,  3 users,  load average: 1.00, 1.18, 0.67
Tasks: 189 total,   2 running, 186 sleeping,   0 stopped,   1 zombie
Cpu(s): 30.5%us,  7.6%sy,  0.0%ni, 60.5%id,  1.5%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1534164k total,  1423392k used,   110772k free,    67328k buffers
Swap:   999420k total,      144k used,   999276k free,   576924k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                      
 1954 tonybai   20   0  316m  55m  26m S   26  3.7   0:36.53 compiz                                       
 2308 tonybai   20   0  499m  84m  39m S   13  5.6   1:07.63 chrome
… …

top的输出大致分为上下两个部分，上半部分输出到是系统的总体负荷信息，下半部分则是分进程列出进程的各种属性信息。

总体负荷信息由五行组成：

第一行：top – 06:35:47 up 7 min,  3 users,  load average: 1.00, 1.18, 0.67。
这行的输出与uptime命令是一样一样的，不信你可以单独执行一下uptime命令。我怀疑top就是直接调用uptime或使用uptime部分代码 得到的，毕竟它们都是procps（procps is the package that has a bunch of small useful utilities that give information about processes using the /proc filesystem.）工具集合的一员。这行输出了当前时间( 06:35:47)、自系统启动以来的累计时间(7 min)，当前系统用户数(3 users)，1分钟，5分钟以及15分钟的平均负荷( load average: 1.00, 1.18, 0.67)。

第二行：Tasks: 189 total,   2 running, 186 sleeping,   0 stopped,   1 zombie。
系统的进程信息汇总，包括总数以及处于各种状态的进程数量。

第三行：Cpu(s): 30.5%us,  7.6%sy,  0.0%ni, 60.5%id,  1.5%wa,  0.0%hi,  0.0%si,  0.0%st。
系统的CPU信息汇总，包括us(CPU用于运行用户空间进程的时间所占比例，不包括renice的用户进程)、sy(CPU用于运行内核进程的时间所占 比例)、ni(CPU用于运行用户空间被renice的进程的时间所占比例)、id（CPU空闲时间所占比例）、wa(CPU等待I/O完成时间所占用的 比例)、hi（处理硬件中断时间所占比例）、si(处理软中断时间所占比例)、st(虚拟机管理程序为其他task而从本虚拟机'偷取'的CPU时间所占 比例)。

第四行和第五行：
Mem:   1534164k total,  1423392k used,   110772k free,    67328k buffers
Swap:   999420k total,      144k used,   999276k free,   576924k cached

系统的内存以及交换区信息汇总，包括内存总量(mem total)、已使用内存(mem used)、空闲内存(mem free)以及交换区总量(swap total)、交换区使用量(swap used)、交换区空闲(swap free)。这里还有两个值buffers和cache，它们是内核使用的内存缓存，均是用于减少磁盘读取，提升系统性能的。buffers代表有多少内 存用于缓存磁盘数据块，目的是减少写磁盘次数；cache用于缓存从磁盘文件读取的数据，以减少读磁盘次数。

下半部分是进程属性信息展示区。默认情况输出的进程属性包括：
    PID(进程ID)
    USER(进程所有者的用户名)
    PR（进程的动态优先级)
    NI（Nice值，进程的base priority）
    VIRT (进程的虚拟内存用量，包括进程的二进制映像大小、数据区以及所有加载的共享库占用的size， = SWAP + RES)
    RES（进程使用的、未被换出的物理内存大小,= CODE + DATA)
    SHR(共享内存区域大小)
    S（进程状态)
    %CPU（上次刷新到现在运行该task的CPU时间所占百分比）
    %MEM（当前task所占用的内存百分比）
    TIME+  （自task启动后所使用的CPU时间累计）
    COMMAND （task对应的二进制程序名）

定制输出

top提供了强大的输出定制功能，无论是上半部分的系统整体负荷信息还是下半部分的进程属性信息展示都是可以根据使用的需求定制的。

整体负荷信息展示区的定制：
- 第一行展示/隐藏：通过点击键盘上的'l'键可以展示或隐藏第一行信息输出
- Task和CPU信息展示/隐藏：通过点击键盘上的't'键可以展示或隐藏Task和CPU行输出
- Mem和Swap信息展示/隐藏：通过点击键盘上的'm'键可以展示或隐藏Mem和Swap行输出

进程属性信息的显示定制：
默认情况下，我们可以看到top会显示进程的若干属性，包括PID、USER、PR、NI 、VIRT 、RES 、SHR、S、%CPU以及%MEM等。不过这些也仅仅是默认的而已，如果你不关住其中一些属性或关注其他一些属性，你完全可以自定义输出显示的进程属 性。点击键盘上的'f'键，top将为我们打开field选择页面：

Current Fields:  AEHIOQTWKNMbcdfgjplrsuvyzX  for window 1:Def
Toggle fields via field letter, type any other key to return

* A: PID        = Process Id                           0×00002000  PF_FREE_PAGES (2.5)
* E: USER       = User Name                            0×00008000  debug flag (2.5)
* H: PR         = Priority                             0×00024000  special threads (2.5)
… …

页面左侧列出了可选的所有进程属性。其中前面有*前缀的是当前已经选择的属性，比如PID。不过你可以通过点击PID对应的开关键'A'来取消对PID的 选择；同样你也可以点击未选择属性前面的开关键来选择对应的属性，比如敲击'p'来选择SWAP属性。定制完毕后回车回到top主页面，你就会看到你定制 后的结果了。

保存你的定制

如果你不想每次都在top启动后重新做定制操作，那就将你的定制保存到top的用户配置文件中。在定制后的top主页面上输入：'W'，top会提示你：Wrote configuration to '/home/tonybai/.toprc，也就是说top会将你的定制保存在你的~/.toprc中。重启top看看，是否依旧是上次你定制后的结果呢^_^。

多视图

默认情况下top为我们打开了一个视图。不过top可不止支持一个视图。敲入'A'看看会发生什么？没错，你会看到上下分割的四副视图，另外在整个窗口的 左上角会出现反白的'1:Def'，这是一个active视图的提示文字。反复输入'w'，top会在各个视图间切换，左上角会在'1:Def'、 '2:Job'、'3:Mem'和'4:Usr'之间切换。‘1:Def'是默认视图，以CPU占用高低对task进行排序；'2:Job'这个视图看起 来比较陌生，里面展示的task多是些系统服务或内核线程；'3:Mem'视图则是以Mem占用高低对task进行排序；'4:Usr'视图则是按用户名 展示task。用'w'切换到某个视图后，可以输入'A'将该active视图放大为单视图铺满窗口。在多视图展示的情况下，还可以输入'-'来隐藏/展 示某种视图。另外这种多视图的配置也是可以保存在.toprc中的。

批处理模式

平时我们更多用的是在交互模式下运行的top，但交互模式下的数据无法记录下来，不便于事后分析，不过top的批处理模式可弥补这一不足。

执行top -b，即可让top以批处理模式运行。默认情况下top会不断重复执行，似乎批处理模式意义不大。不过我们可以限定批处理模式的运行间隔和运行次数，默认情况下top运行/更新间隔为3s，运行次数为无限制。我们可以通过一些命令行参数来设定这两个值，比如：

$> top -b  -d 1 -n 10

-d 用来设置更新间隔为1s；而-n 则设置批处理运行10次。

默认情况下top输出的task太多，我们可以通过指定相关进程或指定user来将关注面缩小，比如：

$> top -b -p 2500 -p 2501 -d 1 -n 10

这个命令只是会输出2500和2501这两个进程的相关信息。

$> top -b -u www-data -d 1 -n 10

这个命令只会输出www-data这个用户下的所有进程相关信息。

即便在批处理模式下，top依旧会输出整体负荷信息。这样一来对后续的数据后处理会带来些麻烦。一个好的方法是先定制top，再做批处理执行。比如先用 l,m,t把top的整体负荷信息都关闭掉，再定制好要关注的进程属性，保存到toprc中；之后再批处理运行top（可将输出结果重定向到某个数据文件 中），我们得到的数据就会比较规整，处理起来也十分方便了。