作者：大塚弘记
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
GitHub入门与实践试读：
译者序
“开源”一词在我国 IT 界已经出现了不少年头，但“社会化编程”想必没有多少人接触过。于是在阅读正文之前，容我越俎代庖替作者问一个问题：各位在狭小的空间里呆上一段时间之后，再出门时是否有一种豁然开朗的感觉？相信很多人的答案都是肯定的。对于对日外包出身的我来说，“社会化编程”就给了我这种感觉。或许外包行业在 IT 界只是极端个例，但“让全世界码农看自己的代码”这种事，很多人恐怕想都不敢想吧。GitHub 正是这样一个平台，我们在这里可以与全世界的开源开发者交流代码或心得。如果您对某款开源软件的源代码感兴趣，如果您想为中意的软件出一份力，如果您自己编写了小程序却苦苦找不到人指点，如果您想跟慕名已久的 IT 界明星（俗称“大神”）聊上几句，那么 GitHub 欢迎您。
GitHub 的纯英文界面或许会令您望而却步，不过不用担心，本书秉承了日系技术书刊一贯的“手把手教学”风格，作者用亲切的语言，简明扼要的介绍，配以生动详实的示例为我们一步步讲解 GitHub 的使用方法，带我们在实践中学习 GitHub。值得一提的是，本书配有一个供各位实践的网站，请感兴趣的读者务必一试。俗话说“读万卷书不如行万里路”，跟着作者一边实践一边阅读本书，相信各位会对这句话有一个更深刻的体会。
有些读者可能要问了，代码是企业的财产，不能随便发到网上给别人看，那 GitHub 对工作又有什么意义呢？这一点作者自然考虑到了。GitHub 面向社会化编程，我们所生活的是一个大社会，我们工作的企业同样是一个小社会，虽然不能强行导入“社会化编程”，但其管理模式仍然值得借鉴。所以如果您是企业的决策者，那么请在本书后半跟随作者一起探讨企业导入社会化编程的利弊，说不定能为您所在的企业带来新的利益。《GitHub 入门与实践》是国内比较少见的对 GitHub 及社会化编程进行系统介绍的书籍。以往我们对于这方面知识，只能通过网络上零零散散的博客或技术文档进行片面了解，难以把握其全貌。各位读完这本书后相信能得到不少帮助。
最后，对另一位帮忙搭建本书相关网站的译者以及图灵文化的各位编辑致以衷心的感谢，正是有了各位的共同努力，本书才得以出版。同时感谢正在阅读本书的您，有了您的支持，本书才能发挥其价值。支鹏浩2015年4月 于北京
序言
当今世界有众多开发者在使用 GitHub 进行开发。本书旨在指导各位读者在开发现场如何使用 GitHub 进行高效开发。因此，书中除针对 GitHub 进行讲解外，也涉及了开发流程及相关辅助工具的解说。
您在开发现场有没有遇到过以下几件事？● 代码审查不到位，审查效率低下● 只有编程者本人能看懂的代码、可靠性不高的代码直接被部署至
正式环境中● 因键入错误、理解错误而造成的低级代码错误导致 BUG 频繁出
现● 没有机会和其他人互相交流代码，共享知识，相互学习、指正、
改善● 没有一个简单高效、能在一天之内添加多个功能的开发流程
GitHub 为我们提供了解决这些问题的机会和功能，而本书则凝练了各种运用 GitHub 的诀窍。
笔者曾为多家企业引入 GitHub，改善其开发流程。本书总结了这些经验，相信能为改善您的开发现场提供一些帮助。● ……谢辞本书在编撰过程中得到了多方的大力支持。特此鸣谢
@yamanetoshi、增田贵士（@masutaka）、bakorer、山科佑
贵、寺田涉、Tatsuma Murase、杉野康弘、泽义和（排名不分
先后）。另外，长期以来，技术评论社的池田大树为本书的编辑与整
理尽心尽力，在此由衷地表示感谢。2014年2月 大塚弘记
本书结构
本书由10章及2个附录构成。
第1章：欢迎来到 GitHub 的世界
讲解 GitHub 是什么，以及有哪些革新之处。在开源软件的世界中，GitHub 为开发者带来了革命性的社会化编程概念。在这里我们将会接触这一概念，并对其带来的优势与功能进行讲解。
第2章：Git 的导入
要使用 GitHub，离不开 Git 这一版本管理系统。本章将深入介绍关于 Git 的知识，加深各位对 Git 的理解，同时说明实际操作的相关流程。
第3章：使用 GitHub 的前期准备
使用 GitHub 需要开设账户（免费），因此我们将按照顺序为您讲解正式使用前需要进行的一系列设置。
另外，本章还会讲解包括操作示例在内的，实际在 GitHub 上创建仓库并发布代码的相关流程。
第4章：通过实际操作学习 Git
在实际操作中学习使用 GitHub 时所必需掌握的 Git 的基本知识和操作方法。
从最基本操作到多人开发时所需的复杂操作，读者都可以随着本章的讲解简单实践一番。
第5章：详细解说 GitHub 的功能
本章我们将以图配文，对 GitHub 的功能逐一进行讲解，同时还会详细解说其作为源代码查看器的功能，带您领略方便快捷的 UI。
建议正在使用 GitHub 的开发者也读一读本章，您或许会发现一些将来能用到的小技巧。
第6章：尝试 Pull Request
Pull Request 是 GitHub 的代表功能，本章我们将带您亲自动手体会。请务必参考本书内容试着进行一次 Pull Request。
第7章：接收 Pull Request
站在仓库维护方的角度，教您在接到 Pull Request 之后应该如何考虑，如何判断，以及该进行哪些操作。
第8章：与 GitHub 相互协作的工具及服务
前半部分为您讲解通过 CLI 对 GitHub 进行操作时所需的 hub 命令。另外，在持续集成环境方面，将讲解可与 GitHub 结合使用的 Travis CI 及 Jenkins 的构建及设定方法。
除此之外，本章还会介绍一些能够与 GitHub 共同使用的服务。
第9章：使用 GitHub 的开发流程
详细讲解以 GitHub 为中心进行开发的 GitHub Flow、Git Flow 两个开发流程。从两者共通的团队开发心得到各自开发流程的特征，都可以通过本章的讲解实际动手体会。
第10章：将 GitHub 应用到企业
总结在企业中采用 GitHub 时需要考虑的问题及一些有用的信息。安全保障、故障信息、事前需要考虑的问题、GitHub Enterprise 的讨论等，这些实际引入 GitHub 时需要考虑或者了解的知识将在本章中进行讲解。
附录 A ：辅助 GitHub 的 GUI 客户端
团队中并不是每个人都对 CLI 得心应手。因此，我们为读者总结了辅助 GitHub 的 GUI 客户端的相关知识。
附录 B ：通过 Gist 轻松实现代码共享
Gist 能帮助开发者轻松与其他人共享简单的代码示例或日志，我们将在这部分对 Gist 进行讲解。利用 Gist 可以轻松管理日常的小代码片段。
本书内容以敝社《WEB+DB PRESS》Vol.69的特辑《详解 1GitHub——使用 Pull Request 打造高效率的软件开发》为基础，进行大篇幅扩展与修正后作为图书出版。1詳解 GitHub——Pull Request が織りなす効率的ソフトウェア開発，WEB+DB PRESS vol.69，技术评论社。——译者注
本书的操作示例是在以下环境中进行的。● OS X 10.9.1● git 1.8.5.2
部分 Windows 相关解说中使用了 Windows 8。另外，GitHub 相关解说皆以2014年2月时的版本为基准。
由于环境和时期不同，操作顺序、页面、运行结果可能会存在差异。
本书中出现的示例仓库，现阶段主要由译者及尝试 Pull Request 的各位读者进行维护。但是在本书出版后，随着时间推移，可能会发生反应变慢甚至没有反应的情况。烦请参照第7章的内容以及关于示例仓库的讲解，一同努力维护。
对于您应用本书内容所产生的后果，本书作者、软件开发方及供应方、技术评论社、人民邮电出版社及译者概不负责，特在此声明。
本书中提及的公司名、制品名，皆是各公司实际使用的注册商标或商标。在正文中并未添加™、©、®标志。
关于本书的补充信息与勘误等，请参考以下网址。
http://www.ituring.com.cn/book/1581▶▶第1章欢迎来到GitHub的世界
本章将为您讲解 GitHub 是什么，以及为什么全世界的开发者都在使用它。同时，还会带您一起考察 GitHub 为开源软件世界带来了怎样的变革。1.1 什么是 GitHub
GitHub 是为开发者提供 Git 仓库的托管服务。这是一个让开发者与朋友、同事、同学及陌生人共享代码的完美场所。GitHub 公司与 octocat
GitHub 公司总部位于美国旧金山，拥有一只不知是章鱼还是猫的吉祥物 octocat（图1.1）。图1.2中是被改编成各种造型的 octocat 1们 。1http://octodex.github.com/
图1.1 octocat
图1.2 octocats并不只是 Git 仓库的托管服务
GitHub 除提供 Git 仓库的托管服务外，还为开发者或团队提供了一系列功能，帮助其高效率、高品质地进行代码编写。这些功能将从下一章开始详细讲解。
GitHub 的创始人之一 Chris Wanstrath 曾有个愿望，那就是能有一个 Git 仓库的托管服务让自己与朋友轻松分享代码，而这便成为了 GitHub 诞生的契机。不过，他也曾经表示：Git 仓库的托管服务是 2GitHub 项目的目标之一，这只是漫长路程上的一个点而已 。2http://www.slideshare.net/rubymeetup/inside-github-with-chris-wanstrathGitHub 的使用情况3
截至2013年12月，GitHub 托管的仓库数已超过1000万 。全世界每时每刻都有开发者在使用它。3https://github.com/features/hosting专栏：GitHub 与 Git 的区别4在此讲解一下 GitHub 与 Git 的区别。GitHub 与 Git 是完全不同的两个东西。本书中，自始至终都以 GitHub 和 Git 的方式区分描述。在 Git 中，开发者将源代码存入名叫“Git 仓库”的资料库中并加以使用。而 GitHub 则是在网络上提供 Git 仓库的一项服务。也就是说，GitHub 上公开的软件源代码全都由 Git 进行管理。理解 Git，是熟练运用 GitHub 的关键所在。Git 的相关知识，我们将在第2章中为您详细讲解。4http://git-scm.com1.2 使用 GitHub 会带来哪些变化
GitHub 的出现已使当今世界的软件开发现场发生了翻天覆地的变化。在这场可称之为革命的变革当中，中国也毫不例外地受到了影响。本章中，我们将简单介绍将 GitHub 导入日常开发后会带来哪些变化，供尚未正式使用 GitHub 的开发者们加以了解。协作形式变化
此前，用于辅助多人协同工作的软件层出不穷，然而它们中的大部分又一个个退出了历史的舞台。在这类软件中，群件（Groupware）和 CRM（Customer Relationship Management，顾客关系管理）等脱颖而出，被全世界的商业人士所用。您所在的公司想必也导入了这类软件。
但是，在以程序员为代表的软件开发者之间，一直都没有一个用来辅助多人协同编程的关键性软件。因此软件开发者们往往要将版本管理系统、BUG 跟踪系统、代码审查工具、邮件列表、IRC 等众多工具组合在一起，以实现多人协作。
开发者们已对这种软件开发协作模式司空见惯，然而 GitHub 的出 现为其带来了巨大变化。下面，我们就来介绍 GitHub 的几项功能。
……在开发者之间引发化学反应的 Pull Request
在 GitHub 这个聚集了世界各地软件开发者的地方，有个在过去绝对是无法想象的事正在飞速地进行着——素未谋面的开发者们隔着半个地球的距离共同开发软件。我们不妨称之为开发者之间的化学反应吧。这种事成为可能，都要归功于一个名为 Pull Request 的功能（图1.3）。图1.3 Pull Request 的页面
Pull Request 是指开发者在本地对源代码进行更改后，向 GitHub 中托管的 Git 仓库请求合并的功能。开发者可以在 Pull Request 上通过评论交流，例如“修正了 BUG，可以合并一下吗？”以及“我试着做了这样一个新功能，可以合并一下吗？”等。通过这个功能，开发者可以轻松更改源代码，并公开更改的细节，然后向仓库提交合并请求。而且，如果请求的更改与项目的初衷相违，也可以选择拒绝合并。
GitHub 的 Pull Request 不但能轻松查看源代码的前后差别，还可以对指定的一行代码进行评论（图1.4）。通过这一功能，开发者们可以针对具体的代码进行讨论，使代码审查的工作变得前所未有地惬意。图1.4 针对某行代码进行评论的实际截图
……对特定用户进行评论
方便和快捷并不是 Pull Request 的专利。任务管理和 BUG 报告可以通过 Issue 进行交互。如果想让特定用户来看，只要用“@ 用5户名”的格式书写，对方便会接到通知（Notifications），查看 Issue（图1.5）。由于也提供了 Wiki 功能，开发者可以轻松创建文档，进行公开、共享。Wiki 更新的历史记录也在 Git 中管理，可以让用户轻松更改。5通知的相关知识将在第5章中详细讲解。图1.5 写有“@ 用户名”的评论截图
……GitHub Flavored Markdown
在 GitHub 上，用户所有用文字输入的功能都可以用 GitHub Flavored Markdown（GFM）语法进行描述。这个语法可以让标记变得简单，以此写出的评论与文档也会更容易理解。只记住一个语法便6能在多种交流中使用，何乐而不为呢 ？它还有一个很特别的功能，那就是可以在评论中添加文字表情，使用户间的交流更加顺利。6第3章和第5章还会有 GFM 的相关讲解。
随着 GitHub 的普及，正在有越来越多的服务开始兼容 Markdown 语法。专栏：还可以这样写 !!GitHub 中可使用的描述方法并不止“@ 用户名”一种。输入“@ 组织名”可以让属于该 Organization（组织）的所7有成员收到通知 。输入“@ 组织名 / 团队”可以让该团队的所有成员收到通知。这就是同时向多人发送通知的方法。输入“# 编号”，会连接到该仓库所对应的 Issue 编号。输入“用户名 / 仓库名 # 编号”则可以连接到指定仓库所对应的 Issue 编号。只要按照这类特定格式书写便会自动创建链接。多加利用上述这些功能，可以让交流更有效率。7Organization 的详细内容将在第10章中进行讲解。能看到更多其他团队的软件
GitHub 快捷的环境为开发者带来的合作伙伴，并不只局限于自己团队内部。只要将感兴趣的仓库添加至 Watch 中，就可以在 News Feed 查 看该仓库的相关信息（图1.6）。图1.6 在 News Feed 中查看各仓库信息
比如，将全公司共用代码库的仓库添加到 Watch 中，便能在第一时间掌握最新版本的新功能或 BUG 修正的信息。当然，您也可以参与到讨论中去，积极地提出意见。如有必要，还可以通过 Pull Request 提交代码。
将隔壁团队正在开发的仓库添加到 Watch 中，就可以每天查看他们都在开发什么功能。一旦发现有用的功能或者库，可以立刻运用到自己的开发团队。如果能进一步交流，分割出共用的库，从而建立起新的仓库，便成了不同开发者团队间协作的美谈。与开源软件相同的开发模式
将 GitHub 运用到企业中，便会带来与开源软件开发相同的开发模式。已经熟悉开源软件开发的开发者不必专门去学习企业独自采用的工具，就可以直接加入到开发行列。
反过来说，只要在企业中运用 GitHub，即便是刚刚入职成为程序员的应届毕业生，也可以很快投身到开源软件开发的世界中。
也就是说，开源软件世界的软件开发与企业内的软件开发将不再有隔阂。在某些企业中，这两者的区别恐怕就是仓库公开与否的区别了。1.3 社会化编程
GitHub 这一服务，为开源世界带来了社会化编程的概念。这一概念影响了全世界众多程序员，说其是软件开发方法的一次革命都不为过。在这里，我们将详细解说社会化编程的概念。
您听过 SOCIAL CODING（以下称为社会化编程）这个词吗？如果没有，那么您见过图1.7的 LOGO 吗？
图1.7 GitHub 曾经的 LOGO8
这是 GitHub 曾经使用过的 LOGO。上面附带着 SOCIAL CODING 这一副标题。2013年4月起，GitHub 开始使用图1.8中的 LOGO。8https://github.com/
图1.8 GitHub 的新 LOGO
GitHub 这一服务创造了社会化编程的概念。随着 GitHub 的出现，软件开发者们才真正意义上拥有了源代码。世界上任何人都可以比从前更加容易地获得源代码，将其自由更改并加以公开。如今，世界众多程序员都在通过 GitHub 公开源代码，同时利用 GitHub 支持着自己日常的软件开发。
在 GitHub 出现之前，软件开发中只有一小部分人拥有更改源代码的权利，这个特权阶级掌握着开发的主导权。开发者在改写、发布源代码之外，往往需要花更多时间和精力去说服这个特权阶级。这导致了许多起初效率很高的流行软件越发保守化，最终被时代所抛弃。
但是，GitHub 的出现为软件开发者的世界带来了真正意义上的“民主”，让所有人都平等地拥有了更改源代码的权利。这在软件开发领域是一场巨大的革命。而革命领导者 GitHub 的口号便是“社会化编程”。
接下来，我们将深入理解引发这场革命的社会化编程，同时为您讲解其原动力——GitHub 这一服务的相关概要。GitHub 各个功能将在第3章之后为您详细介绍。1.4 为什么需要社会化编程
当今的 IT 业界已经没有了终身雇佣制，人才流动性日益增大。可以说，每个月我们都能在一些著名开发者的博客中看到这种现象：月末刚发布“辞职了”的消息，月初就又“入职了”。
那么，如果您是程序员的面试官，两者之间您会选择哪一位呢？● 能查看到以前所写代码的程序员 or 无法查看的程序员● 精通最新软件的程序员 or 不精通的程序员● 对语言或软件差异带来的不同文化有所理解的程序员 or 不理解
的 程序员
为了不成为后一种程序员，理解社会化编程和 GitHub 至关重要。不要闭目塞听，要接触不同的文化
在工作中接触非公开代码的职业程序员们，更应该接触世界上的不同文化，拓展见闻。如果只在公司这一封闭的小世界中敲代码，往往在不知不觉间，手中的技术就变得陈腐不堪了。
放眼世界，注意那些日新月异的源代码、技术、设计以及文化，会对自己编写的源代码及成果带来巨大影响。笔者自身也曾在知名框架的实现中受到启发，良好地实现了公司内部开发的软件。会写代码的程序员更受青睐
在软件开发行业中，Web 业界的变化尤其激烈，能实际编写源代码的程序员大受青睐。
在过去，程序员只需有简单的编程经验，用人单位更重视其人品、协调性、管理能力。但如今，能踏踏实实编写出代码的职业程序员反而更受欢迎。这是由于近年来随着技术的不断发展，开发一项服务需要用到多种编程语言和技术，以求兼容多种硬件设备。在这种背景下，判断一个求职者能否编写项目所需的源代码，最切实可行的办法就是看他实际写出的东西。
如今，GitHub 的出现已经让所有人平等拥有公开源代码的权利。看看 Facebook 或 Twitter 能了解一个人的品性，而看看 GitHub 就能了解一个程序员的实力。
今后，进行社会化编程的程序员会越来越多，从而成为一种普遍现象。在不远的将来，应聘的成功与否将取决于您曾经编写过的代码。因此，面向全世界的代码公开必将越发重要。以编写代码为生的职业程序员们，更应该进行社会化编程。GitHub 最大的特征是“面向人”
这里讲解一下 GitHub 与单纯的仓库托管服务的不同之处，在笔者看来这是一个重点问题。
GitHub 与以往的仓库托管服务最大的不同点，就在于它以人为中心。
以往的仓库托管服务都是以项目为中心，每个项目就是一个信息封闭的世界。虽然能够知道一个仓库的管理者是谁，但这个管理者还在做哪些事，我们就不得而知了。
GitHub 除项目之外，还可以把注意力集中到人身上。我们不但能阅览一个人公开的所有源代码，只要查看其控制面板中的 News Feed，还能知道他对哪些仓库感兴趣，什么时候做过提交等。一个9人在 GitHub 进行的开发是一目了然的 。9控制面板的相关知识将在第5章中进行详细说明。
您可以将注意力聚焦到感兴趣的人身上。他既可以是您崇拜已久的超级黑客，也可以是同校同学或公司的同事。
能同时关注人与代码，是 GitHub 为我们带来的一个新的世界。1.5 GitHub 提供的主要功能
在 GitHub 上，有许多帮助开发者高效输出优质代码的功能。这里，我们就简单地为您说明这些功能。Git 仓库
一般情况下，我们可以免费建立任意个 GitHub 提供的 Git 仓库。但如果需要建立只对特定人物或只对自己公开的私有仓库，则需10要依照套餐类型 支付每月最低7美元的使用费。10https://github.com/plansOrganization
通常来说，个人使用时只要使用个人账户就足够了，但如果是公司，建议使用 Organization 账户。它的优点在于可以统一管理账户和权限，还能统一支付一些费用。
如果只使用公开仓库，是可以免费创建 Organization 账户的。因此，如果是以交流群或 IT 小团体的形式进行软件开发时不妨试一试。组织或企业使用 GitHub 时需注意的地方将在第10章进行详细讲解。Issue
Issue 功能，是将一个任务或问题分配给一个 Issue 进行追踪和管理的功能。可以像 BUG 管理系统或 TiDD（Ticket-driven Development）的 Ticket 一样使用。在 GitHub 上，每当进行我们即将讲解的 Pull Request，都会同时创建一个 Issue。
每一个功能更改或修正都对应一个 Issue，讨论或修正都以这个 Issue 为中心进行。只要查看 Issue，就能知道和这个更改相关的一切信息，并以此进行管理。
在 Git 的提交信息中写上 Issue 的 ID（例如“#7”），GitHub 就会自动生成从 Issue 到对应提交的链接。另外，只要按照特定的格式描述提交信息，还可以关闭 Issue。这是一个非常方便的功能，请务必实践一下。详细内容将在第5章中为您讲解。Wiki
通过 Wiki 功能，任何人都能随时对一篇文章进行更改并保存，因此可以多人共同完成一篇文章。该功能常用在开发文档或手册的编写中。语法方面，可以通过第5章讲解的 GFM 语法进行书写。
Wiki 页也是作为 Git 仓库进行管理的，改版的历史记录会被切实保存下来，使用者可以放心改写。由于其支持克隆至本地进行编辑，所以程序员使用时可以不必开启浏览器。Pull Request
开发者向 GitHub 的仓库推送更改或功能添加后，可以通过 Pull Request 功能向别人的仓库提出申请，请求对方合并。
Pull Request 送出 后，目标仓库的管理者等人将能够查看 Pull Request 的内容及其中包含的代码更改。
同时，GitHub 还提供了对 Pull Request 和源代码前后差别进行讨论的功能。通过此功能，可以以行为单位对源代码添加评论，让程序员之间高效地交流。
详细内容及实际发送 Pull Request 的流程将在第6章中进行讲解。专栏：GitHub 上受到瞩目的软件在这里为各位介绍几个正在 GitHub 上开发的软件（表 a）（截至2013年12月）。想必其中很多软件大家都用过或者听过。11另外，在 GitHub 上可以随时查看当前备受瞩目的软件 。表 a GitHub 上正在开发的知名软件名称解说GitHub 的 URLRub在 Ruby 中使用的一种代表性的开https://github.com/y on Rails源 Web 框架rails/railsNod最近在 JavaScript 界大受欢迎的平https://github.com/e台。又名 Node.jsjoyent/nodejQue当今所有领域都在应用的 https://github.com/ryJavaScript 库jquery/jquerySym通过 PHP 编写的全栈式 Web 框架https://github.com/fony2symfony/symfonyBoot可以做出 Twitter 那种界面的组件集https://github.com/straptwitter/bootstrap11https://github.com/trending1.6 小结
本章就实现了社会化编程的 GitHub 进行了讲解。各部分的详细解说将在随后的章中进行。参考资料
如果要更加深入理解社会化编程的概念，建议参考松田明先生的资料（表1.1）。撰写本章时笔者就参考了这些资料。12
表1.1 参考资料 12三份资料的原标题依次为『たのしい Rails』『オブジェクト指向ソーシャルコーディングスクリプト言語 Ruby』『ソーシャルコーディングの世界』。——译者注标题URL轻松 Railshttp://www.slideshare.net/a_matsuda/rails-development-that-doesnt-hurt面向对象社会化编程https://speakerdeck.com/a_matsuda/object-oriented-脚本语言 Rubysocial-coding-scripting-language-ruby社会化编程的世界https://speakerdeck.com/u/a_matsuda/p/social-coding▶▶第2章Git的导入
Git 仓库管理功能是 GitHub 的核心。因此，使用 GitHub 之前必须先掌握 Git 的相关知识，同时本地的设备还要安装 Git 的环境。本章我们将为大家讲解使用 Git 所需的知识及各种设置。2.1 诞生背景
Git 属于分散型版本管理系统，是为版本管理而设计的软件。
Linux 的创始人 Linus Torvalds 在2005年开发了 Git 的原型程序。当时，由于在 Linux 内核开发中使用的既有版本管理系统的开发方许可证发生了变更，为了更换新的版本管理系统，Torvalds 开发了 Git。
Linux 内核的更新速度在全世界也算首屈一指。因此，势必需要一个功能强、性能高的版本管理系统来提高开发速度。
在当时的开源环境下，虽然已经有数款版本管理软件被开发出来，但功能和性能都差强人意。加之 Git 是由 Linus Torvalds 亲自着手开发的，可以说在功能与性能方面无可挑剔。程序员们愿意接受 Git，很大 程度上取决于这个背景。1
笔者在从 Subversion 改用 Git 时，也对其强大的功能和性能感到震惊。Git 功能多到夸张，让人觉得至今都没能彻底掌握它。同时，它大幅削减了笔者花在版本管理系统上的时间，现在如果没有 Git，软件开发恐怕会是一件非常痛苦的事情。1http://subversion.apache.org/
在发布之初，Git 由于其艰涩难懂，只有部分黑客愿意使用。但随着众多开发者的共同努力，现在它已被全世界的程序员们所采用。2.2 什么是版本管理
版本管理就是管理更新的历史记录。它为我们提供了一些在软件开发过程中必不可少的功能，例如记录一款软件添加或更改源代码的过程，回滚到特定阶段，恢复误删除的文件等。
在 Git 出现以前，人们普遍采用 Subversion 等集中型版本管理系统，而现在 Git 已经成为了主流。由于 GitHub 的普及，想必世界上使用 Git 的人会越来越多。因此要学习版本管理的各位，建议您选择 Git。集中型与分散型
刚才我们提到版本管理系统分为 Subversion 这类集中型的与 Git 这类分散型的，下面就为各位简单说明一下二者的不同点。
……集中型
以 Subversion 为代表的集中型，会如图2.1所示将仓库集中存放在服务器之中，所以只存在一个仓库。这就是为什么这种版本管理系统会被称作集中型。
图2.1 集中型
集中型将所有数据集中存放在服务器当中，有便于管理的优点。但是一旦开发者所处的环境不能连接服务器，就无法获取最新的源代码，开发也就几乎无法进行。服务器宕机时也是同样的道理，而且万一服务器故障导致数据消失，恐怕开发者就再也见不到最新的源代码了。
……分散型
图2.2是以 Git 为代表的分散型的示意图。如图中所示，GitHub 将仓库 Fork 给了每一个用户。Fork 就是将 GitHub 的某个特定仓库复制到自己的账户下。Fork 出的仓库与原仓库是两个不同的仓库，开发者可以随意编辑。
图2.2 分散型
如图所示，分散型拥有多个仓库，相对而言稍显复杂。不过，由于本地的开发环境中就有仓库，所以开发者不必连接远程仓库就可以进行开发。
图中只显示了一般的使用流程。实际上，所有仓库之间都可以进行 push 和 pull。即便不通过 GitHub，开发者 A 也可以直接向开发者 B 的仓库进行 push 或 pull。因此在使用前如果不事先制定规范，初学者往往会搞不清最新的源代码保存在哪里，导致开发失去控制。不过不用担心，只要各位随着本书的讲解亲自动手尝试，想掌握要领并不是一件难事。集中型与分散型哪个更好
要说集中型与分散型哪个更好，其实双方都各有优缺点，需要看具体情况而定。不过，随着 Git 与 GitHub 的普及，今后使用分散型的开发者将会占绝大多数。只要规则制定得当，分散型同样能像集中型那样进行管理。
有些人在学习版本管理的相关知识时，认为该从相对简单的集中型入手，再循序渐进学习分散型。但笔者认为，今后用到集中型的机会很少，所以不必特地绕这个弯路。
同样，建议想给团队导入版本管理系统的读者选择 GitHub 与 Git。如果软件开发进行到一半再从集中型转为分散型，不但需要支付高额的费用，还要让开发者花费大量的精力与金钱去重新学习。考虑到今后的各种机遇与挑战，从一开始就选择分散型，必定是各位成功路上的关键一步。
只要脑中掌握了多个仓库并存的概念，学习分散型并不是什么难事。而且对于刚刚接触这方面知识的人来说，由于没有先入为主的干扰，应该很容易接受这一概念。2.3 安装
接下来就让我们在本地环境中实际安装 Git，进行各种设置。Mac 与 Linux
最近的 Mac 中都预装了 Git。而各版本的 Linux 中也都以软件包（Package）的形式提供给用户了，所以各位可以直接使用。关于这两个环境特有的详细安装方法，由于篇幅关系恕不赘述。Windows2
在 Windows 环境中，最简单快捷的方法是使用 msysGit 。请按照 Downloads 的向导下载安装包。本书使用的版本是 Git-1.8.4-preview20130916.exe。2http://msysgit.github.io/
安装包下载完毕后，只要双击运行，按照向导一步步安装即可。下面我们对安装时的设定进行讲解。
……组件的选择
在图2.3的页面中选择需要的组件。由于所有必要组件都已默认勾选，大可直接进入下一步。图2.3 组件的选择
……设置环境变量
在图2.4的页面中，可以设置调用 Git 的环境变量。本书的讲解只会用到 msysGit 中附属的 Git Bash 命令提示符，所以请选择最上面的 Use Git Bash only，然后进行下一步。图2.4 环境变量的设置
……换行符的处理
在图2.5所示的页面中，选择换行符的相关设置。图2.5 换行符的转换
GitHub 中公开的代码大部分都是以 Mac 或 Linux 中的 LF（Line Feed）换行。然而，由于 Windows 中是以 CRLF（Carriage Return ＋ Line Feed）换行的，所以在非对应的编辑器中将不能正常显示。
Git 可以通过设置自动转换这些换行符。使用 Windows 环境的各位，请选择推荐的“Checkout Windows-style, commit Unix-style line endings”选项。换行符在签出时会自动转换为 CRLF，在提交时则会自动转换为 LF。
各位请注意以上这几点，配合当前使用的环境进行安装。
……Git Bash
顺利安装好 msysGit 之后，Git Bash 会作为一个应用程序添加进系统，接下来请启动它。双击之后，会弹出一个名为 Git Bash 的命令提示符（图2.6），它附属于 msysGit。如果各位是按照本书中介绍的流程进行安装，那么 git 命令就只能在 Git Bash 中使用，在 Windows 附属的命令提示符中则无法运行。图2.6 Git Bash 的运行页面
从名字中带有 Bash 就不难猜到，Git Bash 中照搬了许多 Bash 命令，习惯 Linux 的人用起来会感觉比 Windows 命令提示符更得心应手。借这个机会，不妨也熟悉一下 Windows 的 CLI（Command Line Interface，命令行界面）操作。本书所用的环境
本书中的示范操作，都是在 OS X 10.9.1上使用 Git 1.8.5.2进行。其他大部分环境也都提供了1.8.x 或1.7.x 版本的软件包，所以并不强求末尾的小版本号一致。不过还是建议各位尽量安装最新版的 Git。2.4 初始设置
下面我们对本地计算机里安装的 Git 进行设置。设置姓名和邮箱地址
首先来设置使用 Git 时的姓名和邮箱地址。名字请用英文输入。$ git config --global user.name "Firstname Lastname"$ git config --global user.email "your_email@example.com"
这个命令，会在“~/.gitconfig”中以如下形式输出设置文件。[user] name = Firstname Lastname email = your_email@example.com
想更改这些信息时，可以直接编辑这个设置文件。这里设置的姓名和邮箱地址会用在 Git 的提交日志中。由于在 GitHub 上公开仓库时，这里的姓名和邮箱地址也会随着提交日志一同被公开，所以请不要使用不 便公开的隐私信息。
在 GitHub 上公开代码后，前来参考的程序员可能来自世界任何地方，所以请不要使用汉字，尽量用英文进行描述。当然，如果您不想使用真名，完全可以使用网络上的昵称。提高命令输出的可读性
顺便一提，将 color.ui 设置为 auto 可以让命令的输出拥有更高的可读性。$ git config --global color.ui auto“~/.gitconfig”中会增加下面一行。[color] ui = auto
这样一来，各种命令的输出就会变得更容易分辨。2.5 小结
本章中，我们从 Git 诞生的背景说起，讲了版本管理系统中集中型和分散型的相关知识。然后还实际安装了 Git，并进行了初始设置。
如果您是一名开发者，今后使用 Git 的情况必然越来越多。请务必认真进行初始设置。▶▶第3章使用GitHub的前期准备
本章将为各位讲解使用 GitHub 前需要做的一些准备。3.1 使用前的准备创建账户1
首先让我们来创建 GitHub 账户。请打开创建账户的页面 。1https://github.com/join
我们会看到如图3.1所示的页面。在 Username 一栏中用英文和数字输入要创建的 ID，您的公开页面的 URL（http://github.com/○○）会用到这个 ID。其他项目也请按照页面要求输入。图3.1 账户创建页面
填写完所有项目后点击 Create an account，就能完成账户的创建。账户创建完成后会直接进入登录状态，用户可以立即开始使用 GitHub。登录状态下用户名会显示在页面的右上方。设置头像
在 GitHub 上随处可见的头像（账户独有的标识）是通过 2Gravatar服务显示的。使用过 WordPress 的读者可能对它有所了解。2http://cn.gravatar.com/
只要使用创建 GitHub 账户时注册的邮箱在 Gravatar 上设置头像，GitHub 的头像就会变成您设置好的样子。
头像并不是使用 GitHub 时的硬性要求，但如果为代码配上编码者的相貌或标识，会让人觉得安心，同时还可能让对方对您产生兴趣。毕竟我们要使用的是能将关注点聚集在人身上的 GitHub，所以建议各位积极地设置头像。设置 SSH Key
GitHub 上连接已有仓库时的认证，是通过使用了 SSH 的公开密钥认证方式进行的。现在让我们来创建公开密钥认证所需的 SSH Key，并将其添加至 GitHub。已经创建过的读者，请用现有的密钥进3行设置 。3本部分讲解参照了 GitHub 的帮助说明（https://help.github.com/articles/generating-ssh-keys）。
运行下面的命令创建 SSH Key。$ ssh-keygen -t rsa -C "your_email@example.com"Generating public/private rsa key pair.Enter file in which to save the key(/Users/your_user_directory/.ssh/id_rsa): 按回车键Enter passphrase (empty for no passphrase): 输入密码Enter same passphrase again: 再次输入密码“your_email@example.com”的部分请改成您在创建账户时用的邮箱地址。密码需要在认证时输入，请选择复杂度高并且容易记忆的组合。
输入密码后会出现以下结果。Your identification has been saved in /Users/your_user_directory/.ssh/id_rsa.Your public key has been saved in /Users/your_user_directory/.ssh/id_rsa.pub.The key fingerprint is:fingerprint值 your_email@example.comThe key's randomart image is:+--[ RSA 2048]----+| .+ + || = o O . | 略
id_rsa 文件是私有密钥，id_rsa.pub 是公开密钥。添加公开密钥
在 GitHub 中添加公开密钥，今后就可以用私有密钥进行认证了。
点击右上角的账户设定按钮（Account Settings），选择 SSH Keys 菜单之后，就会出现如图3.2的界面。点击Add SSH Key，会出现Title和Key两个输入框。在 Title 中输入适当的密钥名称。Key 部分请粘贴 id_rsa.pub 文件里的内容。id_rsa.pub 的内容可以用如下方法查看。$ cat ~/.ssh/id_rsa.pubssh-rsa 公开密钥的内容 your_email@example.com图3.2 SSH Keys
添加成功之后，创建账户时所用的邮箱会接到一封提示“公共密钥添加完成”的邮件。
完成以上设置后，就可以用手中的私人密钥与 GitHub 进行认证和通信了。让我们来实际试一试。$ ssh -T git@github.comThe authenticity of host 'github.com (207.97.227.239)' can't be established.RSA key fingerprint is fingerprint值 .Are you sure you want to continue connecting (yes/no)? 输入yes
出现如下结果即为成功。Hi hirocastest! You've successfully authenticated, but GitHub does not provide shell access.使用社区功能
既然说 GitHub 能够以人为焦 点，那么在创建账户后不妨试试 Follow（关注）别人。在用户信息页面的右上角点击如图3.3所示的按钮即可。图3.3 Follow 按钮
这样一来，您所 Follow 的用户的活动就会显示在您的控制面板页面中。您可以通过这种方法知道那个人在 GitHub 上都做了些什么。
对于仓库，也可以使用 Watch 功能获取最新的开发信息。如果您经常使用的某个软件正在 GitHub 上进行开发，不妨去 Watch 一下。
关于这部分的内容还将在第5章中详细讲解。3.2 实际动手使用创建仓库
实际创建一个公开的仓库。点击右上角工具栏里的 New repository（图3.4）图标，创建新的仓库。图3.4 新建仓库的按钮
……Repository name
参考图3.5，在 Repository name 栏中输入仓库的名称。这里我们输入 Hello-World。图3.5 新建仓库的页面
……Description
Description 栏中可以设置仓库的说明。这一栏不是必需项，可以留空。
……Public、Private
在这一栏可以选择 Public 还是 Private。这里我们选择 Public，创建公开仓库，仓库内的所有内容都会被公开。
选择 Private 可以创建非公开仓库，用户可以设置访问权限，但这项服务是收费的。
……Initialize this repository with a README
在 Initialize this repository with a README 选项上打 钩，随后 GitHub 会自动初始化仓库并设置 README 文件，让用户可以立刻 clone 这个仓库。如果想向 GitHub 添加手中已有的 Git 仓库，建议不要勾选，直接手动 push。
……Add .gitignore
下方左侧的下拉菜单非常方便，通过它可以在初始化时自动生4成 .gitignore 文件 。这个设定会帮我们把不需要在 Git 仓库中进行版本管理的文件记录在 .gitignore 文件中，省去了每次根据框架进行设置的麻烦。下拉菜单中包含了主要的语言及框架，选择今后将要使用的即可。由于本书中我们并不使用任何框架，所以不做选择。4该文件用来描述 Git 仓库中不需管理的文件与目录。
……Add a license
右侧的下拉菜单可以选择要添加的许可协议文件。如果这个仓库中包含的代码已经确定了许可协议，那么请在这里进行选择。随后将自动生成包含许可协议内容的 LICENSE 文件，用来表明该仓库内容的许可协议。
输入选择都完成后，点击 Create repository 按钮，完成仓库的创建。连接仓库
下面这个 URL 便是刚刚创建的仓库的页面。https://github.com/用户名/Hello-World
……README.md
README.md 在初始化时已经生成好了。README.md 文件的内容会自动显示在仓库的首页当中。因此，人们一般会在这个文件中标明本仓库所包含的软件的概要、使用流程、许可协议等信息。如果使用 Markdown 语法进行描述，还可以添加标记，提高可读性。
……GitHub Flavored Markdown
在 GitHub 上进行交流时用到的 Issue、评论、Wiki，都可以用 Markdown 语法表述，从而进行标记。准确地说应该是 GitHub Flavored Markdown（GFM）语法。该语法虽然是 GitHub 在 Markdown 语法基础上扩充而来的，但一般情况下只要按照原本的 Markdown 语法进行描述就可以。5
关于 Markdown 语法的解说，网上也有相关资料可查 。各位不妨一边参考一边实际尝试。5http://www.ituring.com.cn/article/775
使用 GitHub 后，很多文档都需要用 Markdown 来书写。也就是说，全世界有大量程序员都在使用 Markdown，因此掌握这种语法已经成为程序员的标准技能之一。请各位也务必学会 Markdown 语法。公开代码
……clone 已有仓库
接下来我们将尝试在已有仓库中添加代码并加以公开。首先将已6有仓库 clone 到身边的开发环境中。clone 时指定的路径请参考图3.6。6git 命令请参考第4章。图3.6 仓库的路径$ git clone git@github.com:hirocastest/Hello-World.gitCloning into 'Hello-World'...remote: Counting objects: 3, done.remote: Total 3 (delta 0), reused 0 (delta 0)Receiving objects: 100% (3/3), done. $ cd Hello-World
这里会要求输入 GitHub 上设置的公开密钥的密码。认证成功后，仓库便会被 clone 至仓库名后的目录中。将想要公开的代码提交至这个仓库再 push 到 GitHub 的仓库中，代码便会被公开。
……编写代码
这里我们编写一个 hello_world.php 文件，用来输出“Hello World!”。hello_world.php的内容
由于 hello_word.php 还没有添加至 Git 仓库，所以显示为 Untracked files。$ git status# On branch master# Untracked files:# (use "git add
……提交
将 hello_word.php 提交至仓库。这样一来，这个文件就进入了版本管理系统的管理之下。今后的更改管理都交由 Git 进行。$ git add hello_world.php$ git commit -m "Add hello world script by php"[master d23b909] Add hello world script by php 1 file changed, 3 insertions(+) create mode 100644 hello_world.php7
通过 git add命令将文件加入暂存区 ，再通过 git commit命令提交。7在 Index 数据结构中记录文件提交之前的状态。
添加成功后，可以通过 git log命令查看提交日志。$ git logcommit d23b909caad5d49a281480e6683ce3855087a5daAuthor: hirocastest
试读结束[说明：试读内容隐藏了图片]