GitHub与社会化编程

[核心提示] 社会化的浪潮正席卷整个互联网，在软件开发领域也是如此。社会化是如何改变传统软件开发的？同时，版本控制的理念与开源的精神正通过 GitHub 这样的社会化平台向更多的行业扩展，其未来的影响将不仅仅局限在开发领域。

I want to live in a world where it’s easier to work together than to work alone… where every part of the software development process is a joy， And I think GitHub can help make that happen.

在我理想的世界里，协同工作将比独立工作简单的多。在那个世界中，软件开发会是一个充满欣喜的过程，我认为 GitHub 正在推进这一愿景的实现。

— GitHub CEO Wanstrath

最近 GitHub 因为两件事成为了媒体的焦点，其一是 Wired 的一篇关于 Github 的文章以 Github 上的 Repository 的形式进行了发行，这让人对 GitHub 未来更广泛的应用充满了期待。其二是一名俄罗斯黑客通过 Ruby on Rail 的漏洞获得了 GitHub 的顶级权限，可以对进入的项目进行随意的操作甚至彻底清空，这在开发者界造成了一场大恐慌，GitHub 的流行度也可见一斑。

作为一个非程序员的我，第一次开始接触到 GitHub 与版本控制的概念大概是在 1 年多以前。那会儿我正热衷于研究 Firefox 插件 Pentadactyl 的各种设置，而网上能找到的众多插件和配置文件大都托管在一个名为 GitHub 的网站上。为了能够跟踪最新的插件更新，我关注了众多 GitHub 上的项目和开发者，为了管理方便，我开始学着将自己的插件和配置文件放到这个平台上。这不仅为我的配置文件在云端免费进行了备份，同时需要的时候我还能够方便的回滚到过去某个时间的某段配置代码。经历过几次数据丢失惨剧的我当时的想法是：“如果早知道这个网站该多好。”我当时认识到的，仅仅是 GitHub 的冰山一角…

GitHub – 不仅仅是版本控制

版本控制这个概念本身对于程序员来说并不新鲜，从 1982 年的 RCS，到 CVS、SVN，再到现在流行的 Git、Mercurial 等，但凡有规模的软件项目都会采用某种版本控制系统来追踪文件的变化、处理软件分支、避免版本混乱。只要拥有一台主机，任何人都能很容易的搭建自己的版本控制服务器。如果仅仅是提供一个支持版本控制的代码托管服务的话，那么其本身并无任何特色可言，但 GitHub 并不局限于此。

GitHub 的理念非常简单：社会化编程。像 Twitter 一样，每个人都可以在 GitHub 上发布自己的各种代码，以时间流的形式展现自己的开发进展，可以关注自己感兴趣的项目和开发者，发表评论，了解其最新的开发动态。但所谓的社会化，还不仅仅局限于此，GitHub 最重要的特征是以一种社交化、民主化的形式进行代码协作。

GitHub 的社会化编程理念可以说将开源的概念发挥到了极致：由于采用了 Git 这种分布式版本控制系统，所有人都可以对任意一个公共项目简单的进行分支开发，而不会对原项目有任何的影响；可以将自己对于项目的功能改进、漏洞修复、或有价值的代码提交给原开发者，一起对项目进行完善。

项目的派生（Fork）和拉拽请求（Pull Request）构成了 GitHub 最独具一格的工作模式，对提交代码的逐行评注及 Pull Request 构成了 GitHub 特色的代码审核。

GitHub 拥有一个非常鼓励合作的社区氛围。这一方面源于 GitHub 的付费模式：私有项目需要付费，而公共项目完全免费。这意味着 GitHub 上的大多数项目都是开源的，任何用户都有海量的开源项目选择可用来分支学习和贡献代码。GitHub 的项目关注、开发者关注、@回复、个人页面的工作项目信息等社交功能可谓完全为开源项目量身打造，大大的促进了用户之间代码的交流，非常适合于开源项目的沟通和管理。一个意外的发现是，在很多程序员的简历上，GitHub 的个人页面也已经成为了其一个重要的技能标志，这也鼓励了更多的人积极的加入 GitHub 的开源项目中。

对于大多数开源协作项目来说，这无疑是发挥大众认知盈余的最好工具。从 Ruby on Rail 框架、Linux 内核、jQuery 脚本、Homebrew 包管理系统、Bootstrap CSS 框架，在众多明星项目的吸引力作用下， GitHub 已经成为最为活跃的开源社区，就连 Twitter、Facebook 等公司也选择了 GitHub 作为其开源项目的首选平台。

社会化如何改变编程

The power of GitHub I believe is that it allows programmers to share their work with their colleagues, learn from others, and work together with others.

GitHub 的最大优势在于程序员可以与他人分享各自的项目，彼此互相学习，并协同合作。

这段对于 GitHub 最大优势的描述在我看来正好总结了社会化对软件编程带来的最大变化。

1.更好的分享已有的代码和算法

很多时候，我们并不需要从头去重建一套问题的算法，开放的社会化网络为我们寻求现有的解决方案提供了一个极佳的发现渠道。像 jQuery、PhoneGap、Appcelerator’s Titanium 等这样的框架为 Web、App 开发带来了无比的便利，而它们就是从 GitHub 这样的社会化平台上成长起来的。

2.为开发者提供一个最好的成长平台：

像所有成功的社交网络一样，GitHub 上早期聚集的众多优秀的项目产生了一种网络效应，吸引到更多的项目加入 GitHub 中来。对于入门者来说，这是一个最好的提高自己技能的平台。GitHub 的开放、社会化属性让用户倾向于关注更多的项目、查看更多的代码，看到一个优秀项目是如何一步步成熟的，而这正是开发者成长中相当重要的一个环节：查看优秀的代码，学习其他开发者如何解决特定的问题，了解一个项目该如何扩展。

就像一本好书一样，查看其他开发者如何解决某个问题的代码可以给我们带来很多启示，为我们提供很多我们也许都没有意识到的解决方案。GitHub 这样的社会化编程平台能够不断为我们带来惊喜。

3.民主化的代码分支与派生：

在传统的开源项目中，对代码进行分支并不是一件得到鼓励的事，Linux、Unix、Android 都是分支过多造成系统分裂的典型例子。在很多项目中，要想对项目进行某个分支，必须征得项目管理者的正式同意才能进行。

而在 Git 这样的分布式版本管理系统中，每个用户在本地都可以拥有项目的全部代码和修改历史，开发者无需任何批准即可实际进行代码分支开发并 Push 到自己的分支项目中去。如果自己的分支取得了预想的效果，用户可以将变动的代码向原始开发者进行提交请求，而原始开发者可以对这一分支的实际效果进行评估，确定代码的有效性后合并入主开发线，而不用担心第三方的无组织分支会对项目本身造成危害（这一过程被成为 Pull Request）。这使 GitHub 上的第三方开发者用户对修改和分支现有项目的积极性得到了大大的提高。

如果我想增加一个新功能，或者想修改代码，我会将代码 Push 到一个新分支，并且新建一个 Pull Requests。如果我的代码会影响我同事的代码，或者他们对我的代码感兴趣，或者他们时间充裕的话，他们可以查看我的代码。这时我们可以将那个分支发布到其他机器上，调试新功能，如果一切正常的话，就可以将这个分支合并到主分支去。

— GitHub 员工 Zach Holman

社会化编程 – 不仅仅是程序员的福音

对于包括 Linux 创始人 Linus Torvalds 等开发者来说，他们的项目对于代码的质量要求非常苛刻，在他们看来 GitHub 带来的更多的是垃圾代码的剧增，并不具有太大的价值。但对于更多资源有限的开源项目来说，更民主化的社会化开源运动为其带来的则更多的是优秀程序员的更大的贡献。

如果认为 GitHub 这样的版本控制及社会化平台仅仅是程序员的福地，那我们又错了，人们已经开始发掘出 GitHub 能够用于的其他创造性用途。在本文开始提到的 Wired 杂志于 GitHub 上的实验文章项目里，读者可以自由的进行代码分支、内容更新、翻译，并把结果向 Wired 进行提交；Scott Chacon 在 GitHub 上托管了一本关于 Git 的书籍 Progit，在发布的一个月内就开始有分支出现，三年后的现在，这本书已经拥有 647 个分支，被翻译成 10 种语言，另有 10 种语言的译本正在进行中。（有趣的是，作者提到这本书一半以上的流量来自于中国，“无数的中国人因为这本书的中文译本开始学习 Git。而这一切之所以可能，也是因为有人利用 GitHub 的分支提供了本书的中文翻译。”）

版本控制的理念与开源的精神正意外的通过 GitHub 这样的社会化编程平台向更多的行业扩展，其未来的影响必将远远超越其起源的开发领域。

转载不附出处，求删

http://event.geekpark.net/read/view/155317

它的文档做得太烂了，提交一个项目第一次好用，过段时间不好用了，认证总失败，也查不到原因，懒得研究，弄了个免费的svn，虽然慢点，但上手容易。

那是你自己的问题。 我还没听说人家文档烂，项目不好用的论调。相反，都是说文档好用简洁，项目push也很方便的。

说个笑话 有人说github文档烂和难用

very funny....

错过github就错过了最好的学习机会

git和svn的工作方式是非常非常不一样的。
github只是做git hosting，不是它的错的。关于git的文档，有好多好多，比如progit什么的都还不错的。

从svn转到git上工作不适应也是完全正常的啦。

你妹的~现在转载东西都老牛B了