背景
现在git创建，合并，发布，发布后处理，每个业务条线不一致，并且没有传承记录，为保证git统一使用，并保持一致，故有如下规则。
Git常用分支包括
master：项目主分支，有且仅有一个，除项目负责人外其他开发人员不得向 master 分支合并内容。
hotfix：紧急线上 bug 修复分支，紧急即需要立刻尽快去处理发布上线（自 master 拉取）, 直接进行测试及上线。
bugfix：非紧急上线的 bug 修复分支, 如非当天上线即使用 bugfix 进行命名（自 master 拉取） , 直接进行测试及上线。bugfix也可以没有，若对业务没有影响，随着需求分支一起上线。
release：作为提测及上线分支，release是发布正式版本之前（即合并到 master 分支之前），需要有一个预发布的版本进行测试。我们公司不要求很敏捷开发，故release分支承担develop能力（测试和回归）
develop：主开发分支，存有确定性的所有功能（上线和未上线）, 作为开发环境共有的部署分支。基于我们公司的需求数量，我develop没有加任何东西。
feature：功能开发分支，feature 是为了开发后续版本的功能。基于我们公司的现状，feature分支作为功能和开发分支。
介绍
1:每次开发需求，从master拉取feature分支，作为开发分支，此次需求开发人员在此分支上开发，自测。
2:提测之前，需要从master分支拉取新的release分支，需要上线的feature分支，合并到release分支。
3:release做为测试和回归测试的分支。
4:每次上线后，线上稳定后，再合并到master，并打tag。
5:合并到master后，需要从master重新merge到正在进行中的feature分支。
6:hotfix&bugfix从master拉取分支，进行开发测试上线，上线后打tag，然后需要从master重新merge到正在进行中的feature分支。
建议分支命名
hotfix：hotfix/{功能}，如 hotfix/providerLose。
bugfix：bugfix/{功能}_年月日，如 bugfix/pubMsg_20210701。
release：release/{功能}_年月日，如 release/pubMsg_20210701。
feature：feature/{功能}_年月日，如 feature/pubMsg_20210701。
或者大家按照现在各科室的命名方法进行命名
优点
- 结构化工作流：Git Flow提供清晰有序的工作流程，适用于需要显式版本控制和正式发布的项目。
- 代码隔离：每个功能在独立的分支上开发，确保工作的清晰分离。
- 版本管理：特性分支开发支持版本控制，并支持维护多个版本在运行。
缺点
-
复杂性：Git Flow引入了复杂性，由于多个长期存在的分支，这使得它对于较小的项目或采用持续交付实践的团队不太合适。
-
开销：管理和合并多个分支可能会减慢开发过程。
