软件开发人员之所以能够在分布式协作领域一直扮演着先行者的角色，原因在于他们的工作成果一直以数字化形态体现。而随着网络黎明时代的全面铺开，他们的工作流程也开始走上联网道路。
帮助软件开发人员实现协作的各类工具加上围绕此类工具所构成的文化理念，当然也希望能够融入主流体系当中。遥想当年，电子邮件与即时消息——二者同样是在接触普通大众之前，首先由开发人员广泛使用——也曾经扮演过同样的角色并面临类似的状况。不过时至今日，这些通信模式早已走入了寻常百姓家。
不过为了协调Linux内核开发而诞生的工具Git与围绕该工具所衍生的文化体系GitHub，目前尚未表现出同样积极的关联态势。大多数非开发人士并不依靠编码作为谋生手段。但随着各个行业、各个领域的工作成果与流程逐步走上数字化方向，很多普通人同样会为这些共享式工具所吸引、并借此实现共享式数字化成果的协调式构建。有鉴于此，Git与GitHub才能够在代码之外、融入更多工作成果的实施流程当中。
根据Wired、ReadWrite以及其它多家站点的报道，GitHub目前已经被用于实现食谱、乐谱、书籍、字体、法律文件、课程与教程以及数据集等资源的协作开发管理。考虑到Git本身令人望而生畏的复杂性，以上状况无疑有些匪夷所思。
原因之一在于GitHub利用其Web界面逐步提供更多底层Git功能。另一项理由则是，更多Web应用程序开始利用GitHub作为其运行平台。接下来再看文化方面的因素：GitHub带来了一种特殊的协作途径。Dave Winer将其形容为“个人工作述职”阶段。我个人则用“看得见的工作”进行描述。Responsive Organization活动为其“隐私之上的透明性”而欢欣鼓舞。在GitHub管理体系内部，倡导者Ben Balter也以“开放式协作”对其加以盛赞。
在一篇尚未正式发表的博文中，我读到了Ben Balter就这一观点的说明。而自从该博文被托管在公共GitHub库中之后，我除了查阅文章的草稿之外，还对审查意见以及围绕该草稿展开的探讨内容进行了高度关注。当然，单单一套库并不一定需要向公众开放——但每一家企业都应当鼓励将开放协作机制引入内部业务流程。根据GitHub发展战略副总裁Brian Doll的观点，目前已经有越来越多企业对这种共享式机制表现出深厚兴趣。
人们常说，时至今日每一家企业都可算作是软件厂商。从抽象角度来看，这种说法并无不可——只要大家将知识产权也定义在软件范畴之内。而且对于不少企业来说，其真正业务价值也确实体现在内部开发的软件成果身上。
企业始终期望着能够将这种协作式发展机制在代码、测试、质量保证以及说明文档等传统领域之外加以进一步拓展。不过如果此类协作机制的贡献成果完全取决于我们自身对于业务或者客户的理解，那么大家可能很难直接参与进去。
“这太疯狂了，”Brain Doll表示。“如果大家在银行中担任管理者角色，那么员工及客户所使用的财富管理工具也就成为银行提供的产品——他们怎么可能直接参与此类方案的改进工作？”但在GitHub的帮助下，每一位股东都能够成为一流的参与者。相较于仅仅用于记录系统运作状态的电子邮件，他们还可以发送各类请求并直接在系统当中讨论相关问题。
驯服Git这只猛兽
作为GitHub引擎盖之下控制引擎的分布式版本，Git的运作方式不仅能够给非程序员带来惊喜、更能让普通程序员们通过集中化系统对其实现访问。
在此类系统当中，于库内部创建一套分支可谓非同小可，其作用相当于一系列既有成果的备用版本。在Git当中，一套分支就相当于一套轻量级构建成果、一种通过移动指针而非数据所产生的尝试预期。在传统系统当中，即使仅仅是为了变更文档中的每个字句而构建的分支都会带来高昂的实现成本。但Git却让这种机动性变得物美价廉。GitHub能够将其嵌入到工作流程当中——即获取到的请求——流程会对变更内容加以封装，而后将其与文档的变更历史相结合。
Git的这种千变万化的能力使其成为工作流程创新领域的理想实验环境，但可供选择的实现方式过多也带来了新的复杂性层。分支与合并机制虽然足够强大，但技术人员仍然在面对何时以及如何进行分支与合并操作时分裂成了各种派别。这一切都给程序员提出了严峻挑战，而且这种挑战要远比其它麻烦更难于解决。有鉴于此，我们如何才能驯服这只猛兽，从而保证非技术出身的利益相关者也能享受到它所带来的便利？
GitHub给出的答案是：强化网站本身以实现各类核心操作。如果一位律师希望修改法律文件中的个别字句，她根本不必接触恐怖的Git客户端; 她完全能够通过浏览器直接实现文件编辑。这种操作将启动一项pull request流程，其会针对特定变更创建出新的分支。GitHub用户总爱说“实现变更只有惟一一种方式。”虽然不是每个人都必须遵循这种黄金定律，但选择最简实现办法无疑能大大减少工作中遇到的阻力。
这样一来，只要企业愿意接纳GitHub、那么每一位员工都能轻松实现这种最佳实践。“不要在发现软件问题时盲目指责水冷机制不够给力，”Brain Doll提醒道。“现在大家已经有办法对自己了解范围内的问题加以修正。”这种鼓励人们参与进来的机制对客户也同样有效。
GitHub自身的变更同样至关重要。“如果不切身参与进来，”Software Carpentry项目创始人Greg Wilson指出，“我根本没办法搞清楚GitHub的权限管理机制、允许用户针对单一repo制作多种fork或者完成其它类似的工作。”
不过无论GitHub风格的交互方案如何具体起效，变更机制都能确切发挥作用——而无需担心针对单一变更的贡献内容到底属于代码、文档、法律建议、企业立场抑或是客户反馈。
作为GitHub当中最为重要的创新成果，沟通与共享的核心价值在引入其它社交媒体中的交流内容之后得到了进一步增强。举例来说，大家可以在Twitter上通过提及另一位Twitter用户的用户名来引起对方的注意。这种@提及技术在GitHub当中也同样为个人及团队作出了巨大贡献。
GitHub Pages同样不可不提，这项服务负责托管GitHub库之上的门户网站。对于熟悉Git并乐于安装（并以本地方式使用）基于Ruby的站点生成工具——也就是Jekyll——的技术型博主来说，GitHub Pages绝对是他们的心头最爱。不过也有用户发现，我们并不一定需要安装Jekyll。大家完全可以直接在浏览器当中管理GitHub Pages，同时享受版本历史以及问题讨论功能所带来的便利。
让变化变得可视化
版本控制与变更可视化机制已经深深植根于软件开发领域当中。时至今日，已经没有任何组件开发人员会考虑在无法通过“diff”进行变更内容说明的前提下讨论新版本中的某些代码。
大多数知识型员工并不具备这种非对等性分布预期。虽然在企业当中这种数字化技术认知应当成为基础性素养，但实际上其并未真正得到普及。而这也种障碍也同时影响到文化（‘我们之前从没采取过这样的方式’）以及技术（‘我的工作成果并不是什么文本文件’）层面。
软件开发所产生的数字化成果仍然体现为包含有文本内容的文件，而且其实质能够追溯至原始的打孔卡载体。我们也仍然需要一行一行对这些文件的内容在视觉基础上进行修改。编译器与IDE能够从模块以及方法的角度了解代码内容，但版本控制系统并不会分享这种认知结果。虽然从理论角度讲，利用计算设备将变更抽象理解为模块X或者方法Y、并随时间推移持续观察此类变更听起来完全可行，但在现实当中却并非如此。
这种理论与现实之间的不匹配状况源自多种深层次历史原因，而且在短时间内不可能很快得到扭转。与此同时，我们可以通过两种方式解决这一难题——而GitHub恰恰在这两方面都有所建树。
方法之一在于将富文档转换为文本文件。在政府机构当中这是一种常见的实践方式，其中GitHub则扮演着协作平台的角色，Ben Balter指出。他还创建出一款工具，能够将政府内部广泛使用的Word文档转化为Markdown——一种能够在GitHub以及其它多种环境下使用的纯文本格式。这种变通方案还远远称不上理想方式，这主要出于两点原因。其一，对文档格式进行往来转换通常存在风险——而Markdown并不属于标准化格式。其二，其中包含多种变量; 事实上，GitHub所使用的准确来说应该是Git Hub Flavored Markdown。
从理想角度看，GitHub应当能够直接处理富文档格式，其在这方面也确实取得了一定进展。我们长久以来早已能够以可视化方式对不同图像中的差别作出对比。一年之前，“prose diff”能够将不同Markdown文件内HTML渲染内容之间的差别以彩色方式进行高亮显示。这种方式同样也能用于着重体现CSV数据以及HTML表间的差异部分，但却并没能在文档结构识别方面做出更多贡献。
此类识别能力如今在一种格式当中成为现实，这就是GeoJSON。它能够将地理空间信息以JSON格式进行编码，而GItHub除了可以利用其作为数据渲染手段之一显示地图之外，也能够利用滚动滑块在不同版本之间显示该地图的直观版本变更历史。如果能够将这种方式推广到Word文档、PDF文件以及电子表格当中，那么GitHub类协作机制将帮助更多使用此类格式构建产品的人们加入到这个大家庭当中。
GitHub即平台
对于由其托管的数百万项目而言，GitHub并不能满足全部需求，但它允许人们在此基础之上构建成果并将成果融入当中。使用GitHub API的工具承载着大量来自现有库的项目管理功能，其中包括Waffleio、HuBoard以及ZenHub等等。
像Travis以及Jenkins这样的持续集成系统能够使用状态API报告与提交内容相关的测试结果。此外，CRUD API则让编程型提交内容得以在库当中实现文件的创建、更新或者删除操作。举例来说，Ben Balter就曾经利用它构建过一款应用程序，旨在从HTML格式内获取输入信息、并将其附加在GitHub库中的CSV文件当中。
当然，GitHub并不是一套适用于每位用户的平台。O’Reilly媒体的Atlas——一套用于发布多种书籍格式的托管系统——就直接建立在Git基础之上。不过对于多数非长久使用Git的用例而言，GitHub的界面——以及不断进化的扩展成果——必将成为一套强有力的综合体。
协作的文化
与Git类似，GitHub也成为多种协作方式的立足根基。GitHub鼓励各类关键性最佳实践，例如在不干涉其它来源的前提下通过一次性分支实现pull request提交。而标签则作为配发给提交内容及pull request的关键词。（其它社交系统可能会调用这些标签，但Git标签会识别库历史当中的特定点。）大家用不着强行使用标签机制，但一旦接触——如果大家的团队采用了详尽且具备高度一致性的用词——那么由此产生的过滤视图将帮助每个人快速了解项目的概貌。
建立实用的提交信息则是另一种促进协作活动的有效途径。程序员往往会在提交信息当中发挥幽默感，例如“我修改了一部分内容”，并通过多年的实践经验学会了如何及为什么要更为高效地对工作内容进行阐述。不过大部分知识型员工并不会用这种格式化的小型单位划分自己的工作成果、将其广泛共享至空间中并以有意义的方式提供他人可资借鉴的描述内容。
这些实践方式全部基于一项共识性结论，即所有共享成果都应当进行版本区分，而全部变更也都需要经过严格控制并配备文档记录——这种最佳实践绝不应被仅仅限制在软件开发领域当中。我们都在以分布式方式处理日常工作，因此需要审慎配合、关注细节并培养团队意识。Git为程序员们打开了通往无限希望的厦门，而GitHub的诞生则成为引导全民迈向协作时代的伟大道路。
英文：http://www.infoworld.com/article/2886828/collaboration-software/github-for-the-rest-of-us.html
