目录:
1-什么是版本控制系统
2-工做流简介
3-集中式工做流
4-功能分支工做流
5-GitFlow工做流git
小记:
初看差点放弃了,不事后面仍是有干货的,能够和廖老师教程相辅相成
2018-11-8-厕所感悟一则:
联想到pt里的 <伺服> ,我忽然以为,pt网站是否是就至关于 <分布式的服务器> ,每一个人都做为本身已下载资源的服务器,尽可能24小时在线或者开机作种,以提供给他人下载所需资源。
------------------------------------------
1、什么是版本控制系统



------------------------------------------
2、工做流简介
2.1 集中式工做流-方面SVN迁移过来-我的(3-5人)

2.2 功能分支工做流-稍大团队(8-12人)

2.3 GitFlow工做流-实际开发中经常使用但会稍微简化-整个公司

2.4 Forking工做流-适合大型团队使用-跨国合做

Pull Requests-请求合并-面试常问的,注意一下
除了第一个,剩下三个都会用到github

------------------------------------------
3、集中式工做流-适合小型团队
内含demo:
老师说,在GitHub新建仓库的时候,选了.gitignore和开源协议
还说不选开源协议会比较吃亏???面试


步骤:
初始化仓库-->全部人克隆仓库-->小明、小红开发功能-->小明提交-->小红提交但失败-->小红先pull再push服务器


------------------------------------------
4、功能分支工做流
<这节还受益良多,之前理解得不太好的一些东西明白了>
一般不在master上开发,而是建立不一样分支,如功能分支、bug分支等
以此来保证master里的代码不被污染
(当代码还有点问题可是又怕丢失的时候,不能够传到master里不然master里就有坏的代码了,这时能够先传到功能分支里,这个分支最终是要删除的,并且能够本身负责一个分支)框架
演示:
功能分支开发完成后用pull request请求有权限的人(组长之类)合并到master分支
组长有权限,能够选择merge该功能到哪一个分支,或者不merge分布式







------------------------------------------
5、GitFlow工做流-企业经常使用
GitFlow 工做流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工做流复杂几分,但提供了用于一个健壮的用于管理大型项目的框架。
发布分支:

维护分支:当有bug时

GitFlow流五大分支:
主干分支
热修复分支
预发布分支
开发分支
功能分支ide

一个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对应 该问题)
svn
3-在本地的hotfix_0004分支下,修复bug,提交并推送到远程库


4-开发人员以为没有问题了,能够在GitHub里发起pull request


5-在本地master分支下,pull(获得补丁),并新建标签1.0.1-RELEASE而后push到远程(勾选包括标签)




6-开发完成后,把不须要的分支删掉:



GitFlow工做流简化:feature分支能够省略,其余都不能

------------------------------------------
Forking工做流
大致操做和廖老师讲的一致
在实际开发中不怎么用
但加入开源社区,或者想作开源贡献时会用到
------------------------------------------
实际开发中经常使用的工做流:
一个是集中式,一个是GitFlow