GIT版本管理规范

版本管理规范

文档编写中

1. Git版本管理

1.1 分支命名

先来一张典中典

分支生命周期

以上生命周期仅作参考,不同开发团队可能有不同的规范,可自行灵活定义。

例如我们团队在开发时,至少需要保证以下流程:

develop 分支和 hotfix 分支,必须从 master 分支检出

由 develop 分支合并到 test 分支

功能测试无误后,由 test 分支合并到 release 分支

UAT测试通过后,由 release 分支合并到 master分支

对于工作量小的功能开发(工时小于1天),可以直接在devolop 分支进行开发,否则由 develop 分支检出 feature 分支进行开发,开发完后合并到develop 分支

1.1.1 dev 分支

develop 为开发环境分支,始终保持最新完成以及bug修复后的代码,用于前后端联调。一般开发的新功能时,feature分支都是基于develop分支创建的。

1.1.2 feature 分支

开发新功能时,以develop为基础创建feature分支。

分支命名时以 feature/ 开头,后面可以加上开发的功能模块, 命名示例:feature/user_module、feature/cart_module

1.1.3 hotfix 分支

线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支。修复完成后,需要合并到 master 分支和 develop 分支。

分支命名以hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似

1.1.4 release分支

release 为预上线分支(预发布分支),UAT测试阶段使用。一般由 test 或 hotfix 分支合并,不建议直接在 release 分支上直接修改代码。

细分分支: Pre-SIT SIT UAT PROD 环境所有hotfix和feature首先上到Pre-SIT/SIT,cherry-pick到其他分支

1.2 Commit提交

在编写文档时,应遵循正式、简洁且易于理解的语言规范。文档不仅应具备专业性和准确性,还应确保内容清晰明了。

feat: 新增功能

fix: 修复bug

docs: 仅文档更改

style: 不影响代码含义的更改(空白、格式设置、缺失 分号等)

refactor: 既不修复bug也不添加特性的代码更改

perf: 改进性能的代码更改

test: 添加缺少的测试或更正现有测试

chore: 对构建过程或辅助工具和库(如文档)的更改

除此之外,还有一些常用的类型:

delete:删除功能或文件

modify:修改功能

build:改变构建流程,新增依赖库、工具等(例如webpack、gulp、npm修改)

test:测试用例的新增、修改

ci:自动化流程配置修改

revert:回滚到上一个版本

单次提交注意事项

提交问题必须为同一类别

提交问题不要超过3个

提交的commit发现不符合规范,git commit --amend -m "新的提交信息"或 git reset --hard HEAD 重新提交一次

2. .gitignore

.gitignore是一份用于忽略不必提交的文件的列表,项目中可以根据实际需求统一.gitignore文件,减少不必要的文件提交和冲突,净化代码库环境。

下面提供一份通用配置,可自取:

Bash
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/

### VS Code ###
.vscode/

# Log file
*.log
/logs*

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

3. README.md

在Git中,README.md 文件通常用来描述项目的概要、安装和使用方法、贡献指南等。它是项目的门面,帮助其他开发者理解和使用你的项目。下面是一个典型的 README.md 文件结构示例:

Bash
# 项目名称

一句话描述项目。具体描述

## 目录

- [介绍](#介绍)
- [安装](#安装)
- [使用](#使用)
- [贡献](#贡献)
- [许可证](#许可证)
- [联系方式](#联系方式)

## 介绍

详细描述项目的背景、目的和功能。

## 安装

步骤一:克隆仓库
```bash
git clone https://github.com/username/repo-name.git

npm install # 或者 pip install -r requirements.txt

## 使用描述

描述如何使用项目,可以包括命令行指令、配置文件说明等。

## 许可证
MIT

posted @   卡优卡1255  阅读(45)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· ollama系列01:轻松3步本地部署deepseek,普通电脑可用
· 25岁的心里话
· 按钮权限的设计及实现
点击右上角即可分享
微信分享提示