Git 分支模型介绍

最新推荐文章于 2025-04-21 22:34:05 发布

轻狂的书生

最新推荐文章于 2025-04-21 22:34:05 发布

阅读量1.1k

点赞数 1

文章标签： git npm github

本文链接：https://blog.youkuaiyun.com/qg2276879379/article/details/107730451

版权

前言

当有多个人一起协作开发时我们就会用到Git ，但是只是简单用了它所提供的代码协作功能，但基于项目太小的特征：没有持久性、一次性开发，所以没有应到 Git 分支模型。然而在企业中，一个应用往往是有比较长的生命线，由很多个迭代项目开发构成，这时要解决几十甚至几百人的代码协作问题，就需要一套完整的规范的代码开发流程。

1.分支模型图解：

在这里插入图片描述

2.分支介绍

master ：这个分支的代码是发布到生产的代码

develop ：这个分支的代码是预发布到生产的代码

release ：这个分支的代码是新版本发布到生产的代码

feature ：这个分支的代码是新需求开发的代码

hotfix ：这个分支的代码是紧急修复生产 bug 的代码

2.1 主分支(master, develop)

主分支包括 master 分支和 develop 分支。master 分支用来发布，HEAD 就是当前线上的运行代码。develop 分支就是我们的日常开发。使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题则将 develop 分支的代码合并到 master 分支并发布。

2.2 辅助分支(feature , release, hotfix)

feature 分支用来开发具体的功能，一般 fork 自 develop 分支，最终可能会合并到 develop 分支。一般feature分支都存在于开发者本地，开发期间使用git rebase来保证和develop分支的代码同步并解决冲突。功能开发完毕后push到远程仓库，然后提交pull request，合并到develop分支。
release 分支在我看来是 pre-master。release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 master 分支。合并到 master 分支上就是可以发布的代码了。有人可能会问那为什么合并回 develop 分支呢？很简单，有了 release 分支，那么相关的代码修复就只会在 release 分支上改动了，最后必然要合并到 develop 分支。比如，当开发一个较长期的feature不着急上线但又需要部署测试时，可以从develop分出一个release分支，feature提交pull request到这个release分支，然后部署这个release分支到测试服。

hotfix 分支用来修复线上 bug。当线上代码出现 bug 时，我们基于 master 分支开一个 hotfix 分支，修复 bug 之后再将 hotfix 分支合并到 master 分支并进行发布，同时 develop 分支作为最新最全的代码分支，hotfix 分支也需要合并到 develop 分支上去。

2.3 分支命名

除了主要分支的名字是固定的之外，派生分支是需要自己命名的，这里就要有个命名规范了。强烈推荐用如下形式：

master 主分支，发布分支

dev 主分支，开发分支
feat_xxx——按照功能点（而不是需求）命名；
release_xxx——用发布时间命名，可以加上适当的前缀；
hotfix_xxx——GitLab 的 issue 编号或 bug 性质等。

小写字母下划线形式

2.4版本号命名

格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。

v1.1.1：第一位大版本号，大功能发布时增加，技术负责人审核；第二位小版本号，增加小特性时增加，主开发审核；第三位BUG修复号，修复BUG用，修复人员负责。

每次发布生产(master)，需要为master打一个tag，方便线上回滚

3.开发规范

3.1 Commit原则

  只要坚持做到以下几点就 OK 了：

提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；
不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。

3.2 Commit Message 格式

<type>(<scope>): <subject> （不超过50个字）

<空行>

<body> （每行不超过72个字）

<空行>

<footer>

type

feat：新功能（feature）
fix：修补bug
mod：修改（即不是新增功能，也不是修改bug的代码变动）
refactor：重构
docs：文档（documentation）
style：格式（不影响代码运行的变动）
test：增加测试
chore：构建过程或辅助工具的变动
Scope
用来说明本次Commit影响的范围，即简要说明修改会涉及的部分。这个本来是选填项，但从AngularJS实际项目中可以看出基本上也成了必填项了。

Subject

用来简要描述本次改动，概述就好了，因为后面还会在Body里给出具体信息。并且最好遵循下面三条:

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
首字母不要大写
结尾不用句号(.)
Body

里的内容是对上面subject里内容的展开，在此做更加详尽的描述，内容里应该包含修改动机和修改前后的对比。

Footer

footer里的主要放置不兼容变更和Issue关闭的信息

Revert

此外如果需要撤销之前的Commit，那么本次Commit Message中必须以revert：开头，后面紧跟前面描述的Header部分，格式不变。并且，Body部分的格式也是固定的，必须要记录撤销前Commit的SHA值。
示例

feat: 增加用户权限功能

增加用户权限列表显示接口和用户权限编辑接口

BREAKING CHANGE: 删除了旧版登录验证接口