一种适用于中小团队的 Git 工作流

1. 前端应用只有三种分支类型：主干分支、特性分支、发布分支。
2. 约定 master 为主干分支，代表当前生产环境最新代码，设为保护分支，只允提 MR 合并，不允许直接推送。
3. 开发一个需求前
   3.1. 每人从 master 分支新建自已的特性分支，命名规则 feature/YYYYMMDD-xxx，其中 YYYYMMDD 代表需求所属迭代要发布的日期，xxx 可以根据自已要做的功能特性以简短有意义的英文命名。如 feature/20201111-productBannerUpdate。
   3.2. TL、项目 Owner 或其他有权限的人，预先从 master 分支新建发布分支，命名规则 release/YYYYMMDD[-xx]，其中 YYYYMMDD 代表需求所属迭代要发布的日期。发布分支暂时设为保护分支，不允许随意合并。[-xx] 说明见 5.2。
4. 开发完成，需要部署开发/测试各环境时
   4.1 每人推送自已的特性分支到远程 Gitlab 仓库中。
   4.2 在 Gitlab 中发起 MR 请求，源分支为自已的特性分支，目标分支为 3.2 中建好的相应迭代的发布分支。
   4.3 TL 或项目 Owner 进行简单的代码 review，检查无问题后合并代码。
   4.4 TL 或项目 Owner 在 CI 系统各环境流水线中部署相应发布分支。
5. 需要发布生产环境时
   5.1 TL 或项目 Owner 再次确认本次迭代要上线的需求已是否合入相应发布分支中，如无问题，则在 CI 系统 UAT 或生产环境流水线中部署相应发布分支。发布成功后，将发布分支合并到 master 分支，并打 Tag。
   5.2 如果有本次迭代不需要上线的特性分支，则 TL 或项目 Owner 从 master 分支新建一个新的发布分支，命名规则为当前迭代的发布分支名末尾加上 -01，需要多次重复此步骤的就多次执行此步骤，结尾加 1 即可。确定如无问题，则在 CI 系统 UAT 或生产环境流水线中部署相应发布分支。发布成功后，将发布分支合并到 master 分支，并打 Tag。
   5.3 发布 Tag 应设为保护 Tag，不允许随意创建。
6. 需要修复生产环境问题时
   6.1 从 master 分支或相应 Tag 新建 hotfix 分支（本质上还是特性分支），命名规则 hotfix/xxx。
   6.2 修复问题后，直接发布 hotfix 分支到相应环境验证，无问题后直接发布生产环境，生产环境发布成功后，将该 hotfix 分支合并到 master 分支，并打 Tag。
7. 发布分支合并冲突解决策略
   7.1 有条件的应在 release 分支上解决冲突。
   7.2 如无 release 分支权限，应基于 release 分支拉一个临时分支解决冲突并合回 release 分支。注意：release 分支如有撤出发布的分支，应基于新的 release 分支重新执行该步骤（有条件的，应优先使用 7.1 的方式解决冲突）。
   7.3 不要使用 Gitlab 自带的在线解决冲突工具。

其它Tips

• 每人在开发过程中，各自的特性分支应随时合并 master 分支上生产环境最新代码。
• 发布分支应随时合并 master 分支上生产环境最新代码。
• 每人的特性分支应按照需求尽量原子化，做到可单独上线或临时不需要上线时不用再手工剔除代码。
  • 原子化的颗粒度由个人把控，接到一个需求可以拆成多个分支，也可以就一个分支，只要符合上述原则就行。
  • 在实际开发中，遇到大的项目可能会出现在开发阶段有依赖其他人的代码的，例如一些公共逻辑，这些公共逻辑应由单独一个特性分支维护。每人根据具体情况，合并到自已的特性分支，或自已再维护一个临时分支，以保持自已的特性分支的纯洁性。
• 为尽量避免合并冲突，各项目应分析代码库中多人频繁操作的文件，如路由配置文件、接口定义文件等，按模块进行拆分，避免多人同时改动同一个文件的情况出现。
• 前期人工操作多，且瓶颈在 TL 或项目 Owner 身上，最好工具化。
• 主要参考 AoneFlow 分支管理模型，参见 在阿里，我们如何管理代码分支？ 只适合 Web 这种生产环境只有一种最新业务形态的场景，手机 APP、私有化部署等 这种需要同时保留多个生产版本的场景并不适用。