Git 分支管理模型团队规范

[yanyue404]

虽然一个人走的更快，但是一群人可以走得更远，前提是统一的步调和策略！

一、git 简介

• Workspace：工作区
• Index / Stage：暂存区
• Repository：仓库区（或本地仓库）
• Remote：远程仓库

二、分支管理

2.1 分支类型

TKFlow 使用以下两类共 4 种分支类型：

固定分支：

• master 分支：主分支（生产分支），代表当前项目的基线，保护分支，不允许直接修
  改，只接受合并请求。保证 master 代码与正式生产环境发布的最新代码相同。
• dev 分支（develop 分支）：
• 测试分支（开发提测分支），用于需求提测和测试环境部
  署，保护分支，不允许直接修改，只接受合并请求。

临时分支：

• feature 分支：特性分支（变更分支、需求分支），用于具体的需求开发。
• hotfix 分支：BUG 修复分支，用于线上 BUG 修复与重大事故应用版本回滚。
• release 分支（可选）：集成分支，用于集成和发布，在上线发布前对各 feature 分支进行集成和
  部署，不同的环境下可以使用不同的 release 分支（如预发环境 release_pre，生产环境
  release_prod）。

分支发布工作流下的分支类型（适合一个项目多个任务并行开发）

• master 主分支：代表当前项目的基线，保护分支，不允许直接修改，只接受合并请求。master 代码保留历史上线过的所有代码。
• feature 特性分支：（变更分支、需求分支），用于具体的需求开发，以及测试部署（每个独立的需求都有一个 对应的 feature 分支）。
• hotfix 修复分支：用于线上 BUG 修复与重大事故应用版本回滚。
• online 上线分支（可选）：用于灰度环境发布和生产环境发布，在上线发布前对各 feature 分支进行集成和
  部署。每次上线都有对应的上线分支，上线分支经过严格的测试后，将代码直接发布生产，进行生产验证。生产验证通过后，合入 master,并提交 tag。 （当只有一个需求上线时，上线分支就是 feature 分支 或 hotfix 分支）

2.2 版本号规约

版本号用于项目发布后 master 分支添加 tag，记录版本，我们常用的版本号为三位数版
本号，其构成如下：

V 主版本号.次版本号.小版本号

eg：V1.0.0、V1.5.0、V1.13.1 等

2.2.1 主版本号（首位版本号）

主版本号，也叫首位版本号、顶位版本号，即 V 后第一个版本号。主版本号一般代表
项目的期数与产品方向。除非项目合同改变、大规模 api 不兼容、产品方向改变、底层架构
升级等情况外不轻易更新。

另外，项目未正式发布、未正式孵化、未正式上线，则首位版本号为 0，一期发布，则项目 GIT 分支管理模型为 V1，二期发布则为 V2。

2.2.2 次版本号（迭代号）

次版本号，也叫迭代号，一般代表某个迭代发布的功能集合（一个迭代发布会包含若干
个功能更新）。

如 V1.1.0：第一期项目第一迭代发布版本、V1.2.0：第一期第二迭代发布版本、第一期

第十八个迭代发布版本:V1.18.0。

2.2.3 小版本号

小版本号，是为了某些小功能的临时上线，热修复的临时上线设置的小迭代，通常不包
含大的功能性更新，常常是围绕某个功能点进行升级或者某个 bug 的修复进行上线。

2.3 分支管理规则

代码合并需遵循以下几条基本规则：

规则一：开始工作前，从 master 分支创建 feature 分支。

为每个需求单独创建一个通常以 feature_前缀命名的特性分支，然后在这个分支上提交
代码修改。前缀命名规则为 OA 号。

规则二：提测时将 feature 分支合并到 dev 分支。

需求开发完成充分自测后，根据测试管理的要求，提交提测申请，将提测需求的 feature
分支合并到 dev 分支，测试自动将 dev 分支代码发布到测试环境。

规则三（可选）：上线前从 master 分支创建 release 分支，合并所有需上线的 feature 分支到 release
分支。

若生产环境存在灰测环境，可先将 release 分支发布到灰测环境进行生产验证。若只有
生产环境，则将 release 分支发布到生产环境。上线时可使用 jenkins 或流水线选择 release
分支发布。

规则四（可选）：发布完成后，合并相应的 release 分支到 master 分支，在 master 分支上添加
tag 版本号，同时删除该 release 分支和相关联的 feature 分支。

规则五：生产环境出现 BUG 需修复，从 master 分支最新版本拉取 hotfix 分支，修复后
合并到 dev 分支测试，测试通过后将 hotfix 分支发布到生产环境，发布完成后合并 hotfix 分
支到 master 分支，同时删除该 hotfix 分支。

规则六：线上出现重大事故需回滚代码，可从 master 分支历史版本创建 hotfix 分支后
发布，线上应用回滚后需及时修复 BUG 并合并回 master 分支，master 分支本身不得回滚。需要 Jenkins 配置

规则七：定期清理无用分支

2.4 补充说明

1. feature 分支需经过严格自测之后才能合并到 dev 分支，合并 dev 分支需提交提测申
   请，不得随意合并；
2. 每次生产发版后 dev 分支和所有正在开发的 feature 分支需从 master 拉取最新代码，
   保持代码与生产最新版本一致；
3. 只有 hotfix 分支和 release 分支才能往 master 分支上面合并，feature 以及 dev 分支
   均不能直接合并到 master 分支；
4. 所有临时分支在合并到 master 分支后需及时删除，避免分支过多，无开发任务时
   gitlab 中应只存在两条固定分支；

三、commit 提交规范

• feat ：新功能
• fix ：修复
• chore ：对构建或者辅助工具的更改
• refactor ：既不是修复 bug 也不是添加新功能的代码更改
• style ：不影响代码含义的更改 (例如空格、格式化、少了分号)
• docs ： 只是文档的更改
• perf ：提高性能的代码更改
• revert ：撤回提交
• test ：添加或修正测试

四、常用命令

创建仓库命令

下表列出了 git 创建仓库的命令：

# 初始化仓库
git init

# 拷贝一份远程仓库，也就是下载一个项目
git clone

提交与修改
Git 的工作就是创建和保存你的项目的快照及与之后的快照进行对比。

下面列出了有关创建与提交你的项目的快照的命令：

git add	    #添加文件到暂存区
git status	#查看仓库当前的状态，显示有变更的文件。
git diff	#比较文件的不同，即暂存区和工作区的差异。
git commit	#提交暂存区到本地仓库。
git reset	#回退版本。
git rm    	#删除工作区文件。
git mv  	#移动或重命名工作区文件。
git cherry-pick	#将指定的提交应用于其他分支。
git stash	#将暂存区未提交的数据保存起来，便于工作目录切换其他分支。
git rebase	#手动编辑指定的commit，便于合并多次提交记录。

提交日志

git log	            #查看历史提交记录
git blame <file>	#以列表形式查看指定文件的历史修改记录

远程操作

git remote	#远程仓库操作
git fetch	#从远程获取代码库
git pull	#下载远程代码并合并
git push	#上传远程代码并合并

五：高频 git 面试题

1. Git fetch & git pull 区别
2. Git rebase