2012级读内核使用 Google Group 来通知、讨论、上传文件的,但效果不是很好,原因是多方面的,这次我们尝试使用GitHub来管理,Github 相比 GG 有很多自身的优势:

• 不用翻墙,虽然有时访问也会受限,但大多时间还是能正常访问的;
• 能对代码、文档进行版本控制,个人认为这是最大的优势;
• Github 的 Issue 模块可以用来跟踪阅读内核所遇到的问题;
• Github 其他功能模块,如Wiki、Page、Gist等等有功能强大且方便的用途;
• Github 中托管的开源代码数量已经超过Google Code、Source Forge,再不用Github你就 OUT 了!
• ...

当然Github也有其劣势,首先上手还是有点困难的,你得学点 Git 的基本命令、你得了解 Github 使用方法、你还需要懂得如何使用 Markdown 语法来编辑等等,但是,这些总的来都比较简单,而且作为一个搞技术的,这些是必须要掌握的。 使用Github 只是我个人的想法,希望用过之后能得到大家的认同,我接触 Git 和 Github 有段时间了,但用的很少,因此也希望趁这机会和大家一起学习学习,成为一个真正的 Gittor 和 Githubber !

我在Github 上建立一个 Organization,名叫 eslab2013-ustc,大家可以通过 https://github.com/eslab2013-ustc来访问,同时在这个帐号下创建了一个新的资源库 RTFSC_Linux_Kernel,即为你们读Linux 内核所有资料所存放的资源库。 那么我们如何来协作管理该资源库呢?

• 注册帐号,fork 资源库 每个人首先要注册一个github 的帐号,登陆之后进入资源库 eslab2013-ustc/RTFSC_Linux_Kernel,右上角有个Fork 按钮,即将该资源库拷贝到自己的账户下。
• 安装客户端,clone 资源库 该操作主要是将自己账户下(以下使用 account 做为该账号)的资源拷贝到本地。
  • Windows 平台 Windows 下使用git有命令行和图形终端两种,操作也较简单
  • Linux 平台 Linux下较简单,只需安装git,使用命令 git-clone
  • Mac OSX 平台 本丝没用过该系统,故略去...
• 本地与远程资源同步 此处远程资源指的是fork到 account 帐号下的资源库,本地是指clone到本地的资源库。在本地通过pull 与 push 操作就可以保证同步。
• 远程资源库与源资源库同步 源资源库指的是 eslab2013-ustc 帐号下的资源库,通过pull request 可保证同步。

为了规范化管理,对该资源库进行如下约定,望大家遵守!

• code 目录树如下:

   /
   |---2013年9月9日_ProcessManager1
   |		|
   |		|---topic&task.doc
   |		|
   | |---余奇
   | | |---汇报主题.ppt
   | | |---笔记1.doc
   | | |---笔记2.doc
   |		|	 |---code.c
   |		|	 |---...
   |		|
   | |---赵勇
   | | |---汇报主题.ppt
   | | |---笔记1.doc
   | | |---笔记2.doc
   |		|	 |---code.c
   |		|	 |---...
   |		|
   |		|---讨论记录.doc
   |
   |---2013年9月16日_ProcessManager2
   |		|
   | 		|---
   |		...
   |
   |---README.md
  

  • README.md 介绍
  • 每次讨论课以 日期_主题 建立一个文件夹
    • 由刘杰及组长给每个人分配本周的阅读内核的任务,提前建立文件 topic&task.doc
    • 各自(汇报人必须或者非汇报人若有要共享的)以 姓名 建一个子文件夹,最好能提前报告一天提交,内容包括汇报的PPT、平时读内核所做的笔记、所写的代码等等
    • 讨论课结束之后,将本次讨论的记录以 讨论记录.doc 文件存放提交

• Issues 管理 github 中的 Issue 功能原本是一个轻量级的缺陷跟踪模块,在此我们充分利用上 Issue 的功能: 首先是缺陷跟踪功能。我们在读内核中或者在作报告中经常会遇到问题,有些通过查资料或者大家讨论很快就能解决的,但更多的疑问一时半会都无法得出一个满意的答案,按照我的经验这些问题时间久了就丢掉了,但疑问仍然在那里,这不是读内核的初衷!所以,我们需要持续跟踪这些问题,直到解决!那么我们就可以在此处发表新的 Issue ,将问题描述清楚,为了能更好的将问题归类,请大家给自己的问题打上标签(Labels),最少一个、最多四个。大家可以将自己对该问题的想法写在该 Issue 的评论中,若最终有比较满意的答案,就可以 close 该 Issue。 其次,我们还可以将 Issue 作为实验室读内核的博客,将 Issue 作为博客来使用还只是个另类的尝试,之所以选择这个,一来我们内核讨论的圈子就集中在 github 上,没有必要再去其它博客类网站再建一个公共博客,分散大家注意力;二来,github Issue 天然具有博客的特点,使用github markdown 进行编辑文本,排版轻盈、代码高亮,且具有评论、标签等功能。为了区分博客与问题,希望大家在博客分享加上"blog" 标签。

• wiki 管理 github 提供了wiki 模块,方便项目团队维护项目文档,暂时这个模块我们不用。

最后将Linus 的一句名言送给大家:

Read The F*cking Source Code! ——Linus