78 lines
3.2 KiB
Markdown
78 lines
3.2 KiB
Markdown
---
|
||
id: 分支（Branch）
|
||
title: 分支（Branch）
|
||
sidebar_position: 1
|
||
data: 2022年6月15日
|
||
---
|
||
|
||
## 规范
|
||
|
||
|
||
|
||
主分支命名：`master `、`main`
|
||
|
||
开发分支命名：`develop`
|
||
|
||
功能分支命名：除 `master`、`main`、`develop`、`release-*`、`hotfix-*` 以外的任何名字
|
||
|
||
预发布分支命名：`release-*`
|
||
|
||
热修复分支命名：`hotfix-*`
|
||
|
||
防止产生歧义，**建议禁止简拼。**
|
||
|
||
## 主要分支
|
||
|
||
在中央仓库中有两个生命期无限长的主要分支：
|
||
|
||
- Master（主分支）
|
||
- Developer（开发分支）
|
||
|
||
默认主要分支 `origin/master` 的 `HEAD` 所指向的源码总是处于**可发布**的状态。
|
||
|
||
默认主要分支 `origin/develop` 的 `HEAD` 所指向的源码总是处于为下次发版所做的最近的一次修改提交的状态。
|
||
|
||
当 `develop` 分支上的代码达到了一个稳定的点并且准备进行发版时，在该分支上所做的所有修改都应该被合并回 `master` 分支，并且打一个版本号标签（`tag`）。
|
||
|
||
## 辅助分支
|
||
|
||
伴随着主要分支 `master` 和 `develop` ，我们的开发模式还用了一些辅助分支来协助团队成员间的平行开发，使对功能的追踪变得轻便，并且协助产品的发布，以及进行线上版本bug的快速修复。
|
||
|
||
- Feature branches (功能分支)
|
||
- Release branches (预发布分支)
|
||
- Hotfix branches (热修复分支)
|
||
|
||
### 功能分支
|
||
|
||
- 分支：创建自：`develop`；必须合并回：`develop`。
|
||
|
||
- 分支命名：除 `master`、`develop`、`release-*`、`hotfix-*` 以外的任何名字
|
||
|
||
功能分支通常**只存在于开发者的本地仓库中**，并不包含在远程库 `origin` 中。
|
||
|
||
### 预发布分支
|
||
|
||
- 分支：创建自：`develop`；必须合并回：`develop` 和 `master`。
|
||
|
||
- 分支命名：`release-*`。
|
||
|
||
预发布分支主要用来协助一个新版本发布的准备工作。
|
||
|
||
它允许对预发布版本做最后的打点，例如做一些较小的 **bug 修复**并且准备一些发版的数据(版本号和编译数据等)。**最后**，在该预发布分支上所做的修改要合并回 `develop` 分支，这样以后的版本就也包含了在该预发布分支上所做的bug修复。
|
||
|
||
正式发布后就可以删掉该预发布分支了。
|
||
|
||
### 热修复分支
|
||
|
||
- 分支：创建自：`master`；必须合并回：`develop` 和 `master`；
|
||
|
||
- 分支命名：`hotfix-*`。
|
||
|
||
热修复分支也是用来协助新版本发布的，在这点上和预发布分支相似，但该分支不是必须存在的。
|
||
|
||
该分支的创建主要是用来及时应对线上版本所出现的意外情况。当线上版本出现一个需要立刻修复的严重bug时，我们可以从 `master` 分支上标记为当前线上版本号的`tag`处切出一个热修复分支。
|
||
|
||
当完成了紧急 bug 的修复时，要将该热修复分支合并回 `master` 分支，**并且同时也要将其合并回 `develop` 分支**，以确保对该 bug 的修复也同时包含在下一次发版中。**如果此时同时存在一个预发布分支，那么要把该热修复分支合并回该预发布分支，而不是 `develop` 分支**。
|
||
|
||
最后就可以删掉该热修复分支了。
|