团队协作中的Github操作
前言
再次使用Github做任务，hiahiahia~嗨森耶，不仅可以在用中学，还可以当做刻意训练，不荒废已经学过的东西。
昨天晓沐姐姐问我对Github的了解程度，好吧，我对Github的所有了解都在这里了（再现写下来的好处，不仅可以便于自己复习巩固，还可以让别人更直观的了解自己的水平），然后可爱的晓沐姐姐计划于晚上来给我说一下github在团队协同方面的操作使用。哈哈哈，我太幸运了，到处都是贵人……
在晓沐姐的两个小时耐心讲解下收获满满呢，比如：
- 我明白了Github的工作原理图
- 我知道了有三种合并分支的方式及他们的特点
- 我明白了除了Code之外的其他如Issues,Projects等的意义及作用
- 我知道了fork的对象是仓库的全部内容，而pull resquest的对象是各分支
- 我学会了建文件夹……
一、Github的工作原理
这是Github的工作原理图
如图所示，这是一张Github的工作原理图，每一种色彩的分别代表着不同的分支。从下往上看：
- 蓝色表示功能分支，负责开发某一功能的工作流。
- 橙色表示功能总汇分支，他里面是所有功能的汇总。
- 黄色表示测试分支，用于产品内测。
- 绿色表示发布分支，只用于发布产品，对外展示。
- 紫色表示bug修复分支，它是指已经发布的产品发现有bug时进行修复的分支。
举个栗子：
如果你们团队在做微信功能开发，程序员A负责语音功能开发，程序员B负责表情包功能开发，程序员C负责微信红包功能开发。那么ABC三人都是在蓝色的Feature分支上进行各自的工作，平行方向的每个箭头和圈圈是每次commit的结果，而上下箭头则是pull request的结果。
当他们觉得自己所负责的功能写的差不多了，就可以pull resquest到橙色的Develop分支了。
管理员D将程序员ABC推送过来的内容进行汇总，就可以pull request到黄色的Release分支进行测试，如果测试合格就可以pull resquest到绿色的Master分支发布了，如果不合格就修改至合格，然后再pull request到Master分支发布，同时pull request到橙色的总汇分支进行备份。
至此，一个合格的产品就上线了。
当然，不可能事事完美。当已经上线的产品被发现有bug时，紫色的Hotfix分支的作用就出来了，这时就需要将Master分支pull request 给Hotfix进行修复漏洞就好了。修复完成后重新pull request给Master发布，同时pull request给橙色的总汇备份。
二：3种合并方式及特点
不知道你有没有见到过这张图，我上次用的Github的时候就疑惑过这个，因为并不懂什么意思，他们说不用管下拉的东西，用默认的Create a merge commit就行了，然后就这样放下了。
今天听晓沐姐说才知道，原来这就是合并分支的三种方式，分别是Create a merge commit，Squash and merge和Rebase and merge。咱们依次都看一下：
1. 方式一：Create a merge commit.
它是最完整的一种合并方式。这种方式合并时不仅保留了所有的提交版本，还保留了所有的修改轨迹。
2. 方式二：Squash and merge.
如图所示，这种方式是最不完整的合并方式，既不保留历史版本，也不保留修改轨迹。
这种方式的好处是对于纯文字编辑者在修改错别字、病句等非关键性语句时，为简洁方便，推送时可以直接忽略版本和轨迹。
3. 方式三：Rebase and merge.
这种方式是前两者的中间值，它保留了提交版本，却不保留各版本的修改轨迹。
至于到底选择哪种方式，这就要看你所做的事情对历史版本和修改轨迹的需求啦~
三、菜单栏的意义及作用
其实我也不知道那些东西应该叫啥，就是Code,Issues,Projects那一栏，看图好了#_#
之前一直都是只使用Cord一栏，其他栏不知道干啥的，也没用到。今天终于知道啦哈哈~
-
Issues：公告栏，一个发通知的地方，相当于论坛，open时，成员可回复评论，当一个任务结束，即可关闭。
-
Projects：看板，类似于任务清单。看板是实现准时化生产的工具。（百度的）作用有：
- 传递信息，统一认识
- 帮助管理，防微杜渐
- 强势宜导，形成改善意识
- 褒优贬劣，营造竞争的氛围
-
wiki：资料库，在推进任务的过程中会用到的标准化文件资料都会放在wiki中。
四、涨姿势
-
原来新建文件夹的地方就是新建文件的地方，只要在名称后加一个“/”就好啦。
-
fork的对象是仓库的全部内容，而pull resquest的对象是各分支
