GIT 分支的区别以及通用流程的理解

Git 分支的含义

Master分支：

职能：代表生产环境中当前运行的代码版本。它应该是稳定的，并且随时可部署。 规则：只从release分支或hotfix分支合并到master分支。确保master分支的改动都经过充分测试，且不直接在master分支上进行开发。

Release分支：

职能：用于准备即将发布的版本。在这个分支上，可以进行最后的测试、Bug修复、文档编写等准备工作。 规则：从master分支分支出来，准备好发布后，合并回master分支，并打上版本标签。同时，合并到develop分支（如果存在）以确保包含了最新的修复和更新。

Feature分支：

职能：用于新功能的开发。每个feature分支专注于开发一个特定的功能或改进，保持开发工作的隔离和聚焦。 规则：从master分支（或develop分支，如果遵循有develop分支的工作流）分支出来，开发完成并测试无误后，合并回master分支或develop分支。

Hotfix分支：

职能：用于紧急修复生产环境中的问题。hotfix分支允许团队快速修复生产环境的Bug，并尽快部署修复。 规则：从master分支分支出来，修复完成后，合并回master分支，并打上相应的版本标签。同样，为了保持代码的一致性，也需要合并回develop分支或当前的release分支。

通用理解

1. 每个版本开发开始, 我们会从 master 拉出需要新增功能的分支 (feature 分支)

2. 我们会基于 feature 分支开发新功能, 并定期从 master 分支拉取新代码, 防止冲突代码
3. 在 feature 开发完并充分测试后, 合入到 master 分支, 并从 master 拉出 realease 分支
4. 这已经在为发布上线做准备了, 我们在这个 release 分支上面进行进行 bug 修复 等上线前准备
5. 等到 realease 分支充分自测后就可以合并入 master, 打上标签, 表示这是要上线的代码了
6. 如果上线后有问题的, 基于 master 拉出 hotfix 分支, 进行线上问题修正测试, 然后同步合并到 master

阿里的 Azonflow

https://developer.aliyun.com/article/573549

规则一，开始工作前，从主干创建特性分支。

规则二，通过合并特性分支，形成发布分支。

规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。

有几点需要注意:

1. master 始终保持和线上环境一致的代码
2. feature 和 realease 都是由 master分支拉出
3. feature 开发完之后, 根据需要合入到不同的 realease 分支上比如 test / prod, 只合入需要上线的 feature
4. 等 realease 发布正式环境后, 将其与 master 分支合并。同时删除 realease 对应的 feature 分支

基于 fork 与否

你是自己 fork 一个仓库, 然后将远程仓库设置为主仓, 进行开发合并

还是直接在主仓上拉出一个分支进行直接提交, 开发。

这两者都是可以的, 没有优劣。只有权衡与选择。

都要做到及时的更新代码, 预防可能出现的冲突。

公司流程的理解

1. 部门拉取 feature 分支

2. 开发完之后合入部门的 develop 分支

3. 卡发完之后, 拉取部门 release 分支

以上暂时都在部门独立测试环境中

在 release 版本的前进中, 经过 qc 的充分测试可以, 搭车

将代码放到PaaS预测试环境环境充分测试, 发车测试时间由核心组统筹

充分完成后可以合并入 test 区的 realese 分支, 也就是项目的主要发布分支

经过 test / 预生产区的充分测试, 合并进入master 作为最终的发布版本

流程:

1. 项目伊始, 从 master 拉取部门的 develop 分支
2. 在部门 develop 分支基础上新建 feature 分支, 进行功能开发
3. 特性开发完成, 直接合并进入 develop 分支
4. 拉取部门的 release 分支
5. 经过部门独立验证环境充分测试后, 搭车进入平台测试环节
6. 经过充分平台, 满足合并进入主项目 release 分支的条件
7. 然后再主 release 分支上经过test 区,预生产的充分测试, 发布生产 最终合入到 master 分支, 打上标签