可追踪是协同开发的核心

目录/Directory

#利用Github实现团队合作

By Xiaoming

前言

对于软件开发而言，团队的合作非常重要（这一点毋庸置疑）。实际上，不仅仅是软件团队需要协作，很多其他类型的团队都需要合作。合作是如此的重要，所以大量的成本就花费在了合作上，这包括时间成本和物质成本。尽管如此，合作对任何一个团队而言都是极为富有挑战性的事情，尤其是对于那种成员来自于不同地区的合作团队。 技术的发展给合作提供了一些工具，在一定程度上可以降低团队合作的难度。

Github是这些年出现一个用于项目开发和管理的网站。该网站是基于Git(一个版本管理软件)的，但是它并非是一个单纯的Git服务器，该网站的主要宗旨是给开源软件开发提供一个合作的平台。而大部分开源软件项目开发者都是一个非常松散的团队，其成员来自于世界各地，并不是一个很稳定的具有强约束力的开发团队。因此Github提供了很多的工具用于软件项目的协同开发，并取得了很好的效果。目前世界上最大的软件代码开发与托管服务器就是Github，甚至许多公司的自己软件（非开源）也使用了Github的服务器或者系统。

由于Github的成功也使其进入了其他类型的项目管理领域，例如设计、出版、政府等。Github更发展为面向组织合作的领域。因此，Github是一个很好的用于小型团队合作管理的开放型网络化平台。

项目中团队合作的需求分析

以软件开发类型的项目为例（其他类似），这里分析一下此类项目中团队合作中的主要需求。

1. 通讯交流

这里的通讯不是指的那种即时通讯工具，例如微信，QQ这类软件，而是围绕着项目某个问题展开的针对性强的交流。这个在团队合作中非常重要，同时又是最难以解决的。以软件BUG为例，假如测试人员发现了一个bug，他（她）通过通讯软件发送给了相关的开发人员，开发人员需要将该问题记录下来并且安排时间去解决。Bug的解决往往是不定时的，也许很快几分钟，也许要花上几天的时间。如果bug比较多，那么单纯靠开发人员的记录是无法实现的，因为无法保证开发人员有足够的耐心和精力去做记录这种工作，另外这种Bug的修改也是很难追踪的，需要成员花费较多的时间。特别是有的测试人员喜欢用电话进行沟通，这种沟通更是无法追踪，也许上午打完电话说完一个bug后，下午可能就忘记了。此外，通讯还经常发生在对一个文档（或者设计）的讨论中。通常我们会召开会议进行讨论，每个人会对该设计发表意见，但是是否有人记录这类意见呢？设计人员有没有能力将所有的意见记录整理出来呢？而这又要花费多少代价呢，另外比较重要的一点，这种通讯方式也是不可追踪的，这也是会议经常开，但是问题得不到解决的一个原因。

所以我们需要一个交流和通讯的工具，该工具必须保证是可追踪的，而且是针对某一问题（对象，话题，设计，图纸，文档等）是可追踪的。我们希望能够借助一个工具，将围绕着某个话题的讨论交流按照时间线索一一列出，直到问题解决或者获得结论。当然，通讯的即时性等基本属性还是应该有的。

2. 文档共享

文档共享是团队里一个标准配置之一，往往是借助于网络应用来实现的，例如云存储（网盘），FTP等。同样的一个问题：就是如何找到以前写的一个文档，这是一件痛苦的事情，特别是当开发进行到了一定程度的时候，已经积累了大量的文档，而大多数人忙于开发或者其他工作，并没有严肃认真的去组织或者规范文档的存储。这个时候如果需要从一堆公开或者私人的文档中找到几个月前写的一个文档，往往需要花费较多的时间，大部分时间都花费在了打开文档，扫一眼，然后关闭这类操作上了。唯一的一点提示可能就是文件名了。但是同类的事情做的多了，类似的文件名也会多了起来，其实是没什么太大帮助的。

所以，在文档共享中的一个需求也是可追踪的文档共享。单个的文档确实没有什么太大的意义，但是如果能够把文档嵌入到开发的过程中，而且随时可以追踪到，那么这种文档的共享才是真正有意义的。文档真正的目的是为了开发服务的，它反映的是在开发的某一阶段问题的记录，方案的设计或者是新思路和想法。

3. 问题追踪

项目开发实际上就是一个一个问题被解决的过程，从最开始的我们到底做什么到最后一个功能被实现，都是对应于一个个问题的解决。所以开发团队中提出问题和解决问题一样重要。与以上的功能类似，这里的问题同样也是要求可以追踪的。要确保存在的问题能够有指定的人在一定的时间内解决。此外，问题必须是依附于项目的，例如代码或者设计文档，因此问题追踪也应当保证记录对应的文档和代码等的对应变化。

4. 版本控制

版本控制的重要性不再解释，实际上版本控制并不是我们想象的只是保存一个版本那么简单，Github之所以功能强大，和Git的功能密不可分。版本控制软件实际上可以帮助我们做很多事，例如检查代码变动，检查程序员的工作量，代码评审，控制发布版本和开发版本等。版本控制也是团队合作必不可少的一个工具，可以避免资料冲突，提高协同效率。

5. 评审

在软件开发项目中评审主要是对项目中的设计文档，开发方案以及代码进行考察。在文档共享，版本控制工具的帮助下，评审也变得可行。此外，评审也是开发流程中的一个重要环节，也可以当成一个问题进行追踪。在团队开发中，评审往往代表着一个结点，或者叫里程碑。代码也可以评审，当然代码评审的过程比较繁琐，但是在一个结点上必要的代码评审是保证软件开发质量的一个有效手段（另一个是测试）。

6. 工作量评估

对于程序员而言，工作量主要反映在代码的编写和错误的排除上。对于项目其他人员工作量可以反映在设计文档，问题追踪或者其他方面。借助于Git版本控制软件，可以比较容易的查看代码量的变化；借助于问题追踪系统可以帮助了解解决问题的多少和难易程度。此外，工作量的评估主要依靠管理手段来实现。

7. 任务管理

任务管理就是定期发布的任务以及任务执行情况的汇报和检查。通常的任务管理往往是通过任务管理软件来实现的，例如微软的Project等。任务管理是一个综合的过程，涉及到资源的分配，人员的调动，目标的管理等一系列问题。对于小团队而言，任务管理可以不那么复杂，也许仅仅借助一个时间管理软件或者TODO List就可以搞定，然而共享任务始终是个难题。

8. 知识库管理

知识库是项目开发过程中积累的一些经验，知识，技能和教训。对于一个长期的项目而言，知识库的积累有助于新的人员快速进入开发角色，以及避免重复解决问题，浪费时间。即使是短期的项目，如果能够及时的积累知识，也可以为团队培养人才，为新的任务积累知识储备。所以，知识库并非必要，但是有的话确实对开发人员而言比较方便。

为什么Github适合用于团队协作

初步了解Github

Github创建的宗旨是为了帮助世界上的开源软件开发，在其首页就写着：

Millions of developers use Github to build personal projects, support their businesses, and work together on open source technologies.

Github提供了两种plan供选择。一种是免费的plan，一种是收费的plan。这两种plan的用户在功能上没有任何区别，都可以使用网站的全部功能，例如创建多个项目仓库，无限的参与到别人的项目中，同时可以邀请无限的人员参与到你自己的项目中等等。唯一的不同是免费的用户只能创建公开的或者开源的项目；而收费的用户可以创建私有的项目。Github承诺对开源项目永远免费使用。用户可以选择随时在两种plan里切换。

Github提供了哪些功能

• 代码版本仓库
• 问题追踪系统
• 项目WIKI
• watch, fork, star, pull request
• 贡献情况查询（pulse）（commit，文件数，代码数，问题数，访问率等）
• 设置合作者

一个典型的Github主界面如下图所示。

让我们更清晰的看看项目上面的头，它显示了一个项目的可以进行的操作，以及可以使用的工具。

这个界面是显示了你对全部项目的贡献情况。

代码版本仓库

这是github最基本的功能，提供了文件的存储和版本控制。免费帐号的数据仓库里文件最大不能超过100M。考虑到github的访问速度，这个限制对我们而言形同虚设。相对而言，github更适合存储大量的小文件。所以在利用github存储项目资料的时候，尽可能的不要压缩并采用多个小尺寸文档的方法。这样不仅可以加快存取速度，而且更有利于版本的控制。此外，尽可能的使用文本文件进行资料存储，这样文件内容可以采用其他的文本搜索工具进行搜索，并且git也可以提供diff命令查看文档的变化情况。这里推荐使用markdonw格式的文本来撰写项目过程中的文档，github本身也对markdown格式提供了不错的支持。

Github中同一个repository，可以设定合作者（collaborators），每个合作者都可以push自己的代码文档到该repository上。然而这是基于对合作者能力的信任上。实际上很多项目运作的时候没有设定合作者，那么其他人如何对该项目作出贡献呢？比较保险的一个方法就是利用Github提供的fork功能，将代码fork到自己的仓库中，然后就像开发自己的项目那样对该代码进行开发，实现某个功能。当该功能实现完毕后，可以向项目的拥有者发送一个pull request，告诉项目拥有者自己实现了某个功能（或者解决了某个Bug），项目拥有者通过pull request功能对该代码进行详细的检查确认无误后，将其pull到自己的repository中并merge到master分支中。这种方法保证了项目的代码质量。在非开源的项目中，通常使用设定collaborators的功能进行合作开发；在开源项目中一般使用pull request。

问题追踪系统

Github中最有特色的应该就是这个问题追踪系统了吧（Issues）。最典型的应用就是bug追踪。每个issue都要经历从创建到关闭的过程。每个人都可以针对当前的项目创建一个issue，可以是一个bug，可以是一个帮助寻求，可以是一个功能要求，也可以是其他创建者认为有意义拿出来讨论的问题。总之一个issue被创建出来后，就一直存在于该项目的各种统计活动中，作为系统的管理者或者订阅者，能够始终看到每一个issue。每个issue会被赋予一个编号，大家可以围绕着该issue进行讨论，上传文档，提交版本等活动，直至该issue被认为已经解决，issue的创建者可以把它关闭。

项目Wiki

Wiki是组织知识库的一个很有效的方法和手段。我曾经使用过Arch Linux的wiki，简直是一个Arch知识的大全，更别说还有著名的维基百科。对于一个需要长期运行的项目，人员更替是普遍的现象，而知识库可以将每一个参与者的知识和经验保留下来供其他人使用，可以在很大程度上减少培训的成本，加快新手的成长速度。更重要的是，可以避免在一些普遍性的错误上浪费时间和精力。Github提供的wiki系统是简单的可维护的，支持页面的编辑以及Markdown语法的使用，所以，编写一个wiki词条并不是很困难的事。wiki同样支持版本的跟踪，允许多人编辑，所以一个wiki词条并不需要一开始就很完善，它可以经过多人之手之后变的逐渐完善，并能够与时俱进。

对项目的操作

Github支持对开源的项目进行如下操作：watch，fork，star和pull request。Watch可以理解为“关注”，fork理解为“创建副本”，star可以理解为“顶”，pull request可以理解为“我要贡献代码”。Watch和star这里不再展开说明了，fork和pull request是一对经常使用的操作。当你需要为某个项目贡献代码（例如解决一个bug），但你本身不是该项目和合作者，无法直接推送修改至远程仓库，那么这时你可以利用“fork”操作将该项目复制到自己的账户下，之后你就可以像修改自己的项目代码那样修改该项目的代码。于是你可以动手解决这个bug。在经过测试确定解决了该bug后，你可以到该项目网站利用“pull request”命令向原作者发送一个请求，告知你解决的bug以及解决方法，思路，结果等。该项目作者会审查你对应该项目的代码，确认无误后，利用git的操作将你写的代码与自己原来的代码合并。通过Fork/pull-request操作实现了非项目组成员代码的提交。该操作对开源项目的开发非常有用，对于私有项目用处不大。

合作者

合作者（Collaborators）是github里的一个重要概念。合作者实际上是一种权限控制，它可以赋予其他人对你的代码仓库的写的权限（推送）。当你在一个项目的setting里设置了合作者后，你就可以在issue里将任务分配给某一个合作者，从而实现一种简单的任务分配。对于私人项目而言，这种权限管理比较简单但是也比较有用；Github还提供了business帐号，该帐号里可以对合作者分配不同的角色组，从而实现更加复杂的权限控制。需要指出的是，对于任何的非私有项目，其内容对于所有人都是公开的，可读的，所以一定要注意不要把不适宜公开的文档推送到非私有项目。尽管除了github自己的搜索功能外，你的仓库里的内容不可能被其他搜索引擎所搜到，但是已经有一些无聊的人在编写程序，利用github的搜索引擎来搜一些特定格式的文档，例如linux上的passwd文件。将仓库设为私有和避免此类尴尬。

项目统计

Github提供了pulse，graph等功能来对项目进行统计，包括修改次数，提交次数，访问次数等，通过该功能项目所有者可以大致了解项目成员的共享率以及项目的受欢迎程度。

如何使用Github进行协作

前面介绍了Github的基本情况，我们可以看出来，github恰好满足了协同开发中的需求，特别是核心需求，即可追踪的开发过程。这也是为什么github这么受欢迎的主要原因。那么如何使用github进行协同开发呢？这里会采用手把手的方法来一步步来说明如何进行协作。

第一步，创建Github帐号并确保可以登录并使用git工具

这部分网上有详细的教程，大家可以看我以前写的一个关于git和github的教程：Git/github极简入门指南。

第二步，将帐号信息发送给项目管理员

项目管理员就是git仓库的创建者。项目管理员收集合作者的github帐号，并通过github设置将合作者信息输入到项目配置中去。管理员创建初始仓库内容，其他人员进行pull和push等操作，将仓库创建至与当前进度吻合的程度。

第三步，项目管理员在issue上创建任务，将其分配给指定的用户

Issue可以用来创建任务。这里的任务不用特别具体，但是要求用户必须进行反馈，可以通过交互的方式对任务进行分解和细化，然后继续创建新的任务。当原有任务完成它的使命后（完成或分解），就可以关闭了。Issue的资源是无穷尽的，所以在使用issue的时候不必过分谨慎，如果觉得不合适就把它关闭就行了。注意：issue一经创建不能删除，只能关闭，也就是意味着所有的issue都会始终留在系统中。

issue上可以设置里程碑。我对里程碑的理解就是一个重要的进度节点，例如某个版本的发布或者某个项目的验收等。所有含有里程碑的issue都被close后，就意味着达到了该进度节点。

整个项目的实施过程都会停留在这一步，所以在项目过程中每个成员都要经常访问自己的github主页来看看有没有属于自己的问题要解决。Github提供了手机端的版本，可以安装后随时获得项目更新信息。

在这个过程中需要讨论的文档，代码等可以push到代码仓库中并在issue中引用（直接插入链接）。

第四步，总结知识经验并发布在wiki上

首先，检查wiki页面有否相关词条。如果有，可以进行编辑。如果没有，那么就可以创建一个新的词条。编辑词条主要使用文字，如果使用图像的话，可以将图像推送到github并获得链接，然后插入到文章中。文章使用markdown语法进行排版，所以需要对markdown语法有一定的了解，可以参考这里。另外在issue中也可以直接使用markdown。

一些担心的问题及如何避免

安全问题

首先，有保密要求的代码项目资料等是绝对不能放在网络上的，因此这个系统只用来对我们底层的项目进行管理（即平台，开发工具等）。如果不想把代码开源，那么可以使用github提供的私有仓库。使用私有仓库每个月只需要支出每个月$7的费用。而且有许多的私有企业使用github提供的私有仓库服务，因此代码和资料的安全性是有保证的。我们只需要保护好自己的账户和密码即可。

其次，如果对安全性仍有疑虑，我们可以考虑只使用github提供的issue工具，即用该工具来进行任务分配，问题讨论和bug追踪。仓库中只存放讨论所涉及到的资料或者wiki中的图片。但是这个缺点就是无法对开发的代码进行控制和评审。只能通过邮件等方式来进行文档传递。

总结

Github为协作开发提供了一整套的工具，非常有效实用。虽然不知道是不是最好的，但应该是可以改善目前团队之间协作的能力和水平。当然，Github只是工具，还是要依赖于团队的人员素质，制度等来提高项目开发能力，另外，Github也不能取代会议，面对面的交流等这种方式，甚至是视频会议。另外定期的Symposium也不能被Github取代。Github应该取代的是部分的邮件，消息，电话等。