GitFork工作流

一、Git分支类型

1.1 master分支

• master 为产品主分支，该分支为只读唯一分支，也是用于部署生产环境的分支，需确保master分支的稳定性。
• master 分支一般由release分支或hotfix分支合并，任何情况下都不应该直接修改master分支代码。
• 产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录，方便追溯。
• master 分支不可删除。

1.2 develop分支

• develop 为主开发分支，基于master分支创建，始终保持最新完成功能的代码以及bug修复后的代码。
• develop 分支为只读唯一分支，只能从其他分支合并，不可以直接在该分支做功能开发或bug修复。
• 一般开发新功能时，feature分支都是基于develop分支下创建的。
• develop 分支包含所有要发布到下一个release的代码。
• feature功能分支完成后, 开发人员需合并到develop分支(不推送远程)，需先将develop分支合并到feature，解决完冲突后再合并到develop分支。
• 当所有新功能开发完成后，开发人员并自测完成后，此时从develop拉取release分支，进行提测。
• release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
• develop 分支不可删。

1.3 feature分支

• feature 分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支。
• 分支命名: feature/ 开头的为新特性或新功能分支，建议的命名规则: feature/user_createtime_feature，例如：feature/ftd_20201018_alipay，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
• 新特性或新功能开发完成后，开发人员需合到develop分支。
• feature 分支可同时存在多个，用于团队中多个功能同时开发。
• feature 分支属于临时分支，功能完成后可选删除。

1.4 release分支

• release 分支为预上线分支，基于本次上线所有的feature分支合并到develop分支之后，从develop分支创建。
• 分支命名: release/ 开头的为预上线分支，建议的命名规则: release/version_publishtime，例如：release/v2.1.1_20201018，含义为：版本号v2.1.1计划于2020年10月18日时发布。
• release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以release分支代码为基准进行提测。测试过程中发现的bug在本分支进行修复，上线完成后需合并到develop/master分支并推送远程。
• release 分支属于临时分支，产品上线后可选删除。

1.5 hotfix分支

• hotfix 分支为线上bug修复分支或叫补丁分支，主要用于对线上的版本进行bug修复。
• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似，建议的命名规则: hotfix/user_createtime_hotfix，例如：hotfix/ftd_20201018_alipaybugfix，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付bug修复的分支。
• hotfix 分支用于线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。当问题修复完成后，需要合并到master分支和develop分支并推送远程。
• 所有hotfix分支的修改会进入到下一个release。
• hotfix 分支属于临时分支，bug修复上线后可选删除。

二、Fork工作流

• Fork 工作流是一种分布式工作流，充分利用了 Git 在分支和克隆上的优势。可以安全可靠地管理大团队的开发者，并能接受不信任贡献者的提交。像github和gitlab 线上服务就是使用这个工作流模式

• 每个成员都可以 fork 项目到自己的目录, 甚至还可以继续衍生出更多项目, 项目之间的通过 pull、push request 进行代码合并。 一个项目可以有多个上游项目, 也可以有多个下游项目, 它们指向形成一种图关系.

1.1 Fork原理

• Fork 其实不是一个新东西, 当我们在gitlab上点击Fork的时候, gitlab只是将项目克隆（git clone）到个人目录。

1.2 适用场景

• 适合开源项目。开源项目需要接受任何开发者的代码共享, 无需给他们正式的代码库的写权限
• 适合大型的，自发性的团队。 fork 工作流可以提供灵活的方式来安全协作

1.3 工作方式

1. Fork: 一般通过服务器页面进行Fork, 创建一个拥有所有权的拷贝
2. 克隆项目到本地, 新建功能分支, 提交自己的代码, 然后推送到远程版本库
3. 然后发起将功能分支 并到上游（upstream）项目的Merge Request请求;
4. 上游项目的所有者决定是否合并你的代码

1.4 代码检测

stream）项目的Merge Request请求;
4. 上游项目的所有者决定是否合并你的代码

1.4 代码检测

一般开源项目都会严格审验每个 提交，Gitlab支持在每个提交后，对他跑一些集成测试，进行一些讨论和 回顾。主要检测代码是否经过了测试、分支代码是否冲突