之前所讲的都是“自娱自乐”，自己管理自己的项目。本篇主要是Git入门的尾声，也是最为精华的一部分，即利用Git进行版本控制，进行“团队协作开发”，也会介绍分支合并以及合并冲突时常见的处理方法。
五、团队协作流程
- 基本流程
(1) 创建一个分支
当你在开发一个项目的时候，一般在同一时刻你会同时展开多个想法，其中一些比较成熟了，另一些还是很初级的。有了分支就可以很好地来进行管理了。当你在项目中创建一个分支的时候，你可能就是正在搭建一个可以尝试新想法的环境。你在新分支上所做的修改不会影响到master分支，所以你能自由实验和提交修改。在被你的同事审核前，你的分支是不会被合并的。
(2) 在新分支上添加新版本
一旦你的分支创建好之后，就可以开始做些修改了。不论何时你添加，编辑或者删除一个文件，你就做一个版本，然后把他们添加到你的分支中。添加版本的过程就跟踪了你在一个功能分支上的工作进展。版本也为你的工作创建了一个透明的历史，其他人可以跟随着去理解你所做的工作以及为什么要这样做。没一个版本都有一条关联的版本信息，版本信息是一段描述，解释了为什么要做这样一个特定的修改。
(3) Pull Request
Pull Requst就是用来发起对你做的各个版本的讨论。因为Pull Request与底层的Git仓库代码是紧密相关的，任何人都能确切地看到你的Pull Request被接受后会有哪些代码合并起来。
在开发过程中的任意时刻，你都可以开启一个Pull Request。当你有很少或没有代码但想要分享一些截图或基本想法的时候，当你陷入困境需要帮助和建议的时候，或者当你准备好让他人审核你的工作的时候，就需要Pull Request。
(4) 讨论和代码审核
一旦开启了一个Pull Rquest，审核你修改的人或团队会来提出问题和评论。有可能是代码风格不符合项目规范，也或者是代码忘了单元测试，也可能是各方面都没问题。Pull Request就是为了鼓励这种类型的讨论而设计的。
根据别人对你所做版本的讨论和反馈，你也可以继续往你的分支上修改代码、推送代码等。
(5) 合并分支，然后部署
一旦你的Pull Request的所有代码经审核，通过了测试，就可以把你的代码合并到主分支上了。在把代码合并到Github上的仓库之前，如果你想测试代码或者是没有仓库的推送权限的话，你可以先在本地执行合并操作。
一旦合并之后，Pull Request会保留代码的历史修改记录。因为它们是可搜索的，它们让人可以回到过去去理解为什么做这个决定以及怎样做的决定。
2. 实际操作
这里以herdyouth的仓库为例作说明。按照以下步骤进行团队内部的合作开发。
(1) 给队友添加写权限
(2) 接收通知
这时youthherd的用户就会收到受邀的通知了。
(3) 指定队友在相应的分支上继续进行项目开发
可以看到被指定的队友youthherd只能在分支上进行Pull Request，而不能对Master进行操作。
(4) 发布之前的讨论、修改、审核
herdyouth在本地进行修改
修改之后做成版本pull到Github上，注意选择相应的分支
这时在herdyouth的Github上阔以看到Compare&pull request
点击之后，则可以进行相应的讨论
继续下拉则可以由颜色条明显的看到前后的变化
再来看看被授予了权限的youthherd===》
进入到相应仓库主页之后，New pull request
这里来选择比较的分支，然后进行讨论。可以一边讨论一边修改代码(在自己本地的相应分支上修改然后同步即可)，使用“:”添加表情。
这时候，herdyouth又可以通过来查看所有的pull request
=====》
讨论结束后其中任何一方就可以通过Merge pull request来合并分支到Master上了，当然得确保分支无冲突。
六、合并分支时的冲突解决
这里主要介绍一下，合并远端的分支以及解决冲突问题。由于我实践的不是很深，所以这一块是看的理论，有问题的地方我在后面的实践中会继续更正的。
同步冲突：如果A和B修改了同一个地方，而且修改的不同，在做版本的时候就可能出现同步冲突，因此在做版本之前A和B必须先商量，手动解决冲突，然后再做成版本。冲突在代码中”<<<<<<<，=======，>>>>>>>”标记出不同分支的内容。HEAD 表示本地分支，Origin/master表示远端分支，======是分隔符，分割冲突的两个分支的冲突地方。
=》无聊分割线==》
过几天要着手蓝牙了，所以我想捋一捋之前所了解到的蓝牙知识，但是Github基础这一块还有最后一大点，即利用开源项目以及Githu的三套机制还没有介绍。我先占个位，免得排版断片了，到时候再补完整。
703
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
