Git分支管理规范（开发协同管理）

最新推荐文章于 2025-04-15 08:16:29 发布

Zze0

最新推荐文章于 2025-04-15 08:16:29 发布

阅读量1.2k

点赞数 3

文章标签： git

本文链接：https://blog.youkuaiyun.com/EFSGFDSRH/article/details/117136345

版权

本文详细介绍了Git的环境命名规范，包括开发(dev)、测试(sit)、用户验收测试(uat)和生产(prod)环境。同时，阐述了Git分支管理，如master(主分支)、release(预发布分支)、feature(功能开发分支)和hotfix(紧急bug修复分支)的使用场景和命名规则。此外，提出了feature分支命名规范，并强调了代码管理和协同开发的最佳实践，包括代码审查的重点和项目交付后的分支处理策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

环境命名规范

环境	命名
开发环境	dev
测试环境	sit
用户验收测试环境	uat
生产环境	prod

分支说明

分支	含义	创建来源分支	合并目标分支	环境	备注
master	主分支	-	-	prod	生产环境的版本。永远是可用的、稳定的、可直接发布的版本。不能直接在该分支上开发。
release	预发布分支	master	master	uat	用于uat提测、发版的分支。 uat测试通过后，发布release分支到生产环境，再合并到master分支。
feature	功能开发分支	master	release	dev、sit	用于dev开发、sit提测的分支。 sit测试通过后，合并到release分支。
hotfix	紧急bug修复分支	master	master	-	修复线上bug，uat紧急测试通过后，发布hotfix分支到生产环境，再合并到master分支。

分支命名规范

feature分支命名: feature-<主版本号>.<小版本号>.<迭代版本号>-<特征英文缩写>

例如：feature-1.0.0-msg2.0、feature-1.2.1-refund

研发人员feature-xxx分支命名: feature-<主版本号>.<小版本号>.<迭代版本号>-<特征英文缩写>-<研发人员简称>

例如：feature-1.0.0-msg2.0-Zze0、feature-1.2.1-refund-gqt

release分支命名：release-<主版本号>.<小版本号>.<迭代版本号>

例如：release-1.0.0、release-1.2.1

hotfix分支命名：hotfix-<主版本号>.<小版本号>.<迭代版本号>-<特征英文缩写>

例如：hotfix-1.0.0-msg2.0、hotfix-1.2.1-refund

git flow

注意事项

项目交付上线后，feature分支和release分支必须删除。代码提交记录已经在master上，feature分支和release分支已无用，如果线上有问题，则从master拉取hotfix分支进行修复。
一个feature分支尽量开发一个功能模块，不要多个功能模块在一个feature分支上开发，除非这些功能模块需要相互依赖。
同期有多个feature分支进行开发且调整为同一个时间上线时，可以建立一个feature-full分支合并这些小feature分支，再进行提测。如果某个功能模块测试不通过需要延期时，可以回滚或建立新的feature-full分支合并除了那个功能模块以外的小feature分支，再重新提测，以防因为一个功能模块导致整个项目工期延期。
技术经理做代码review内容主要是：了解代码位置合理性、代码规范、代码中的无用注释代码、存在临时测试代码、资源文件存放位置、资源大小、代码耦合情况、是否有编写已有的公共功能、明显的代码错误、运行错误、代码质量、及其优化建议。