大塚弘记
●没有机会和其他人互相交流代码，共享知识，相互学习、指正、改善 ●没有一个简单高效、能在一天之内添加多个功能的开发流程
GitHub的Pull Request不但能轻松查看源代码的前后差别，还可以对指定的一行代码进行评论（图1.4）。通过这一功能，开发者们可以针对具体的代码进行讨论，使代码审查的工作变得前所未有地惬意。
输入“@组织名”可以让属于该Organization（组织）的所有成员收到通知。输入“@团队名”可以让该团队的所有成员收到通知。这就是同时向多人发送通知的方法。
GitHub这一服务创造了社会化编程的概念。随着GitHub的出现，软件开发者们才真正意义上拥有了源代码。世界上任何人都可以比从前更加容易地获得源代码，将其自由更改并加以公开
●不要闭目塞听，要接触不同的文化
Issue功能，是将一个任务或问题分配给一个Issue进行追踪和管理的功能。可以像BUG管理系统或TiDD（Ticket-driven Development）的Ticket一样使用。在GitHub上，每当进行我们即将讲解的Pull Request，都会同时创建一个Issue。
Linux的创始人Linus Torvalds在2005年开发了Git的原型程序。当时，由于在Linux内核开发中使用的既有版本管理系统的开发方许可证发生了变更，为了更换新的版本管理系统，Torvalds开发了Git。
集中型将所有数据集中存放在服务器当中，有便于管理的优点。但是一旦开发者所处的环境不能连接服务器，就无法获取最新的源代码，开发也就几乎无法进行。服务器宕机时也是同样的道理，而且万一服务器故障导致数据消失，恐怕开发者就再也见不到最新的源代码了。
分散型 图2.2是以Git为代表的分散型的示意图。如图中所示，GitHub将仓库Fork给了每一个用户。Fork就是将GitHub的某个特定仓库复制到自己的账户下。Fork出的仓库与原仓库是两个不同的仓库，开发者可以随意编辑。
ssh -T [email protected]
要想让文件成为Git仓库的管理对象，就需要用git add命令将其加入暂存区（Stage或者Index）中。暂存区是提交之前的一个临时区域。 
显示文件的改动 如果想查看提交所带来的改动，可以加上-p参数，文件的前后差别就会显示在提交信息之后。  $ git log -p
切换回上一个分支 现在，我们再切换回feature-A分支。  $ git checkout - Switched to branch 'feature-A' 像上面这样用“-”（连字符）代替分支名，就可以切换至上一个分支。当然，将“-”替换成feature-A同样可以切换到feature-A分支。
git log --graph——以图表形式查看分支 用git log --graph命令进行查看的话，能很清楚地看到特性分支（feature-A）提交的内容已被合并。除此以外，特性分支的创建以及合并也都清楚明了。
执行git clone命令后我们会默认处于master分支下，同时系统会自动将origin设置成该远程仓库的标识符。也就是说，当前本地仓库的master分支与GitHub端远程仓库（origin）的master分支在内容上是完全相同的
例子中指定了origin/feature-D，就是说以名为origin的仓库（这里指GitHub端的仓库）的feature-D分支为来源，在本地仓库中创建feature-D分支。
首先我们来理解什么是Pull Request。Pull Request是自己修改源代码后，请求对方仓库采纳该修改时采取的一种行为。
Travis CI是一款免费服务，专门托管面向开源开发组织的CI（Continuous Integration，持续集成）。
让CI软件监视仓库，可以在开发者发送提交后立刻执行自动测试或构建。通过持续执行这样一个操作，可以检测出开发者意外发送的提交或无意的逻辑偏差，让代码保持在一定质量以上。
使用Jenkins对Pull Request进行自动测试时，需要用到GitHub pull request builder plugin插件。这个插件可以在Jenkins内部构建出Pull Request合并之后的状态并执行自动测试。由于其结果会自动发送到GitHub，所以能够让我们避免“Pull Request合并后出现了某些问题导致测试未通过”的情况。如此一来，Pull Request的合并就变得更加安全了。
实际开发中往往1天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。简单的开发流程能够让问题应对变得更加灵活。
要注意，没有进行过测试或者测试未通过的代码绝不可以合并到master分支。因此势必要用到持续集成等手段。
采用这一方式，开发者在查看远程仓库的分支列表时，能够对当前团队正在实施的任务一目了然。另外，由于分支名明确描述了工作内容，即便开发者需要先去做其他工作，回来时也能很快想起该分支的工作目标。
如果将3个工作分为3次提交，那么每个差别就有了更清晰的含义。
Pull Request具有显示差别以及对单行代码插入评论的功能，开发者可以利用这些进行交流。另外，如果希望得到特定开发者的反馈或建议，可以在评论中加入“@用户名”，给该用户发送Notifications。对方注意到之后，照例都会以某种形式进行反馈。
●务必让其他开发者进行审查 一个分支的作业结束后，需要注明作业已完成，让其他开发者进行审查。找其他开发者看一看自己编写的代码，可以有效防止想当然的错误或者低级失误。审查时要选择没有参与编写的人，被指出有问题时，要积极进行修改。当然，这一切的大前提是该部分代码已经通过所有自动测试
审查之后如果认为可以与master分支合并，则需要明确地告知对方。按照GitHub的文化，这里会用到“:+1:”或“:shipit:”等表情（图9.5）。偶尔也会见到LGTM的字样，这是Looks good to me的简写。
让测试自动化 如果每次部署到正式环境前都需要在测试环境中手动进行测试，那这一开发流程也就无从谈起了。所以必须让测试自动化，令其自动检测是否有代码被意外破坏，以及是否出现BUG。
编写测试代码，通过全部测试 每一名开发者都必须编写测试代码。成品代码的Pull Request中如果不包含测试代码，是不可以合并至master分支中的。只有包含测试代码并且通过了所有测试的成品代码才可以被合并至master分支。
开发时间越长或者代码量越大，代码审查时的成本就越高。过长的开发时间让审查者难以了解开发该功能时的背景，过大的代码量会让审查者难以阅读到代码的每个细节。这样一来BUG更容易出现，久而久之整个团队的代码审查都会漏洞频出。
尽量缩小Pull Request的体积，保证每几小时至几天向master分支发送一次Pull Request，通过多次合并来实现一个功能。这样一来不但能有一个很好的开发节奏，软件的成长过程也能够更加安全可靠。
●开发流程以部署为中心 ●高速源于简单
❶ 从开发版的分支（develop）创建工作分支（feature branches），进行功能的实现或修正 ❷ 工作分支（feature branches）的修改结束后，与开发版的分支（develop）进行合并 ❸ 重复上述❶和❷，不断实现功能直至可以发布
❹ 创建用于发布的分支（release branches），处理发布的各项工作 ❺ 发布工作完成后与master分支合并，打上版本标签（Tag）进行发布
❻ 如果发布的软件出现BUG，以打了标签的版本为基础进行修正（hotfixes） 整个流程看上去应该比较好理解。这一流程最大的亮点在于考虑了紧急的BUG应对措施。
master分支 master分支时常保持着软件可以正常运行的状态。由于要维持这一状态，所以不允许开发者直接对master分支的代码进行修改和提交。
程序员要以develop分支为起点新建feature分支，在feature分支中进行新功能的开发或者代码的修正。也就是说，develop分支维持着开发过程中的最新源代码，以便程序员创建feature分支进行自己的工作。
❶ 从develop分支创建feature分支 ❷ 在feature分支中实现目标功能 ❸ 通过GitHub向develop分支发送Pull Request ❹ 接受其他开发者审查后，将Pull Request合并至develop分支
●切换至develop分支 ●执行git pull（fetch & merge）
今后如果遇到什么问题，只要指定这个标签，就可以将软件回溯到相应版本。 ●
再push标签信息。  $ git push --tags
因此，hotfix分支都是以发布版本的标签或master分支为起点。借助hotfix分支，可以在不影响develop分支正常开发的情况下，由其他开发者处理成品的修正工作。
但是，由于在实际开发现场需要多人分工合作，这一开发流程往往会变得很复杂。建议各位把开发流程图放大并张贴在墙壁上，这样能够有效帮助团队成员理解流程内容。