Git工作流指南 - av32575602
文档资料
目录：
1-什么是版本控制系统
2-工作流简介
3-集中式工作流
4-功能分支工作流
5-GitFlow工作流
小记：
初看差点放弃了，不过后面还是有干货的，可以和廖老师教程相辅相成
2018-11-8-厕所感悟一则：
联想到pt里的，我突然觉得，pt网站是不是就相当于，每个人都作为自己已下载资源的服务器，尽量24小时在线或者开机做种，以提供给他人下载所需资源。
------------------------------------------
一、什么是版本控制系统
------------------------------------------
二、工作流简介
2.1 集中式工作流-方面SVN迁移过来-个人（3-5人）
2.2 功能分支工作流-稍大团队（8-12人）
2.3 GitFlow工作流-实际开发中常用但会稍微简化-整个公司
2.4 Forking工作流-适合大型团队使用-跨国合作
Pull Requests-请求合并-面试常问的，注意一下
除了第一个，剩下三个都会用到
------------------------------------------
三、集中式工作流-适合小型团队
内含demo：
老师说，在GitHub新建仓库的时候，选了.gitignore和开源协议
还说不选开源协议会比较吃亏？？？
步骤：
初始化仓库-->所有人克隆仓库-->小明、小红开发功能-->小明提交-->小红提交但失败-->小红先pull再push
------------------------------------------
四、功能分支工作流
<这节还受益良多，以前理解得不太好的一些东西明白了>
通常不在master上开发，而是创建不同分支，如功能分支、bug分支等
以此来保证master里的代码不被污染
（当代码还有点问题但是又怕丢失的时候，不可以传到master里否则master里就有坏的代码了，这时可以先传到功能分支里，这个分支最终是要删除的，而且可以自己负责一个分支）
演示：
功能分支开发完成后用pull request请求有权限的人（组长之类）合并到master分支
组长有权限，可以选择merge该功能到哪个分支，或者不merge
------------------------------------------
五、GitFlow工作流-企业常用
GitFlow 工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。
发布分支：
维护分支：当有bug时
GitFlow流五大分支：
主干分支
热修复分支
预发布分支
开发分支
功能分支
一个demo：
开发环节
1-首先创建develop分支-由有权限的人
所有开发工作都在这个开发分支下完成
2-然后开发人员先pull后在develop分支基础上创建自己的功能分支
3-开发人员小明开发并推送后，可在GitHub里发起pull request
4-预发布人员小明在本地切换到develop分支，创建预发布分支
：预发布分支这个版本是提供给测试人员用的，测试人员把它pull下来做测试
5-测试完成，没有问题了，再从预发布分支下，向master分支发起pull request请求
发布环节
1-本地打标签，作为里程碑式的第一个发布版本
2-本地打好标签以后，推送到远程
后期修复bug
1-用户发现bug，在issue里提交一个
2-上线：checkout下，在标签1.0.0基础上创建新分支
（上一部分写到，自动生成的问题编号是#4，故hotfix分支命名为hotfix_0004对应 该问题）
3-在本地的hotfix_0004分支下，修复bug，提交并推送到远程库
4-开发人员觉得没有问题了，可以在GitHub里发起pull request
5-在本地master分支下，pull（得到补丁），并新建标签1.0.1-RELEASE然后push到远程（勾选包括标签）
6-开发完成后，把不需要的分支删掉：
GitFlow工作流简化：feature分支可以省略，其他都不能
