Git版本管理规范(Git Flow)

Posted 2023-03-09

参考技术A

需求是开发的起点， 先有需求再有功能分支或者补丁分支 。完成开发后，该分支就合并到常驻分支，然后被删除.

完成开发，该分支会合并到 develop 或 master 中，合并完成之后该分支的生命周期结束，删除该分支 。

* 是取通配符的意思，用来代替不同的命名

看图说话：

使用注意：

开发环境的稳定分支，公共开发环境基于该分支构建。

注意点：

为了开发某个特定功能，从 develop 分支上面分出来的。开发完成后，要merge到 develop 分支。

注意点：

feature 分支的使用说明：

预发布分支，又叫测试分支，是一个临时分支。通常用于合并到 master 之前拉一个预发布分支用于测试。

注意点：

修复线上bug一般拉一个叫 hotfix-* 分支。其他的开发bug分支叫 bugfix 分支。这两种分支都属于临时分支，合并完成，及时删除该分支。

因为线上bug和开发bug处理方式不同，最好还用分区一下分支的命名

bug产生的分支情况：

bug产生于 master 分支，需要从 master 对应的tag节点拉取hotfix分支，做完修复之后，用这个hotfix

打包测试，发布上线。 上线成功之后，将该条hotfix分支分别合并到 master 和 develop 上 ，并删除该hotfix分支。（如有需要还要合并到需要的 feature 和 release 分支）

思考为什么要从bug分支打包上线❓

bug产生于 develop 分支，在发现该bug的节点，拉取bugfix分支，修复完成，合并回 develop 分支。并做删除操作。（如有需要还要合并到 feature 和 release 分支）

在 feature 上发现的bug，要对该bug做区分是否属于该功能分支上的。如果属于该分支，修改即可。如果属于 develop 分支，要在 develop 上找到合适的commit，拉取bugfix分支，修改完成之后合并到 develop 上。（如有需要还要合并到需要的 feature 和 release 分支）

生产环境的Bug分两种情况：

紧急Bug修复：

功能分支合并请求，可以使用Gitlab的 Merge Request 功能。本质是一种对话机制，你可以在提交的时候， @ 相关人员，引起他们的注意。

master 分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批 Merge Request 的权力。Gitlab默认提供了该功能。

Git有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另一种是"非直进式合并"（none fast-forword），会生成单独节点。

前者不利于保持commit信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用 --no-ff 参数）。只要发生合并，就要有一个单独的合并节点。