图灵社区的电子书没有采用专有客户 端，您可以在任意设备上，用自己喜 欢的浏览器和PDF阅读器进行阅读。
但您购买的电子书仅供您个人使用，
未经授权，不得进行传播。
我们愿意相信读者具有这样的良知和 觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对
该用户实施包括但不限于关闭该帐号
等维权措施，并可能追究法律责任。
图书在版编目（CIP）数据
GitHub入门与实践 / （日） 大塚弘记著；支鹏浩，
刘斌译. -- 北京：人民邮电出版社，2015.7 （图灵程序设计丛书）
ISBN 978-7-115-39409-5
Ⅰ. ①G… Ⅱ. ①大… ②支… ③刘… Ⅲ. ①软件工 具－程序设计 Ⅳ. ①TP311.56
中国版本图书馆CIP数据核字(2015)第112943号
内 容 提 要
本书从Git的基本知识和操作方法入手，详细介绍了GitHub的各种功能，GitHub 与其他工具或服务的集成，使用GitHub的开发流程以及如何将GitHub引入到企业中。
在讲解GitHub的代表功能 Pull Request 时，本书专门搭建了供各位读者实践的仓 库，邀请各位读者进行Pull Request并共同维护。
本书旨在指导各位读者如何在开发现场使用GitHub进行高效开发，适合所有 想要使用GitHub进行开发的程序员或团队阅读。
◆ 著 ［日］ 大塚弘记 译 支鹏浩 刘斌 责任编辑 乐 馨 执行编辑 高宇涵 责任印制 杨林杰
◆ 人民邮电出版社出版发行 北京市丰台区成寿寺路11号 邮编 100164 电子邮件 [email protected]
网址 http://www.ptpress.com.cn 北京 印刷
◆开本：880×1230 1/32 印张：8.75
字数：260千字 2015年7月第1 版
印数：1 - 4 000册 2015年7月北京第1次印刷 著作权合同登记号 图字：01-2015-1263号
定价：39.00元
读者服务热线：(010)51095186转600 印装质量热线：(010)81055316 反盗版热线：(010)81055315
广告经营许可证：京崇工商广字第0021号
● 译者序
“开源”一词在我国IT 界已经出现了不少年头，但“社会化编程”
想必没有多少人接触过。于是在阅读正文之前，容我越俎代庖替作者问 一个问题：各位在狭小的空间里呆上一段时间之后，再出门时是否有一 种豁然开朗的感觉？相信很多人的答案都是肯定的。对于对日外包出身 的我来说，“社会化编程”就给了我这种感觉。或许外包行业在IT 界只 是极端个例，但“让全世界码农看自己的代码”这种事，很多人恐怕想 都不敢想吧。
GitHub 正是这样一个平台，我们在这里可以与全世界的开源开发者 交流代码或心得。如果您对某款开源软件的源代码感兴趣，如果您想为 中意的软件出一份力，如果您自己编写了小程序却苦苦找不到人指点，如 果您想跟慕名已久的IT 界明星（俗称“大神”）聊上几句，那么 GitHub 欢迎您。
GitHub 的纯英文界面或许会令您望而却步，不过不用担心，本书秉 承了日系技术书刊一贯的“手把手教学”风格，作者用亲切的语言，简 明扼要的介绍，配以生动详实的示例为我们一步步讲解GitHub 的使用 方法，带我们在实践中学习GitHub。值得一提的是，本书配有一个供各 位实践的网站，请感兴趣的读者务必一试。俗话说“读万卷书不如行万 里路”，跟着作者一边实践一边阅读本书，相信各位会对这句话有一个 更深刻的体会。
有些读者可能要问了，代码是企业的财产，不能随便发到网上给别 人看，那GitHub 对工作又有什么意义呢？这一点作者自然考虑到了。
GitHub 面向社会化编程，我们所生活的是一个大社会，我们工作的企业 同样是一个小社会，虽然不能强行导入“社会化编程”，但其管理模式 仍然值得借鉴。所以如果您是企业的决策者，那么请在本书后半跟随作 者一起探讨企业导入社会化编程的利弊，说不定能为您所在的企业带来 新的利益。
《GitHub 实战入门》是国内比较少见的对 GitHub 及社会化编程进行
iv
译者序的博客或技术文档进行片面了解，难以把握其全貌。各位读完这本书后 相信能得到不少帮助。
最后，对另一位帮忙搭建本书相关网站的译者以及图灵文化的各位 编辑致以衷心的感谢，正是有了各位的共同努力，本书才得以出版。同 时感谢正在阅读本书的您，有了您的支持，本书才能发挥其价值。
支鹏浩 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 的开发者也读一读本章，您或许会发现一些 将来能用到的小技巧。
本书结构
vii
第 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 可以轻松管理日常的小代码片段。
本书的操作示例是在以下环境中进行的。
• 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
A 詳解 GitHub——Pull Request が織りなす効率的ソフトウェア開発，WEB+DB PRESS vol.69，技术评论社。——译者注
本书内容以敝社《WEB+DB PRESS》Vol.69 的特辑《详解 GitHub——使用 Pull
Request 打造高效率的软件开发》①为基础，进行大篇幅扩展与修正后作为图书出版。
● 目录
第1章 欢迎来到GitHub的世界
………11.1
…什么是 GitHub
…...2GitHub 公司与 octocat…...2
并不只是 Git 仓库的托管服务…...3
GitHub 的使用情况…...3
Column…专栏 ：GitHub 与 Git 的区别…...4
1.2
…使用 GitHub 会带来哪些变化
…...4协作形式变化…...4
在开发者之间引发化学反应的 Pull…Request…...5
对特定用户进行评论…...6
GitHub…Flavored…Markdown…...7
Column…专栏 ：还可以这样写 !!…...7
能看到更多其他团队的软件…...7
与开源软件相同的开发模式…...8
1.3
…社会化编程
…...91.4
…为什么需要社会化编程
…...10不要闭目塞听，要接触不同的文化…...10
会写代码的程序员更受青睐…...11
GitHub 最大的特征是“面向人”…...11
1.5
…GitHub 提供的主要功能
…...12Git 仓库…...12
Organization…...12
Issue…...13
Wiki…...13
Pull Request…...13
Column…专栏 ：GitHub 上受到瞩目的软件…...14
1.6
…小结
…...14x
目录参考资料…...14
第2章 Git的导入
……… 172.1
…诞生背景
…...182.2
…什么是版本管理
…...18集中型与分散型…...19
集中型…...19
分散型…...19
集中型与分散型哪个更好…...20
2.3
…安装
…...21Mac 与 Linux…...21
Windows…...21
组件的选择…...22
设置环境变量…...22
换行符的处理…...23
Git…Bash…...23
本书所用的环境…...24
2.4
…初始设置
…...24设置姓名和邮箱地址…...24
提高命令输出的可读性…...25
2.5
…小结
…...25第3章 使用GitHub的前期准备
……… 273.1
…使用前的准备
…...28创建账户…...28
设置头像…...29
设置 SSH Key…...29
添加公开密钥…...30
使用社区功能…...31
目录
xi
3.2
…实际动手使用
…...31创建仓库…...31
Repository…name…...32
Description…...32
Public、Private…...32
Initialize…this…repository…with…a…README…...32
Add….gitignore…...33
Add…a…license…...33
连接仓库…...33
README.md…...33
GitHub…Flavored…Markdown…...34
公开代码…...34
clone 已有仓库…...34
编写代码…...35
提交…...36
Column…专栏 ：公开时的许可协议…...37
进行 push…...37
3.3
…小结
…...38第4章 通过实际操作学习Git
… ……… 394.1
…基本操作
…...40git init——初始化仓库…...40
git status——查看仓库的状态…...40
git add——向暂存区中添加文件…...41
git commit——保存仓库的历史记录…...42
记述一行提交信息…...42
记述详细提交信息…...42
中止提交…...43
查看提交后的状态…...43
git log——查看提交日志…...43
只显示提交信息的第一行…...44
只显示指定目录、文件的日志…...44
显示文件的改动…...45
xii
目录git diff——查看更改前后的差别…...45
查看工作树和暂存区的差别…...45
查看工作树和最新提交的差别…...46
4.2
…分支的操作
…...47git branch——显示分支一览表…...48
git checkout -b——创建、切换分支…...48
切换到 feature-A 分支并进行提交…...48
切换到 master 分支…...49
切换回上一个分支…...50
特性分支…...50
主干分支…...51
git merge——合并分支…...51
git log --graph——以图表形式查看分支…...52
4.3
…更改提交的操作
…...53git reset——回溯历史版本…...53
回溯到创建 feature-A 分支前…...53
创建 fix-B 分支…...54
推进至 feature-A 分支合并后的状态...55
消除冲突…...56
查看冲突部分并将其解决…...57
提交解决后的结果…...57
git commit --amend——修改提交信息...58
git rebase -i——压缩历史…...59
创建 feature-C 分支…...59
修正拼写错误…...60
更改历史…...61
合并至 master 分支…...63
4.4
…推送至远程仓库
…...63git remote add——添加远程仓库…...64
git push——推送至远程仓库…...64
推送至 master 分支…...64
推送至 master 以外的分支…...65
4.5
…从远程仓库获取
…...65git clone——获取远程仓库…...65
目录
xiii
获取远程仓库…...65
获取远程的 feature-D 分支…...66
向本地的 feature-D 分支提交更改…...67
推送 feature-D 分支…...67
git pull——获取最新的远程仓库分支…...67
4.6
…帮助大家深入理解 Git 的资料
…...68Pro Git...68
LearnGitBranching…...69
tryGit…...69
4.7
…小结
…...70第5章 详细解说GitHub的功能
……… 715.1
…键盘快捷键
…...725.2
…工具栏
…...73关于 UI…...73
1 LOGO…...73
2 Notifications…...73
3 搜索窗口…...73
4 Explore…...73
5 Gist…...74
6 Blog…...74
7 Help…...74
8 头像、用户名…...74
9 Create…a…new...…...74
Account…settings…...75
Sign…out…...75
5.3
…控制面板
…...75关于 UI…...75
❶ News…Feed…...76
❷ Pull…Requests…...76
❸ Issues…...76
❹ Stars…...76
xiv
目录❻ Repositories…you…contribute…to…...76
❼ Your…Repositories…...76
5.4
…个人信息
…...77关于 UI…...77
1…用户信息…...77
2 Popular…Repositories…...78
3 Repositories…contributed…to…...78
4 Public…contributions…...78
5 Contribution…Activity…...78
6 Repositories…...78
7 Public…Activity…...79
5.5
…仓库
…...80关于 UI…...80
❶ 用户名（组织名）/ 仓库名…...80
❷ Watch/Star/Fork…...80
❸ Code…...81
❹ Issue…...81
❺ Pull…Requests…...81
❻ Wiki…...82
❼ Pulse…...82
❽ Graphs…...82
❾ Network…...82
❿ Settings…...82
⓫ SSH…clone…URL…...82
⓬ Clone…in…Desktop…...82
⓭ Download…ZIP…...83
a commits…...83
b branches…...83
c releases…...83
d contributors…...83
e Compare…&…review…...83
f branch…...83
g path…...84
h Fork…this…project…and…Create…a…new…file…...84
i files…...84
文件的相关操作…...84
Column…专栏 ：通过部分名称搜索文件…...85
目录
xv
查看差别…...85
查看分支间的差别…...85
查看与几天前的差别…...86
查看与指定日期之间的差别…...87
5.6
…Issue
…...87简洁且表现力丰富的描述方法…...88
语法高亮…...89
添加图片…...90
添加标签以便整理…...90
添加里程碑以便管理…...91
Column…专栏 ：了解贡献时的规则！…...92
Tasklist 语法…...92
通过提交信息操作 Issue…...93
在相关 Issue 中显示提交…...93
Close…Issue…...93
将特定的 Issue 转换为 Pull Request…...94
5.7
…Pull Request
…...94Column…专栏 ：获取 diff 格式与 patch 格式的文件…...96
Conversation...96
Column…专栏 ：引用评论…...96
Commits…...97
Column…专栏 ：在评论中应用表情…...98
Files Changed…...98
5.8
…Wiki
…...99Pages…...100
History...101
Column…专栏 ：在 Wiki 中显示侧边栏…...101
5.9
…Pulse
…...102active pull requests…...103
active issue…...103
commits…...104
Releases published…...104
xvi
目录5.10
…Graphs
…...105Contributors…...105
Commit Activity…...106
Code Frequency…...106
Punchcard…...108
5.11
…Network
…...1085.12
…Settings
…...109Options…...109
❶ Settings…...109
❷ Features…...110
❸ GitHub…Pages…...111
❹ Danger…Zone…...111
Collaborators…...111
Webhooks & Services…...112
Deploy Keys…...112
5.13
…Notifications
…...1125.14
…其他功能
…...114GitHub Pages…...114
GitHub Jobs…...114
GitHub Enterprise…...114
GitHub API…...115
5.15
…小结
…...115Column…专栏 ：在 Mac 的通知中心查看 GitHub 的 Notifications…...115
第6章 尝试Pull Request
……… 1176.1
…Pull Request 的概要
…...118什么是 Pull Request…...118
Pull Request 的流程…...118
6.2
…发送 Pull Request 前的准备
…...119查看要修正的源代码…...120
目录
xvii
Fork…...120
clone…...120
branch…...121
为何要在特性分支中进行作业…...121
确认分支…...121
创建特性分支…...121
添加代码…...122
提交修改…...122
创建远程分支…...123
6.3
…发送 Pull Request
…...1236.4
…让 Pull Request 更加有效的方法
…...126在开发过程中发送 Pull Request 进行讨论…...126
明确标出“正在开发过程中”…...127
不进行 Fork 直接从分支发送 Pull Request…...128
6.5
…仓库的维护
…...128仓库的 Fork 与 clone…...129
给原仓库设置名称…...129
获取最新数据…...130
6.6
…小结
…...130第7章 接收Pull Request
……… 1317.1
…采纳 Pull Request 的方法
…...1327.2
…采纳 Pull Request 前的准备
…...133代码审查…...133
查看图片的差别…...134
2-up…...134
Swipe…...135
Onion…Skin…...135
Difference…...136
在本地开发环境中反映 Pull Request 的内容…...136
xviii
目录获取发送方的远程仓库…...137
创建用于检查的分支…...138
合并…...138
删除分支…...139
Column…专栏 ：如何提升代码管理技术…...139
7.3
…采纳 Pull Request
…...139合并到主分支…...140
push 修改内容…...141
7.4
…小结
…...142Column…专栏 ：请协助我们共同创建互相学习的场所...142
第8章 与GitHub相互协作的工具及服务
……… 1438.1
…hub 命令
…...144概要…...144
安装…...144
安装…...145
确认运行情况…...145
设置别名…...145
实现 shell 上的功能补全…...146
~/.config/hub…...146
命令…...146
hub…clone…...146
hub…remote…add…...147
hub…fetch…...147
hub…cherry-pick…...147
hub…fork…...148
hub…pull-request…...148
hub…checkout…...148
hub…create…...149
hub…push…...149
hub…browse…...150
hub…compare…...150
Column…专栏 ：让 GitHub…Enterprise 支持 hub 命令…...151
目录
xix
8.2
…Travis CI
…...151 概要…...151 实际尝试…...152 编写配置文件…...152 检测配置文件是否有问题…...152 与 GitHub 集成…...153 将 Travis…CI 的结果添加至 README.md…...1558.3
…Coveralls
…...156 概要…...156 安装…...157 注册…...157 添加对象仓库…...158 编写配置文件…...158 添加 gem…...159 查看报告…...1608.4
…Gemnasium
…...1608.5
…Code Climate
…...1618.6
…Jenkins
…...162 概要…...162 安装…...164 创建 bot 账户…...165 bot 账户的权限设置…...165 对象为个人账户时…...165 对象为 Organization 账户时…...165 检查设置…...167 给 Jenkins 设置 SSH 密钥…...167 初次使用 Jenkins 时…...167 已经在使用 Jenkins 时…...168 GitHub pull request builder plugin 的安装…...169 Git plugin 的设置…...170 Github Pull Requests Builder 的设置…...170 Github…server…api…URL…...171xx
目录Admin…list…...172 job 的创建与设置…...172 GitHub…project…...172 源码管理…...172 构建触发器…...173 构建…...174 通知结果…...174 测试执行中的状态…...175 Failed…...175 All…is…well…...175 commit…status…...175 通过评论进行控制…...176 执行任务…...176 添加至 White…list…...176 重新执行任务…...176 变更指定评论…...177
8.7
…小结
…...177 Column…专栏 ：用 Coderwall 生成 GitHub 上的个人信息…...178第9章 使用GitHub的开发流程
……… 1799.1
…团队使用 GitHub 时的注意事项
…...180 一切从简…...180 项目管理工具与 GitHub 的区别…...180 项目管理工具与 GitHub 相异的原因…...181 不 Fork 仓库的方法…...1829.2
…GitHub Flow——以部署为中心的开发模式
…...1839.3
…GitHub Flow 的流程
…...184 随时部署，没有发布的概念…...184 进行新的作业时要从 master 分支创建新分支…...185 在新创建的分支中进行提交…...186 定期 push…...186 使用 Pull Request…...187目录
xxi
务必让其他开发者进行审查…...187 合并后立刻部署…...187
9.4
…实践 GitHub Flow 的前提条件
…...188 部署作业完全自动化…...188 使用部署工具…...189 通过 Web 界面进行部署的工具…...189 导入开发时的注意事项…...190 重视测试…...190 让测试自动化…...190 编写测试代码，通过全部测试…...190 维护测试代码…...1909.5
…模拟体验 GitHub Flow
…...191 Fizzbuzz 的说明…...191 添加新功能…...192 创建新的分支…...192 如果尚未 clone 仓库…...192 如果之前 clone 过仓库…...193 创建特性分支…...193 实现新功能…...194 创建 Pull Request…...196 接收反馈…...196 修正缩进…...197 添加测试…...199 培育 Pull Request…...202 Pull Request 被合并…...2029.6
…团队实践 GitHub Flow 时的几点建议
…...203 减小 Pull Request 的体积…...204 准备可供试运行的环境…...204 不要让 Pull Request 中有太多反馈…...205 不要积攒 Pull Request…...2069.7
…GitHub Flow 的小结
…...206xxii
目录便于理解的标准流程…...207 有时显得过于复杂…...209
9.9
…导入 Git Flow 前的准备
…...209 安装 git-flow…...209 Mac 下的安装…...209 Linux 下的安装…...210 确认运行状况…...210 仓库的初始设置…...210 创建仓库…...210 进行 git…flow 的初始设置…...211 在远程仓库中也创建 develop 分支…...2129.10
…模拟体验 Git Flow
…...212 master 分支与 develop 分支的区别…...213 master 分支…...213 develop 分支…...213 在 feature 中进行的工作…...213 创建分支…...214 在分支中进行作业…...215 发送 Pull Request…...216 通过代码审查提高代码质量…...217 更新本地的 develop 分支…...219 在 release 分支中进行的工作…...220 Column…专栏 ：设置默认分支…...220 创建分支…...221 分支内的工作…...222 进行发布与合并…...222 查看版本标签…...224 更新到远程仓库…...225 在 hotfix 分支中进行的工作...226 创建分支…...226 创建标签和进行发布…...228 从 hotfix 分支合并至 develop 分支…...2309.11
…Git Flow 的小结
…...232 Column…专栏 ：版本号的分配规则…...232目录
xxiii
第10章 将GitHub应用到企业
……… 23310.1
…将世界标准的开发环境引入企业现场
…...234 企业引入 GitHub 的好处…...234 使用 Organization…...235 确认 Github 的安全性…...235 注意维护时间…...235 查看故障信息…...23610.2
…GitHub Enterprise
…...237 概述…...238 引入的好处…...238 引入的弊端…...239 适合引入 GitHub Enterprise 的几种情况…...239 源代码不可外传…...239 Column…专栏 ：将 GitHub 的仓库作为 Subversion 仓库使用…...240 希望维护与故障时间可控…...24010.3
…能实现 Git 托管的软件
…...241 Column…专栏 ：Bitbucket…...24110.4
…小结
…...242附录A 支持GitHub的GUI客户端
……… 243A.1
…GitHub for Mac，GitHub for Windows
…...244A.2
…SourceTree
…...246附录B 通过Gist轻松实现代码共享
……… 247B.1
…Gist 的特点
…...248B.2
…创建 Gist
…...248 UI 讲解…...249xxiv
目录2 name…this…file...…...249 3 language…...250 4 ACE…Editor…...250 5 文件…...250 6 Add…another…File…...251 7 Create…Secret…Gist…...251 8 Create…Public…Gist…...251
B.3
…查看 Gist
…...252 Gist 的菜单…...252❶ Gist…Detail…...253
❷ Revisions…...253
❸ Download…Gist…...253
❹ Clone…this…gist…...253
❺ Embed…this…gist…...253
❻ Link…to…this…gist…...253 文件的菜单…...254
B.4
…Your Gists
…...254B.5
…小结
…...255欢迎来到GitHub的世界
第 1 章
2
第 1 章 欢迎来到 GitHub 的世界本章将为您讲解GitHub 是什么，以及为什么全世界的开发者都在 使用它。同时，还会带您一起考察GitHub 为开源软件世界带来了怎样 的变革。
1.1 什么是 GitHub
GitHub 是为开发者提供 Git 仓库的托管服务。这是一个让开发者与 朋友、同事、同学及陌生人共享代码的完美场所。
● GitHub 公司与 octocat
GitHub 公司总部位于美国旧金山，拥有一只不知是章鱼还是猫的吉 祥物octocat（图 1.1）。图 1.2 中是被改编成各种造型的 octocat 们A。
图 1.1 octocat
A http://octodex.github.com/
1.1 什么是 GitHub
3
图 1.2 octocats
● 并不只是 Git 仓库的托管服务
GitHub 除提供 Git 仓库的托管服务外，还为开发者或团队提供了一 系列功能，帮助其高效率、高品质地进行代码编写。这些功能将从下一 章开始详细讲解。
GitHub 的创始人之一 Chris Wanstrath 曾有个愿望，那就是能有一个 Git 仓库的托管服务让自己与朋友轻松分享代码，而这便成为了 GitHub 诞生的契机。不过，他也曾经表示：Git 仓库的托管服务是 GitHub 项目 的目标之一，这只是漫长路程上的一个点而已A。
● GitHub 的使用情况
截至2013 年 12 月，GitHub 托管的仓库数已超过 1000 万B。全世界 A http://www.slideshare.net/rubymeetup/inside-github-with-chris-wanstrath
4
第 1 章 欢迎来到 GitHub 的世界 每时每刻都有开发者在使用它。专栏：GitHub 与 Git 的区别
在此讲解一下 GitHub 与 Git注 a的区别。GitHub 与 Git 是完 全不同的两个东西。本书中，自始至终都以 GitHub 和 Git 的方 式区分描述。
在 Git 中，开发者将源代码存入名叫“Git 仓库”的资料库中 并加以使用。而 GitHub 则是在网络上提供 Git 仓库的一项服务。
也就是说，GitHub 上公开的软件源代码全都由 Git 进行管 理。理解 Git，是熟练运用 GitHub 的关键所在。Git 的相关知识，
我们将在第 2 章中为您详细讲解。
注a http://git-scm.com
1.2 使用 GitHub 会带来哪些变化
GitHub 的出现已使当今世界的软件开发现场发生了翻天覆地的变 化。在这场可称之为革命的变革当中，中国也毫不例外地受到了影响。
本章中，我们将简单介绍将GitHub 导入日常开发后会带来哪些变化，
供尚未正式使用GitHub 的开发者们加以了解。
● 协作形式变化 ●
此前，用于辅助多人协同工作的软件层出不穷，然而它们中的大部 分又一个个退出了历史的舞台。在这类软件中，群件（Groupware）和 CRM（Customer Relationship Management，顾客关系管理）等脱颖而出，
被全世界的商业人士所用。您所在的公司想必也导入了这类软件。
但是，在以程序员为代表的软件开发者之间，一直都没有一个用来 辅助多人协同编程的关键性软件。因此软件开发者们往往要将版本管理
Column
1.2 使用 GitHub 会带来哪些变化
5
系统、BUG 跟踪系统、代码审查工具、邮件列表、IRC 等众多工具组合 在一起，以实现多人协作。
开发者们已对这种软件开发协作模式司空见惯，然而GitHub 的出 现为其带来了巨大变化。下面，我们就来介绍GitHub 的几项功能。
在开发者之间引发化学反应的 Pull Request
在GitHub 这个聚集了世界各地软件开发者的地方，有个在过去绝 对是无法想象的事正在飞速地进行着——素未谋面的开发者们隔着半个 地球的距离共同开发软件。我们不妨称之为开发者之间的化学反应吧。
这种事成为可能，都要归功于一个名为Pull Request 的功能（图 1.3）。
图 1.3 Pull Request 的页面
含有数字 7 时显示 GitHub 已经实现。求审查。
缩进好像不太对。
没有关于本次实现的测试代码，请添加一份。
@yuria…感谢您的审查。
关于规范方面有个问题。
比如，在本次实现之前，数字 75 应该显示为 fizzbuzz。
但 在 本 次 实 现 后， 由 于 属 于“ 含 有 数 字 7” 的 范 畴， 就 会 显 示 成 GitHub。
Pull Request 是指开发者在本地对源代码进行更改后，向 GitHub 中 托管的Git 仓库请求合并的功能。开发者可以在 Pull Request 上通过评 论交流，例如“修正了BUG，可以合并一下吗？”以及“我试着做了这 样一个新功能，可以合并一下吗？”等。通过这个功能，开发者可以轻
6
第 1 章 欢迎来到 GitHub 的世界如果请求的更改与项目的初衷相违，也可以选择拒绝合并。
GitHub 的 Pull Request 不但能轻松查看源代码的前后差别，还可以 对指定的一行代码进行评论（图1.4）。通过这一功能，开发者们可以针 对具体的代码进行讨论，使代码审查的工作变得前所未有地惬意。
图 1.4 针对某行代码进行评论的实际截图
缩进好像不太对。
对特定用户进行评论
方便和快捷并不是Pull Request 的专利。任务管理和 BUG 报告可以 通过Issue 进行交互。如果想让特定用户来看，只要用“@ 用户名”的 格式书写，对方便会接到通知（Notifications）A，查看Issue（图 1.5）。由 于也提供了Wiki 功能，开发者可以轻松创建文档，进行公开、共享。
Wiki 更新的历史记录也在 Git 中管理，可以让用户轻松更改。
图 1.5 写有“@ 用户名”的评论截图
@yuria…感谢您的审查。
关于功能方面有个问题。
比如，在本次实现之前，数字 75 应该显示 fizzbuzz。
但在本次实现后，由于属于“含有数字 7”的范畴，会显示成 GitHub。
您有没有想过让它显示成 fizzbuzzGitHub 这种复合形式呢？
A 通知的相关知识将在第 5 章中详细讲解。
1.2 使用 GitHub 会带来哪些变化
7
GitHub Flavored Markdown
在GitHub 上， 用 户 所 有 用 文 字 输 入 的 功 能 都 可 以 用 GitHub Flavored Markdown（GFM）语法进行描述。这个语法可以让标记变得简 单，以此写出的评论与文档也会更容易理解。只记住一个语法便能在多 种交流中使用，何乐而不为呢A？它还有一个很特别的功能，那就是可 以在评论中添加文字表情，使用户间的交流更加顺利。
随着GitHub 的普及，正在有越来越多的服务开始兼容 Markdown 语法。
专栏：还可以这样写 !!
GitHub 中可使用的描述方法并不止“@ 用户名”一种。
输入“@ 组织名”可以让属于该 Organization（组织）的所 有成员收到通知注 a。输入“@ 组织名 / 团队”可以让该团队的所 有成员收到通知。这就是同时向多人发送通知的方法。
输入“# 编号”，会连接到该仓库所对应的 Issue 编号。输入
“用户名 / 仓库名 # 编号”则可以连接到指定仓库所对应的 Issue 编号。只要按照这类特定格式书写便会自动创建链接。
多加利用上述这些功能，可以让交流更有效率。
注a Organization 的详细内容将在第 10 章中进行讲解。
● 能看到更多其他团队的软件
GitHub 快捷的环境为开发者带来的合作伙伴，并不只局限于自己团 队内部。只要将感兴趣的仓库添加至Watch 中，就可以在 News Feed 查 看该仓库的相关信息（图1.6）。
Column
8
第 1 章 欢迎来到 GitHub 的世界 图 1.6 在 News Feed 中查看各仓库信息比如，将全公司共用代码库的仓库添加到Watch 中，便能在第一时间 掌握最新版本的新功能或BUG 修正的信息。当然，您也可以参与到讨论 中去，积极地提出意见。如有必要，还可以通过Pull Request 提交代码。
将隔壁团队正在开发的仓库添加到Watch 中，就可以每天查看他们 都在开发什么功能。一旦发现有用的功能或者库，可以立刻运用到自己 的开发团队。如果能进一步交流，分割出共用的库，从而建立起新的仓 库，便成了不同开发者团队间协作的美谈。
● 与开源软件相同的开发模式
将GitHub 运用到企业中，便会带来与开源软件开发相同的开发模 式。已经熟悉开源软件开发的开发者不必专门去学习企业独自采用的工 具，就可以直接加入到开发行列。
反过来说，只要在企业中运用GitHub，即便是刚刚入职成为程序员 的应届毕业生，也可以很快投身到开源软件开发的世界中。
也就是说，开源软件世界的软件开发与企业内的软件开发将不再有 隔阂。在某些企业中，这两者的区别恐怕就是仓库公开与否的区别了。
1.3 社会化编程
9
1.3 社会化编程
GitHub 这一服务，为开源世界带来了社会化编程的概念。这一概念 影响了全世界众多程序员，说其是软件开发方法的一次革命都不为过。
在这里，我们将详细解说社会化编程的概念。
您听过SOCIAL CODING（以下称为社会化编程）这个词吗？如果 没有，那么您见过图1.7 的 LOGO 吗？
这是GitHubA曾经使用过的LOGO。上面附带着 SOCIAL CODING 这一副标题。2013 年 4 月起，GitHub 开始使用图 1.8 中的 LOGO。
图 1.7 GitHub 曾经的 LOGO
图 1.8 GitHub 的新 LOGO
GitHub 这一服务创造了社会化编程的概念。随着 GitHub 的出现，
软件开发者们才真正意义上拥有了源代码。世界上任何人都可以比从前 更加容易地获得源代码，将其自由更改并加以公开。如今，世界众多程 序员都在通过GitHub 公开源代码，同时利用 GitHub 支持着自己日常的 软件开发。
在GitHub 出现之前，软件开发中只有一小部分人拥有更改源代码 的权利，这个特权阶级掌握着开发的主导权。开发者在改写、发布源代
10
第 1 章 欢迎来到 GitHub 的世界码之外，往往需要花更多时间和精力去说服这个特权阶级。这导致了许 多起初效率很高的流行软件越发保守化，最终被时代所抛弃。
但是，GitHub 的出现为软件开发者的世界带来了真正意义上的“民 主”，让所有人都平等地拥有了更改源代码的权利。这在软件开发领域 是一场巨大的革命。而革命领导者GitHub 的口号便是“社会化编程”。
接下来，我们将深入理解引发这场革命的社会化编程，同时为您讲 解其原动力——GitHub 这一服务的相关概要。GitHub 各个功能将在第 3 章之后为您详细介绍。
1.4 为什么需要社会化编程
当今的IT 业界已经没有了终身雇佣制，人才流动性日益增大。可 以说，每个月我们都能在一些著名开发者的博客中看到这种现象：月末 刚发布“辞职了”的消息，月初就又“入职了”。
那么，如果您是程序员的面试官，两者之间您会选择哪一位呢？
●能查看到以前所写代码的程序员or 无法查看的程序员
●精通最新软件的程序员or 不精通的程序员
● 对语言或软件差异带来的不同文化有所理解的程序员 or 不理解的 程序员
为了不成为后一种程序员，理解社会化编程和GitHub 至关重要。
● 不要闭目塞听，要接触不同的文化
在工作中接触非公开代码的职业程序员们，更应该接触世界上的不 同文化，拓展见闻。如果只在公司这一封闭的小世界中敲代码，往往在 不知不觉间，手中的技术就变得陈腐不堪了。
放眼世界，注意那些日新月异的源代码、技术、设计以及文化，会 对自己编写的源代码及成果带来巨大影响。笔者自身也曾在知名框架的
1.4 为什么需要社会化编程
11
实现中受到启发，良好地实现了公司内部开发的软件。● 会写代码的程序员更受青睐
在软件开发行业中，Web 业界的变化尤其激烈，能实际编写源代码 的程序员大受青睐。
在过去，程序员只需有简单的编程经验，用人单位更重视其人品、
协调性、管理能力。但如今，能踏踏实实编写出代码的职业程序员反而 更受欢迎。这是由于近年来随着技术的不断发展，开发一项服务需要用 到多种编程语言和技术，以求兼容多种硬件设备。在这种背景下，判断 一个求职者能否编写项目所需的源代码，最切实可行的办法就是看他实 际写出的东西。
如今，GitHub 的出现已经让所有人平等拥有公开源代码的权利。看 看Facebook 或 Twitter 能了解一个人的品性，而看看 GitHub 就能了解一 个程序员的实力。
今后，进行社会化编程的程序员会越来越多，从而成为一种普遍现 象。在不远的将来，应聘的成功与否将取决于您曾经编写过的代码。因 此，面向全世界的代码公开必将越发重要。以编写代码为生的职业程序 员们，更应该进行社会化编程。
● GitHub 最大的特征是“面向人”
这里讲解一下GitHub 与单纯的仓库托管服务的不同之处，在笔者 看来这是一个重点问题。
GitHub 与以往的仓库托管服务最大的不同点，就在于它以人为 中心。
以往的仓库托管服务都是以项目为中心，每个项目就是一个信息封 闭的世界。虽然能够知道一个仓库的管理者是谁，但这个管理者还在做 哪些事，我们就不得而知了。
GitHub 除项目之外，还可以把注意力集中到人身上。我们不但能阅
12
第 1 章 欢迎来到 GitHub 的世界能知道他对哪些仓库感兴趣，什么时候做过提交等。一个人在GitHub 进行的开发是一目了然的A。
您可以将注意力聚焦到感兴趣的人身上。他既可以是您崇拜已久的 超级黑客，也可以是同校同学或公司的同事。
能同时关注人与代码，是GitHub 为我们带来的一个新的世界。
1.5 GitHub 提供的主要功能
在GitHub 上，有许多帮助开发者高效输出优质代码的功能。这里，
我们就简单地为您说明这些功能。
● Git 仓库
一般情况下，我们可以免费建立任意个GitHub 提供的 Git 仓库。但 如果需要建立只对特定人物或只对自己公开的私有仓库，则需要依照套 餐类型B支付每月最低7 美元的使用费。
● Organization
通常来说，个人使用时只要使用个人账户就足够了，但如果是公 司，建议使用Organization 账户。它的优点在于可以统一管理账户和权 限，还能统一支付一些费用。
如果只使用公开仓库，是可以免费创建Organization 账户的。因此，
如果是以交流群或IT 小团体的形式进行软件开发时不妨试一试。组织 或企业使用GitHub 时需注意的地方将在第 10 章进行详细讲解。
A 控制面板的相关知识将在第 5 章中进行详细说明。
B https://github.com/plans
1.5 GitHub 提供的主要功能
13
● 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 和源代码前后差别进行讨论
14
第 1 章 欢迎来到 GitHub 的世界间高效地交流。
详细内容及实际发送Pull Request 的流程将在第 6 章中进行讲解。
专栏：GitHub 上受到瞩目的软件
在这里为各位介绍几个正在 GitHub 上开发的软件（表 a）
（截至 2013 年 12 月）。想必其中很多软件大家都用过或者听过。
另外，在 GitHub 上可以随时查看当前备受瞩目的软件注 a。 注a https://github.com/trending
表 a GitHub 上正在开发的知名软件
名称 解说 GitHub 的 URL
Ruby…on…
Rails
在 Ruby 中使用的一种代 表性的开源 Web 框架
https://github.com/rails/rails
Node 最近在 JavaScript 界大受
欢迎的平台。又名 Node.js
https://github.com/joyent/node
jQuery 当今所有领域都在应用的
JavaScript 库
https://github.com/jquery/jquery
Symfony2 通 过 PHP 编 写 的 全 栈 式
Web 框架
https://github.com/symfony/
symfony
Bootstrap 可 以 做 出 Twitter 那 种 界
面的组件集
https://github.com/twitter/
bootstrap
1.6 小结
本章就实现了社会化编程的GitHub 进行了讲解。各部分的详细解 说将在随后的章中进行。
● 参考资料
如果要更加深入理解社会化编程的概念，建议参考松田明先生的资 料（表1.1）。撰写本章时笔者就参考了这些资料。
Column
1.6 小结
15
表 1.1 参考资料A
标题 URL
轻松 Rails http://www.slideshare.net/a_matsuda/rails-development-
that-doesnt-hurt 面向对象社会化编程脚本
语言 Ruby
https://speakerdeck.com/a_matsuda/object-oriented- social-coding-scripting-language-ruby
社会化编程的世界 https://speakerdeck.com/u/a_matsuda/p/social-coding
A 三份资料的原标题依次为『たのしい Rails』『オブジェクト指向ソーシャルコー
Git的导入
第 2 章
18
第 2 章 Git 的导入Git 仓库管理功能是 GitHub 的核心。因此，使用 GitHub 之前必须 先掌握Git 的相关知识，同时本地的设备还要安装 Git 的环境。本章我 们将为大家讲解使用Git 所需的知识及各种设置。
2.1 诞生背景
Git 属于分散型版本管理系统，是为版本管理而设计的软件。
Linux 的创始人 Linus Torvalds 在 2005 年开发了 Git 的原型程序。
当时，由于在Linux 内核开发中使用的既有版本管理系统的开发方许可 证发生了变更，为了更换新的版本管理系统，Torvalds 开发了 Git。
Linux 内核的更新速度在全世界也算首屈一指。因此，势必需要一 个功能强、性能高的版本管理系统来提高开发速度。
在当时的开源环境下，虽然已经有数款版本管理软件被开发出来，
但功能和性能都差强人意。加之Git 是由 Linus Torvalds 亲自着手开发 的，可以说在功能与性能方面无可挑剔。程序员们愿意接受Git，很大 程度上取决于这个背景。
笔者在从SubversionA改用Git 时，也对其强大的功能和性能感到震 惊。Git 功能多到夸张，让人觉得至今都没能彻底掌握它。同时，它大 幅削减了笔者花在版本管理系统上的时间，现在如果没有Git，软件开 发恐怕会是一件非常痛苦的事情。
在发布之初，Git 由于其艰涩难懂，只有部分黑客愿意使用。但随 着众多开发者的共同努力，现在它已被全世界的程序员们所采用。
2.2 什么是版本管理
版本管理就是管理更新的历史记录。它为我们提供了一些在软件开
A http://subversion.apache.org/
2.2 什么是版本管理
19
发过程中必不可少的功能，例如记录一款软件添加或更改源代码的过 程，回滚到特定阶段，恢复误删除的文件等。
在Git 出现以前，人们普遍采用 Subversion 等集中型版本管理系统，
而现在Git 已经成为了主流。由于 GitHub 的普及，想必世界上使用 Git 的人会越来越多。因此要学习版本管理的各位，建议您选择Git。
● 集中型与分散型
刚才我们提到版本管理系统分为Subversion 这类集中型的与 Git 这 类分散型的，下面就为各位简单说明一下二者的不同点。
集中型
以Subversion 为代表的集中型，会如图 2.1 所示将仓库集中存放在 服务器之中，所以只存在一个仓库。这就是为什么这种版本管理系统会 被称作集中型。
集中型将所有数据集中存放在服务器当中，有便于管理的优点。但 是一旦开发者所处的环境不能连接服务器，就无法获取最新的源代码，
开发也就几乎无法进行。服务器宕机时也是同样的道理，而且万一服务 器故障导致数据消失，恐怕开发者就再也见不到最新的源代码了。
图 2.1 集中型
Subversion
开发者 A 开发者 B
commit checkout
commit checkout
分散型
图2.2 是以 Git 为代表的分散型的示意图。如图中所示，GitHub 将 仓库Fork 给了每一个用户。Fork 就是将 GitHub 的某个特定仓库复制到
20
第 2 章 Git 的导入随意编辑。
图 2.2 分散型
git git
git git
GitHub
pull pull
push push
Fork
开发者 A
Pull Request
开发者 B
如图所示，分散型拥有多个仓库，相对而言稍显复杂。不过，由于 本地的开发环境中就有仓库，所以开发者不必连接远程仓库就可以进行 开发。
图中只显示了一般的使用流程。实际上，所有仓库之间都可以进行 push 和 pull。即便不通过 GitHub，开发者 A 也可以直接向开发者 B 的 仓库进行push 或 pull。因此在使用前如果不事先制定规范，初学者往 往会搞不清最新的源代码保存在哪里，导致开发失去控制。不过不用 担心，只要各位随着本书的讲解亲自动手尝试，想掌握要领并不是一 件难事。
● 集中型与分散型哪个更好
要说集中型与分散型哪个更好，其实双方都各有优缺点，需要看具 体情况而定。不过，随着Git 与 GitHub 的普及，今后使用分散型的开发 者将会占绝大多数。只要规则制定得当，分散型同样能像集中型那样进 行管理。
有些人在学习版本管理的相关知识时，认为该从相对简单的集中型
2.3 安装
21
入手，再循序渐进学习分散型。但笔者认为，今后用到集中型的机会很 少，所以不必特地绕这个弯路。
同样，建议想给团队导入版本管理系统的读者选择GitHub 与 Git。
如果软件开发进行到一半再从集中型转为分散型，不但需要支付高额的 费用，还要让开发者花费大量的精力与金钱去重新学习。考虑到今后的 各种机遇与挑战，从一开始就选择分散型，必定是各位成功路上的关键 一步。
只要脑中掌握了多个仓库并存的概念，学习分散型并不是什么难 事。而且对于刚刚接触这方面知识的人来说，由于没有先入为主的干 扰，应该很容易接受这一概念。
2.3 安装
接下来就让我们在本地环境中实际安装Git，进行各种设置。
● Mac 与 Linux
最近的Mac 中都预装了 Git。而各版本的 Linux 中也都以软件包
（Package）的形式提供给用户了，所以各位可以直接使用。关于这两个 环境特有的详细安装方法，由于篇幅关系恕不赘述。
● Windows
在Windows 环境中，最简单快捷的方法是使用 msysGitA。请 按 照Downloads 的 向 导 下 载 安 装 包。 本 书 使 用 的 版 本 是 Git-1.8.4- preview20130916.exe。
安装包下载完毕后，只要双击运行，按照向导一步步安装即可。下 面我们对安装时的设定进行讲解。
22
第 2 章 Git 的导入组件的选择
在图2.3 的页面中选择需要的组件。由于所有必要组件都已默认勾 选，大可直接进入下一步。
设置环境变量
在图2.4 的页面中，可以设置调用 Git 的环境变量。本书的讲解只 会用到msysGit 中附属的 Git Bash 命令提示符，所以请选择最上面的 Use Git Bash only，然后进行下一步。
图 2.3 组件的选择
图 2.4 环境变量的设置
2.3 安装
23
换行符的处理
在图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。
图 2.5 换行符的转换
各位请注意以上这几点，配合当前使用的环境进行安装。
Git Bash
顺利安装好msysGit 之后，Git Bash 会作为一个应用程序添加进系 统，接下来请启动它。双击之后，会弹出一个名为Git Bash 的命令提示 符（图2.6），它附属于 msysGit。如果各位是按照本书中介绍的流程进 行安装，那么git 命令就只能在 Git Bash 中使用，在 Windows 附属的命 令提示符中则无法运行。
24
第 2 章 Git 的导入 图 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 "[email protected]"
这个命令，会在“~/.gitconfig”中以如下形式输出设置文件。
