Git 企业级协作规范文档

原创已于 2026-06-26 13:35:37 修改 · 209 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#git #java #前端 #后端

话题

#CSDN年度技术趋势预测

于 2026-06-26 13:35:12 首次发布

开发工具专栏收录该内容

2 篇文章

订阅专栏

企业级 Git 协作规范文档

文档目的

统一团队 Git 使用方式，规范分支创建、代码提交、合并、版本发布流程，减少代码冲突、避免提交混乱、防止代码丢失，保障代码库稳定可追溯，适配 CI/CD 自动化流水线。

一、基础环境规范（企业强制落地标准）

本章为全员开发设备统一强制规范，所有团队成员必须完成本地环境初始化配置，统一代码提交溯源、跨平台兼容、仓库性能、安全权限，从根源杜绝个人环境差异导致的冲突、格式错乱、提交溯源失效、推拉报错等问题。所有配置一次设置、永久生效，适配Windows/Mac/Linux全平台。

1. 身份信息配置（代码溯源核心·强制）

所有开发者必须配置真实可追溯的提交身份，禁止匿名、随意昵称提交，用于代码责任归属、MR评审溯源、迭代复盘。

# 全局统一身份配置（所有项目生效，优先推荐）
git config --global user.name "真实姓名/工号"
git config --global user.email "企业邮箱/工作邮箱"

# 多企业/多项目专属身份（局部覆盖全局，单项目生效）
git config user.name "项目专属姓名"
git config user.email "项目专属邮箱"

规范要求：姓名禁止英文乱码、昵称，邮箱必须为工作邮箱，禁止个人私人邮箱用于企业项目提交。

2. 高频命令别名配置（团队统一操作习惯·推荐）

统一全员命令简写，简化高频操作，避免命令输入错误，统一团队操作话术与习惯。

# 基础高频别名
git config --global alias.st status
git config --global alias.co switch
git config --global alias.br branch
git config --global alias.cm "commit -m"
git config --global alias.unstage "reset HEAD"

# 进阶运维别名（提效必备）
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.pullr "pull --rebase"
git config --global alias.forcepush "push --force-with-lease"
git config --global alias.resetsoft "reset --soft HEAD~1"

3. 跨平台兼容配置（根治CRLF/LF格式冲突·强制）

解决Windows、Mac、Linux跨系统协作导致的「无修改全量变红、无效diff、批量冲突」顽疾，企业团队统一归一化配置。

# 团队统一标准配置（全平台通用最优解）
git config --global core.autocrlf input

# 配套兼容优化（杜绝文件权限、大小写无效变更）
git config --global core.filemode false
git config --global core.ignorecase false

配置释义：所有系统提交代码统一转为LF标准换行符，检出时适配本地系统格式，彻底统一仓库文件规范，杜绝跨平台格式冲突。

4. 全局与项目双维度忽略文件规范（强制）

区分「个人全局忽略（所有项目生效）」和「项目团队忽略（全员统一）」，彻底杜绝IDE配置、系统缓存、本地环境文件误提交。

4.1 全局忽略配置（个人设备专属）

# 创建全局忽略文件并绑定配置
touch ~/.gitignore_global
git config --global core.excludesfile ~/.gitignore_global

全局忽略规则（适配个人所有项目）：系统缓存、IDE私有配置、本地临时文件

# 系统缓存
.DS_Store
Thumbs.db
*.tmp
*.log

# 编辑器私有配置
.idea/
.vscode/
*.suo
*.user

# 本地环境文件
.env.local
.local
node_modules/
dist/
build/

4.2 项目级.gitignore规范（团队统一强制）

项目根目录必须维护统一的.gitignore，纳入版本管控，保证所有团队成员忽略规则一致，禁止私自修改。

4.3 忽略规则失效修复方案（高频排错）

若文件已被Git追踪，新增忽略规则不会自动生效，需手动清理缓存：

# 清理单个文件缓存
git rm --cached 文件名

# 全局重置忽略规则（批量修复）
git rm --cached -r .
git add .

5. 仓库性能优化配置（大仓库提速·推荐）

针对迭代周期长、文件量大、分支多的项目，优化Git读写性能，解决克隆卡顿、状态查询缓慢、diff延迟问题。

# 开启索引预加载，加速status、diff查询
git config --global core.preloadindex true

# 开启文件系统缓存，提升大文件操作速度
git config --global core.fscache true

# 调高垃圾回收阈值，减少自动卡顿
git config --global gc.auto 256

# 大文件阈值适配，优化二进制文件读写
git config --global core.bigfilethreshold 104857600

6. 安全权限配置（规避高危操作·强制）

从配置层面限制高危操作，杜绝代码覆盖、历史污染、强制推送事故。

# 禁止公共分支非快进合并，防止版本覆盖
git config --global receive.denyNonFastForwards true

# 默认推送当前分支，简化操作、规避错推分支
git config --global push.default current

7. 远程凭证与SSH环境配置（团队统一）

解决HTTPS频繁输密码、SSH连接失败、权限拒绝问题，统一长期稳定的远程连接方式。

7.1 HTTPS凭证缓存配置

# 缓存账号密码，无需重复输入
git config --global credential.helper store

7.2 SSH密钥规范（企业首选）

统一使用SSH方式关联仓库，规避凭证过期、密码变更问题，配置一次永久使用。

密钥生成必须绑定企业工作邮箱
私钥本地妥善保存，禁止提交仓库、禁止外传
公钥上传企业Git仓库账号，统一权限管控

8. 多账号环境适配规范（多公司/多项目场景）

针对同时参与企业项目、开源项目的开发者，严格区分全局/局部配置，避免账号邮箱错乱导致提交溯源失败。

企业项目：使用局部本地配置，绑定企业邮箱
开源项目：使用全局配置，绑定个人邮箱
禁止混用账号提交，保证不同项目提交身份独立合规

9. 环境配置排查与校验规范

新设备初始化、环境异常、提交溯源错乱时，执行以下命令排查配置问题：

# 查看全量配置（含配置来源路径，精准排错）
git config --list --show-origin

# 单独校验全局/本地配置
git config --global --list
git config --local --list

10. 基础环境落地验收标准（全员达标）

身份信息配置完整，提交记录可精准溯源
跨平台换行符统一，无无效格式变更
忽略文件规范生效，无临时文件、IDE配置误提交
远程凭证正常，推拉代码无权限报错
高危操作配置生效，杜绝误操作风险

二、分支管理规范（两种方案·强制二选一·企业落地完整版）

团队分支模型为代码协作核心基准，项目必须固定一套分支模型全程沿用，禁止两套模型混用。本章完整补全「GitFlow 版本迭代模型」「主干开发 Trunk Based 敏捷模型」的适用场景、完整工作流、合并策略、生命周期、权限规范、禁忌操作、落地标准，适配不同迭代节奏的项目，彻底解决分支混乱、版本错乱、合并事故、迭代追溯困难问题。

方案 A：GitFlow 标准模型（正式版迭代/多版本并行/版本强管控项目）

适用场景：中大型项目、版本周期固定（月度/季度迭代）、多环境并行（测试、预发、生产）、需要版本归档、线上版本与开发版本长期分离、需要同时维护多个历史版本的项目。

核心优势：版本隔离清晰、风险可控、发布稳定、可回溯可回滚、适配正式版本上线流程；短板：流程繁琐、迭代节奏慢，不适合高频持续部署项目。

1. 五大固定分支定位与权责（永久分支+临时分支）

分支名	分支定位与核心用途	来源分支	合并目标	生命周期
`master/main`	生产唯一稳定基线，仅存放已上线正式代码，任何时刻均可直接部署生产	永久主干	仅接收 release、hotfix 合并	永久保留
`develop`	开发集成基线，汇总所有迭代功能，保存下一待发布版本代码	初次从master拉出	feature、release 合并	永久保留
`feature/xxx`	单业务功能独立开发分支，一人/小组独占开发	develop	develop	临时分支，合并后立即删除
`release/vx.x.x`	版本预发布分支，迭代收尾、统一测Bug、版本定型，不新增功能	develop	develop + master	临时分支，版本上线后删除
`hotfix/vx.x.x`	生产紧急故障热修复，快速修复线上阻断性问题	master	master + develop	临时分支，修复上线后删除

2. 强制分支命名规范（统一归档标准）

功能开发分支：feature/任务ID-简短功能描述，示例：feature/T2026-user-phone-login
版本预发布分支：release/主版本.次版本.补丁，示例：release/v1.3.0
线上热修复分支：hotfix/主版本.次版本.补丁-问题简述，示例：hotfix/v1.2.1-order-calc-bug

3. GitFlow 完整标准工作流（强制落地步骤）

3.1 新功能开发流程

同步develop最新代码，保证本地基线最新；
从develop拉出专属feature功能分支；
独立开发、频繁小粒度规范提交；
开发自测完成，拉取develop最新代码解决冲突；
推送远程分支，提交MR合并至develop；
评审通过、CI校验通过后合并，合并完成立即删除本地+远程feature分支。

3.2 版本发布流程

迭代功能全部合并至develop后，从develop拉出release预发布分支；
仅做Bug修复、配置调整、文档优化，禁止新增业务功能；
测试全量回归，修复问题直接提交至release分支；
测试通过后，同时合并至master与develop分支，保证双基线版本一致；
在master分支打正式版本标签，归档版本；
删除release临时分支，本次迭代结束。

3.3 线上紧急热修复流程

基于当前线上master最新版本，拉出hotfix修复分支；
精准修复线上阻断Bug，最小改动原则，禁止附带无关优化；
自测+测试回归通过；
合并至master（上线修复），同时合并至develop（同步至开发基线，避免下个版本复现）；
master更新对应补丁版本标签，归档修复版本；
删除hotfix临时分支。

4. GitFlow 合并策略规范

feature → develop：采用Squash合并，多条开发提交压缩为一条规范迭代记录，保证开发基线整洁；
release → master/develop：保留完整提交记录，便于版本问题追溯；
hotfix → master/develop：保留修复完整记录，精准定位线上故障修复节点。

5. GitFlow 红线禁忌

禁止直接在master/develop永久分支提交代码；
禁止在release分支新增功能，只修Bug不迭代；
禁止hotfix分支做功能优化，仅修复线上致命问题；
禁止保留过期feature/release/hotfix分支，避免分支堆积混乱。

方案 B：主干开发 Trunk Based Development（敏捷迭代/持续部署/高频上线项目·推荐）

适用场景：敏捷迭代、小步快跑、日均多次部署、无需固定版本归档、轻量版本管理的互联网项目、SaaS项目、持续交付项目。

核心优势：流程极简、迭代高效、冲突极少、上线灵活、学习成本低；短板：不适合多版本并行维护、传统固定版本发布模式。

1. 分支整体架构规范

全局唯一永久主干分支：main，所有线上代码、迭代基线统一依托main；
所有开发均从main拉出短生命周期特性分支，无长期开发分支、无预发布分支；
严格遵循：短分支、快合并、快销毁、不堆积核心原则。

2. 强制分支命名规范（语义化+可追溯）

新功能迭代：feat/任务ID-功能简述，示例：feat/T2026-order-refund
线上/测试Bug修复：fix/任务ID-问题简述，示例：fix/T2026-pay-timeout-error
代码重构/性能优化/工程调整：refactor/任务ID-优化内容
文档/注释更新：docs/任务ID-文档说明
依赖/配置/工程脚本调整：chore/任务ID-配置更新

3. 主干开发标准工作流

每日开发前先执行git pull origin main 同步主干最新基线；
基于main新建语义化特性分支，独立开发；
开发过程小粒度、规范提交，不堆积大量代码；
开发自测完成，再次拉取主干代码，本地解决所有冲突；
推送远程分支，提交MR，填写关联任务、修改说明、测试步骤；
评审通过、CI流水线校验通过后，Squash合并至main主干；
合并完成立即删除本地+远程特性分支，杜绝无效分支堆积。

4. 核心强制规则（主干开发关键）

分支生命周期强制约束：所有特性分支存活时间不超过3天，短期迭代、快速合并，杜绝长期滞后分支；
主干永久干净稳定：main分支任何时刻均可直接部署，禁止未自测、未评审、未测试代码合并主干；
冲突前置解决：所有冲突必须在个人特性分支本地解决，禁止将冲突代码合入主干；
提交历史整洁：统一使用Squash合并，单次迭代对应主干单条规范提交，历史清晰可追溯。

5. 主干开发禁忌操作

禁止多人共用同一个特性分支开发；
禁止特性分支长期不合并、不更新主干；
禁止直接推送代码至main主干，必须走MR评审流程；
禁止在主干分支执行rebase、reset等重写历史操作。

两套模型选型决策标准（团队统一落地依据）

选 GitFlow：有固定版本迭代周期、需要维护多版本、需要版本归档、预发布环境定型、传统政企/大型项目、上线节奏固定；
选主干开发：敏捷迭代、持续部署、高频小版本上线、无需多版本并行、互联网轻量项目；
硬性要求：项目初始化时确定模型，全程不可中途切换、不可混用分支规则，所有成员严格统一执行。

通用全局分支红线（两套模型均强制遵守）

所有公共主干分支开启分支保护，禁止直接推送、禁止强制推送、禁止随意删除；
所有临时分支合并后必须及时销毁，保持仓库分支整洁；
公共分支只允许merge合并，私有特性分支可使用rebase整理提交；
任何分支操作不得覆盖、污染团队已有有效代码历史。

三、代码提交规范（强制约束·企业落地完整版）

代码提交是版本追溯、问题定位、代码评审、自动迭代日志生成的核心基础，所有团队成员必须100%遵守统一提交规范。本章细化提交格式、提交粒度、场景约束、错误修正规则、历史整理规范、自动化校验标准，杜绝模糊提交、脏提交、混合提交，保证仓库提交历史干净、线性、可审计、可复盘。

1. 标准化提交信息格式（强制 Conventional Commits）

所有提交必须严格遵循统一语义格式，禁止自定义随意备注，适配自动化 CHANGELOG 生成、版本迭代统计、问题溯源、MR 评审归类。

1.1 标准格式结构

固定格式：类型(模块): 简短描述【可选：详细正文/关联单号】

结构说明：

类型：固定规范关键词，严格限定取值
模块：业务模块/功能包/服务名，精准定位改动范围
简短描述：一句话清晰说明改动内容，禁止模糊话术
扩展正文（可选）：复杂改动可换行补充修改原因、适配场景、注意事项

1.2 合法提交类型（仅允许以下7类）

feat：新增业务功能、新增接口、新增页面、新增能力（对应版本小版本迭代）
fix：修复测试/线上 Bug、修复逻辑异常、修复兼容问题（对应补丁版本迭代）
docs：仅修改注释、文档、README、接口文档，无任何代码逻辑变更
refactor：代码重构、结构优化、逻辑梳理，不改变任何功能与输出
test：新增/修改/补充单元测试、集成测试、mock数据，无业务代码变更
chore：工程配置、依赖版本、构建脚本、CI配置、git配置调整，无业务功能变更
perf：性能优化、接口提速、渲染优化、内存优化、请求瘦身等性能提升改动

1.3 规范与不规范示例（强对比）

✅ 标准规范示例

feat(user): 新增手机号验证码登录功能
fix(order): 修复特殊场景下订单金额四舍五入精度误差
refactor(goods): 重构商品列表查询过滤逻辑，提升可读性
perf(api): 优化首页接口查询耗时，减少数据库重复查询
docs: 更新项目启动与部署文档
chore: 升级项目依赖版本，修复依赖安全漏洞
test(order): 补充订单支付场景单元测试

❌ 严禁无效提交示例（全线禁止）

update
修改代码
修复bug
临时提交
调试代码
优化部分逻辑
测试一下

2. 提交粒度规范（强制单职责原则）

所有提交严格遵循一次提交、一件事情、一个改动维度，杜绝混合提交，保证版本可回滚、可精准定位问题。

2.1 允许提交场景

同一模块单一功能新增、单一逻辑修复、单一性能优化
批量同类文档修改、同类配置调整、同类测试用例补充
局部代码重构，不穿插功能新增与Bug修复

2.2 绝对禁止混合提交

禁止「新功能开发 + Bug修复」合并一次提交
禁止「业务代码 + 配置修改 + 依赖升级」混杂提交
禁止「功能迭代 + 代码重构」混合提交
禁止堆积大量未分类代码一次性批量提交

落地要求：多维度改动必须拆分多次规范提交，保证每一条提交可独立回滚、独立追溯。

3. 提交前置自检规范（提交前必做）

所有开发者在执行 commit 前，必须完成以下自检，杜绝无效、错误、脏代码入库：

文件筛选自检：确认无临时文件、日志文件、密钥配置、本地环境变量混入提交
代码自测自检：本地编译通过、项目可正常运行、无新增报错、无语法警告
逻辑完整性自检：当前改动逻辑完整，无半截代码、注释代码、调试残留代码
格式化自检：代码已统一格式化，无缩进混乱、格式错乱、无效空行
备注合规自检：提交备注符合规范，语义清晰、可精准追溯

4. 提交修正与历史整理规范（私有分支专用）

核心红线：仅个人私有特性分支允许整理提交历史，公共主干分支严禁任何历史重写操作。

4.1 临时提交整理（开发阶段提效）

开发过程中可频繁小粒度提交，迭代收尾后、提交MR前，必须整理零散历史，保证合入主干的提交记录干净规整。

# 交互式变基，合并/修改/删除多条零散提交
git rebase -i HEAD~n

# 常用操作
# pick：保留该提交
# squash：合并至上一条提交
# reword：修改提交备注
# drop：删除无效提交

4.2 最新代码同步规范

个人分支优先使用 git pullr（pull --rebase）同步主干最新代码
同步后整理冲突、整理提交历史，保证主干历史线性干净
禁止大量混杂合并节点，避免主干历史杂乱分叉

5. 异常提交修复规范

5.1 未推送远程：本地错误提交修正

# 修改上一次提交备注/补充代码，不新增提交记录
git commit --amend

5.2 已推送远程：公共分支禁止回写历史

已推送远程的错误提交，禁止使用 rebase/amend 重写历史，只能新增修复提交，备注格式：fix(模块): 修复上一版本xx问题，保证团队版本统一。

6. 全场景禁止操作（强制红线）

禁止在公共主干分支（main/develop）直接 commit、直接推送代码。
禁止在多人共用分支执行 git rebase、git amend 等重写历史操作，仅允许 merge。
禁止使用无意义、模糊、无法追溯的提交备注。
禁止将调试代码、console日志、注释残留代码、临时测试代码提交入库。
禁止一次提交混杂多模块、多类型改动，破坏版本追溯性。
禁止强制推送重写公共分支历史，避免团队代码版本错乱、丢失。

7. 自动化强制校验规范（工程化落地）

为杜绝人为违规，团队可接入工具全自动强制校验，不合规直接拦截提交：

commitlint + husky：强制校验提交信息格式，非法类型、模糊备注直接拦截，禁止提交
eslint + prettier：提交前自动格式化代码、拦截语法错误与代码规范问题
git-cz：统一交互式提交，规范备注无需手动记忆格式
CI 流水线校验：MR 阶段二次校验提交历史，禁止脏历史、混杂历史合入主干

8. 提交规范落地价值

版本历史清晰线性，故障可精准定位到人、到改动节点
自动生成版本更新日志，降低版本复盘成本
代码评审聚焦真实业务改动，提升评审效率与质量
支持精准版本回滚、局部功能回退，保障线上稳定性
统一团队编码迭代习惯，降低新人上手成本

四、代码合并与 MR/PR 评审规范（企业强制落地）

MR（Merge Request）/PR（Pull Request）是团队代码质量管控、风险拦截、版本合规的唯一合并入口。所有代码严禁直接推送主干，必须经过分支开发、自测、冲突预处理、代码评审、CI校验、合规合并全流程。本章统一合并策略、评审标准、审批流程、冲突规范、红线禁忌、落地模板，彻底杜绝脏代码、风险代码、不合规代码入库。

1. 核心准入原则（合并前置强制条件）

所有 MR 必须满足以下全部条件，方可提交评审、进入合并流程，任意一条不满足直接驳回：

分支合规：必须为规范命名的短周期特性分支/修复分支，禁止使用过期分支、临时乱命名分支提交MR；
代码自测完成：本地编译成功、服务正常启动、功能自测通过、无显性BUG、无逻辑漏洞；
代码质量合规：无语法报错、无严重告警、无冗余死代码、无注释调试代码、代码已统一格式化；
基线同步完成：提交MR前必须拉取主干最新代码，本地提前解决所有冲突，禁止将冲突代码提交至MR；
提交历史合规：分支内提交记录符合Conventional Commits规范，无模糊、无效、混乱提交；
CI流水线校验通过：单元测试、代码扫描、构建打包全部通过，无阻断性异常。

2. MR 单据填写规范（统一归档、可追溯）

所有MR必须完整填写单据信息，信息缺失一律驳回，保证每一次合并可追溯、可复盘、可审计。

2.1 必填字段标准

关联任务ID：绑定禅道/Jira/看板任务编号，实现代码与需求一一对应；
修改类型：明确标注新增功能/BUG修复/代码重构/性能优化/配置调整；
修改内容说明：清晰描述改动范围、核心逻辑、技术方案，禁止“优化代码、修复问题”等模糊描述；
测试范围与步骤：明确测试场景、操作步骤、预期结果、边界用例；
风险说明：标注改动风险点、影响模块、回滚方案，无风险填写“无”。

2.2 MR 备注红线

禁止空备注、模板敷衍备注、语义模糊备注，所有描述必须精准、具体、可落地、可核验。

3. 分级评审流程规范（企业分级管控）

根据改动范围、风险等级划分评审标准，兼顾质量与迭代效率，全员强制执行。

3.1 普通低风险改动（日常迭代）

适用：普通功能迭代、页面改造、接口优化、非核心逻辑修复

评审要求：至少1名同组开发人员审批通过
评审重点：代码规范、逻辑正确性、边界处理、重复代码、安全隐患

3.2 中高风险改动（核心业务）

适用：支付、订单、权限、用户核心链路、数据库结构变更、缓存逻辑变更、底层架构调整

评审要求：开发负责人 + 技术负责人双人审批通过
评审重点：业务逻辑闭环、并发安全、数据一致性、兼容适配、降级兜底、回滚可行性

3.3 紧急线上修复特殊规则

线上阻断性BUG、生产故障热修复，可走快速评审通道：

优先保障快速修复上线，事后补齐完整复盘与二次评审；
改动遵循最小改动原则，禁止附带无关优化与功能改动。

4. 合并策略强制标准（分场景统一）

根据分支模型、分支类型固定合并方式，禁止随意选择合并策略，保证主干历史统一、整洁、可追溯。

4.1 主干开发模型（Trunk Based）统一策略

特性分支 → main主干：强制使用 Squash 合并
规则：将分支内多条零散开发提交，压缩为一条规范语义提交合入主干；
价值：主干历史线性干净、无杂乱分叉、版本回滚精准、问题定位高效。

4.2 GitFlow 模型分层策略

feature → develop：Squash合并，规整开发迭代历史；
release → master/develop：普通Merge合并，完整保留版本迭代轨迹；
hotfix → master/develop：普通Merge合并，完整留存线上故障修复记录。

4.3 通用禁止策略

禁止使用随意合并、暴力合并；
禁止保留无意义合并节点、多余分叉节点；
禁止主干分支变基合并。

5. 代码冲突处理规范（统一标准）

5.1 冲突责任界定

所有冲突由当前开发分支开发者全权负责解决，禁止交由评审人、测试人员处理。

5.2 分场景冲突处理规则

个人私有特性分支：优先使用 git rebase origin/main 变基方式合并基线，保持线性历史；
公共长期分支（develop）：仅使用merge合并，禁止变基，保护团队公共提交历史。

5.3 冲突解决红线

禁止直接删除对方代码、粗暴覆盖冲突；
禁止保留冲突标记、未解决冲突直接提交合并；
复杂冲突必须联动对应代码负责人确认，避免逻辑丢失、功能降级。

6. MR 评审权责与评审标准

6.1 提交人权责

对本次改动的代码质量、功能正确性、线上稳定性全权负责；
及时响应评审意见，限期修改、主动复盘、补齐缺陷；
严禁绕过评审、私自合并、重复提交无效MR。

6.2 评审人权责

严格把控代码规范、业务逻辑、安全风险、性能问题、边界场景；
拒绝“走过场评审”，发现问题必须明确标注、要求整改；
对评审遗漏的重大线上问题承担连带责任。

6.3 评审核心检查清单（必看）

是否存在冗余代码、死代码、重复代码；
是否存在硬编码、密钥泄露、接口越权、参数校验缺失；
是否处理异常场景、空值场景、并发场景；
数据库改动是否兼容旧版本、是否有回滚方案；
性能是否存在慢查询、循环查询、资源浪费；
改动范围是否合理，是否夹带无关代码、无关文件修改。

7. 合并后收尾规范（强制）

合并通过后立即删除远程+本地特性分支，杜绝无效分支堆积；
关闭对应任务、归档MR记录，禁止长期挂单；
重大迭代、BUG修复完成后，同步更新文档、接口说明、版本日志；
上线后主动验证功能有效性，兜底保障线上稳定。

8. 全流程红线禁忌（零容忍）

禁止绕过MR直接推送代码至主干分支；
禁止未自测、未测试、未校验代码提交MR；
禁止为了快速合并，强行覆盖冲突、忽略代码告警；
禁止评审走过场、人情评审、未审先合；
禁止合并后保留过期特性分支，造成仓库分支混乱；
禁止在MR中混入多维度无关改动，拆分不规范代码。

五、版本标签管理规范（企业版本归档·强制标准化）

Tag 版本标签是项目版本冻结、上线归档、历史回溯、故障复盘的唯一官方节点，用于标记每一次生产正式发布版本。所有线上发布必须打版本标签，标签信息纳入版本台账统一归档，禁止随意打标、改标、删标，保证所有上线版本可精准定位、可回滚、可审计、可追溯。

1. 版本号规范（语义化版本·强制统一）

全员统一遵循 MAJOR.MINOR.PATCH 三段式语义化版本规则，禁止自定义不规则版本号、日期版本号、模糊版本号。

1.1 版本号迭代规则

MAJOR 主版本：重大架构重构、不兼容破坏性改动、业务体系大迭代，版本号整体升级；不向下兼容。
MINOR 次版本：新增业务功能、新增接口、模块能力迭代优化，向下完全兼容，主版本号不变。
PATCH 补丁版本：线上BUG修复、逻辑微调、兼容修复、小粒度优化，无新增功能，仅修复问题。

1.2 辅助预发布标识（可选）

测试环境预发布版本可携带后缀，禁止带入生产：

测试预览版：v1.2.0-beta
候选发布版：v1.2.0-rc1

强制要求：生产正式版本禁止携带任何后缀，必须为纯净三段式版本号。

2. 标签类型选用规范（企业统一）

Git 标签分为轻量标签与附注标签，团队强制统一使用附注标签，禁止使用轻量标签做版本归档。

2.1 标签类型区别

轻量标签：仅绑定commit哈希，无作者、无时间、无版本说明，信息不可追溯，禁止用于正式版本。
附注标签（强制）：独立tag对象，保存版本说明、作者、时间，支持版本备注归档，满足企业审计要求。

2.2 标准打标命令（生产唯一标准）

# 本地创建正式版本附注标签
git tag -a v1.2.0 -m "正式版本：v1.2.0｜新增订单支付、修复结算精度问题｜2026-06-26"

# 推送远程仓库归档（必须推送，仅本地标签无效）
git push origin v1.2.0

3. 标签绑定分支规范（固定基线）

所有生产正式标签，仅允许打在 main/master 主干分支。
禁止在 feature、release、hotfix、develop 分支打正式版本标签。
预发布测试标签可临时打在 release 分支，上线合并主干后，重新在主干打正式归档标签。

4. 标签备注内容规范（必填可审计）

标签备注必须简洁完整说明版本核心内容，禁止空备注、模糊备注。

标准备注模板：版本号｜核心迭代内容｜修复问题｜上线日期

规范示例：v1.3.0｜新增用户手机号登录、优化首页加载速度｜修复优惠券叠加BUG｜2026-06-26

5. 标签运维与生命周期规范

5.1 新增标签规则

版本测试通过、生产上线完成后立即打标归档；
版本号严格递增，禁止重复版本号、回退版本号；
一次上线对应唯一版本标签，禁止一次迭代多标签、多迭代共用一个标签。

5.2 标签修改与删除规范（强约束）

核心红线：已推送远程的正式版本标签，禁止删除、禁止修改、禁止移动，视为永久归档节点。

本地未推送标签：可自由删除、重新打标；
已推送远程正式标签：绝对禁止删除与覆盖；
版本存在问题，不改动旧标签，直接迭代新版本补丁标签。

5.3 错误标签修复方案

若远程已推送标签存在备注错误、版本号写错，严禁删标重打：

记录错误版本台账说明；
直接升级 PATCH 补丁版本发布新版本标签；
旧版本标签保留归档，用于历史追溯。

6. 版本回溯与回滚规范

线上故障需要版本回滚时，以标签为唯一基准回滚，禁止基于零散commit随意回退。

# 基于历史稳定版本标签，切回对应版本
git checkout v1.2.0

# 基于指定版本新建修复分支
git switch -c hotfix/v1.2.1-bugfix

7. 版本台账归档规范（团队落地必备）

所有版本标签必须同步登记版本台账，内容包含：版本号、上线时间、迭代内容、负责人、关联任务、风险说明、回滚版本。实现代码标签+文档台账双向追溯。

8. 全流程红线禁忌（零容忍）

禁止使用轻量标签作为正式生产版本归档。
禁止在非主干分支打生产正式版本标签。
禁止重复版本号、倒退版本号、自定义非规范版本号。
禁止删除、覆盖、修改已推送远程的正式版本标签。
禁止空备注、模糊备注打版本标签。
禁止不上线打标、未测试打标，杜绝无效脏标签。

9. 常用标签运维命令清单（团队统一）

# 查看所有本地版本标签
git tag

# 查看远程所有标签
git ls-remote --tags origin

# 查看当前版本标签详细信息
git show v1.2.0

# 删除本地错误标签（仅未推送可用）
git tag -d v1.2.0

# 推送单个版本标签
git push origin v1.2.0

# 推送所有本地标签（慎用，禁止批量推送脏标签）
git push origin --tags

六、储藏与临时代码处理规范（临时代码管控·强制标准化）

开发过程中切换分支、紧急修Bug、临时同步基线、跨任务切换场景时，禁止随意提交半成品代码、禁止堆积未完成改动。所有未自测、未完成、不具备合并条件的临时代码，必须统一使用 Git Stash 储藏管理，规范临时代码生命周期，杜绝半成品代码误提交、误合并、代码丢失、分支污染问题。

1. 核心强制原则

半成品不提交原则：未开发完成、未自测通过、逻辑不闭环的代码，禁止执行 commit 提交，仅允许 stash 储藏。
场景必储原则：切换分支、同步主干基线、临时紧急改Bug、暂停当前任务，必须先储藏本地改动。
随用随清原则：临时储藏的代码恢复使用后，及时清理无效储藏记录，禁止大量无用储藏堆积。
可追溯原则：所有储藏必须携带清晰备注，禁止无备注匿名储藏，防止遗忘代码用途。

2. 标准化储藏操作规范（统一命令）

统一使用带备注储藏方式，废弃默认无参匿名储藏，保证每一条储藏可识别、可追溯。

2.1 标准带备注储藏（强制使用）

# 标准语法：储藏所有改动并添加任务备注
git stash save "【任务ID】临时备注：当前未完成功能/改动说明"

# 规范示例
git stash save "【T2026-1001】未完成：用户登录页表单校验开发"
git stash save "【T2026-1002】暂停：订单结算逻辑优化，待续开发"

2.2 选择性储藏（精细化场景）

仅需要储藏部分文件、保留部分本地临时改动时，使用精细化储藏，避免无用代码一并储藏：

# 仅储藏指定文件
git stash save "【自选文件储藏】" 文件名1 文件名2

# 交互式选择性储藏（精准挑选代码块）
git stash -p

2.3 新建储藏并临时清理工作区

需快速清空本地工作区、切换其他任务，同时保留本次临时代码：优先使用标准带备注储藏。

3. 储藏列表查看与管理规范

多任务切换、多条储藏堆积时，必须先查看列表，精准识别每一条储藏对应的业务内容，避免恢复错误代码。

# 查看所有储藏列表（展示索引+备注）
git stash list

# 查看指定储藏详细改动内容
git stash show stash@{0}
git stash show -p stash@{0} # 查看完整代码改动详情

编号规则说明：stash@{0} 为最新一次储藏，序号越大储藏时间越早。

4. 储藏恢复规范（分场景执行）

根据是否保留历史储藏，区分两种恢复方式，杜绝代码丢失、重复叠加改动。

4.1 恢复并保留储藏记录（临时复用场景）

# 恢复最新储藏，保留原储藏记录
git stash apply

# 恢复指定索引储藏，保留原储藏记录
git stash apply stash@{0}

4.2 恢复并删除储藏记录（开发完成收尾·推荐）

恢复代码且确认无需二次复用，直接弹出并删除储藏，保持储藏列表整洁：

# 弹出最新储藏（恢复并删除）
git stash pop

# 弹出指定索引储藏
git stash pop stash@{0}

5. 储藏清理规范（定时运维·强制）

无效、过期、已废弃的储藏必须及时清理，避免长期堆积导致代码混淆、误恢复。

# 删除指定无效储藏
git stash drop stash@{0}

# 清空所有储藏（谨慎使用，确认全部无效后执行）
git stash clear

6. 多储藏冲突处理规范

多次储藏恢复出现代码冲突时，由当前开发者负责手动合并解决，梳理新旧改动逻辑，杜绝粗暴覆盖。
若改动重叠严重、逻辑混乱，优先废弃旧储藏，基于最新主干重新开发，保证代码整洁。
禁止强行恢复冲突储藏后直接提交MR，必须自测验证功能完整性。

7. 全场景红线禁忌（零容忍）

禁止无备注匿名储藏，导致后续无法识别储藏内容、造成代码废弃丢失。
禁止将调试代码、临时测试代码、错误代码储藏后长期留存，不做清理。
禁止未储藏本地改动直接切换分支、拉取代码，造成代码错乱、改动丢失。
禁止恢复过期废弃储藏，污染当前迭代代码。
禁止使用 stash 替代规范 commit，长期堆积半成品代码不闭环。

8. 高频场景标准操作流程（落地模板）

8.1 开发中临时切换任务流程

确认当前代码为半成品、未完成状态；
执行带备注stash储藏；
通过 stash list 确认储藏成功；
切换分支/同步主干/处理紧急任务；
回归原任务后，stash pop 恢复代码继续开发。

8.2 本地改动与主干基线冲突处理流程

储藏本地临时改动；
拉取主干最新代码同步基线；
恢复本地改动；
手动解决冲突、自测验证；
清理无效储藏记录。

9. 落地价值

彻底杜绝半成品代码误提交、误合并，保障代码仓库干净稳定；
支持多任务快速切换，提升迭代效率，避免代码丢失返工；
标准化备注管理，实现临时代码可追溯、可识别、可清理；
规避分支切换、基线同步带来的代码错乱、覆盖风险。

七、安全红线（严禁操作·零容忍强制规范）

本章为团队 Git 协作最高等级强制红线规范，所有规则零容忍、无特例，任何人不得违规操作。违规操作将造成代码泄露、数据安全事故、版本错乱、团队权限失控、线上故障等严重问题，一经发现需追责复盘、立即整改。所有开发者必须严格遵守，纳入日常代码规范考核。

1. 敏感信息安全红线（数据泄露零容忍）

严禁提交任何隐私敏感信息至代码仓库，包含但不限于：数据库账号密码、密钥、Token、Session、私钥、签名秘钥、服务器账号密码、OSS密钥、第三方应用授权凭证、本地环境隐私配置、内网地址端口、业务脱敏数据等。
严禁将生产环境配置、正式环境密钥写入代码、配置文件、注释中，所有敏感配置必须通过环境变量、配置中心、密钥托管服务统一管理。
若不慎提交敏感信息，禁止仅修改文件掩盖问题，必须立即清理 Git 全量历史记录、重置密钥、更新所有关联凭证，同步团队与运维人员排查风险。
严禁截图、复制代码仓库敏感提交记录对外传播，禁止私发仓库代码、分支内容、版本配置。

2. 仓库历史安全红线（版本稳定零破坏）

严禁重写、回滚、强制覆盖公共主干分支历史，包含 main/master、develop 等永久公共分支，禁止执行 rebase、reset、force 强制推送等高危操作。
严禁私自删除、移动、修改已合入主干的有效提交记录、版本标签，保证版本历史永久可追溯、不可篡改。
严禁基于老旧过期版本分支大规模开发合并，避免引入丢失代码、逻辑回退、功能降级风险。
严禁使用暴力强制推送覆盖远程分支代码，杜绝团队成员本地代码大面积丢失。

3. 分支与权限安全红线（仓库秩序零混乱）

严禁绕过分支保护、MR评审、CI校验，直接推送代码至公共主干分支。
严禁私自修改仓库权限、分支保护规则、MR审批规则、CI流水线配置，如需调整需报备技术负责人统一修改。
严禁多人共用临时开发分支长期迭代，避免代码权责混乱、无法追溯责任人。
严禁私自删除远程永久分支、历史版本标签，过期临时分支需经确认后统一清理。
严禁外接陌生设备、陌生账号登录企业代码仓库，禁止转借仓库账号、SSH密钥。

4. 代码内容安全红线（脏代码零入库）

严禁提交调试代码、测试死代码、注释残留代码、临时打印日志、无效占位代码至正式分支。
严禁提交未自测、未编译报错、功能不完整、存在明显BUG的半成品代码合入主干。
严禁提交硬编码参数、固定环境地址、写死密钥参数，所有可变配置统一抽离配置文件或配置中心。
严禁提交违规二进制大文件、冗余资源文件，大文件统一使用 Git LFS 托管，禁止占用代码仓库存储空间。
严禁夹带无关代码、私自优化、私自新增功能混入BUG修复迭代提交中。

5. 合并与评审安全红线（风险代码零上线）

严禁人情评审、走过场评审，明知代码存在风险、不规范、逻辑漏洞仍审批通过合并。
严禁紧急修复为由跳过自测、跳过评审、跳过CI校验直接合并上线。
严禁合并存在代码冲突、编译报错、单元测试失败、代码扫描阻断问题的MR。
严禁合并未关联任务、无说明、无测试场景的空白/模糊改动MR。

6. 本地操作安全红线（本地环境零风险）

严禁私自修改 .git 目录内部配置文件、篡改版本索引、手动修改提交记录哈希。
严禁本地随意重置、回退公共分支代码后强行推送远程。
严禁在生产服务器、测试服务器直接修改代码并提交至仓库，所有改动必须本地开发、走规范MR流程。

7. 事故兜底处置规范（违规必处置）

一旦触发安全红线操作，必须第一时间暂停迭代、同步技术负责人，快速评估影响范围，执行回滚、修复、密钥重置等兜底操作。
所有红线违规操作必须留存记录，完成问题复盘、原因分析、整改优化，杜绝二次违规。
因个人违规操作导致数据泄露、版本事故、线上故障，需承担对应团队考核责任。

8. 核心红线总结（极简记忆版）

不泄敏感、不改历史、不碰权限、不脏代码、不跳评审、不暴力推送、不私改配置、不违规合并。

八、工程化校验规范（可选落地·全自动强制合规）

人为规范存在疏漏风险，本章节提供全链路工程化自动化校验方案，通过工具拦截不规范操作，实现「代码提交、格式规范、信息规范、代码质量、合并准入、大文件管控」全流程自动校验，零人工干预落地所有Git协作规范。所有配置为团队通用标准，接入后全员统一生效，适配前端、后端、全栈各类项目，可按需模块化接入。

1. 整体校验架构（全链路拦截）

采用「本地前置拦截 + 流水线后置校验」双层校验机制，本地拦截低级违规、流水线兜底拦截遗漏问题，双重保障仓库代码合规：

本地Git钩子（Husky）：提交阶段实时拦截，禁止违规commit、违规代码入库
代码格式化校验（Prettier/ESLint）：统一代码风格，杜绝格式混乱
提交信息校验（Commitlint）：强制Conventional Commits规范，拦截无效备注
大文件管控（Git LFS）：拦截违规大文件、二进制文件提交
CI流水线兜底校验：MR阶段二次校验，拦截本地绕过校验的违规代码

2. 代码格式与语法校验（ESLint + Prettier）

统一团队代码编码风格与语法规范，杜绝个人编码风格差异，自动格式化、自动纠错、拦截严重错误。

2.1 核心校验能力

语法错误拦截：禁止存在编译报错、语法异常的代码提交
代码规范校验：统一缩进、空行、变量命名、注释规范
自动格式化：提交代码前自动修复格式问题，无需手动调整
冗余代码校验：检测未使用变量、死代码、无效导入

2.2 强制落地规则

所有代码格式问题自动修复、严重问题直接拦截提交
禁止手动规避格式化校验、禁止关闭校验规则
团队统一配置规则文件，纳入版本管控，全员强制同步

3. 提交信息自动化校验（Commitlint + Husky）

彻底杜绝无效提交备注、不规范提交格式，全自动校验提交语义，适配版本日志自动生成。

3.1 校验强制规则

强制校验提交类型，仅允许：feat/fix/docs/refactor/test/chore/perf
禁止无意义、模糊、过短的提交描述
禁止大小写不规范、语义混乱的提交信息
严格匹配「类型(模块): 描述」标准格式

3.2 交互式规范提交（Git-CZ）

接入git-cz实现交互式提交，无需手动记忆格式，全程选型式提交，从根源杜绝不规范备注。

4. 本地Git钩子拦截规范（Husky + lint-staged）

通过Git生命周期钩子，在commit、push关键节点自动执行校验，违规直接阻断操作，是本地合规的核心保障。

4.1 核心钩子执行逻辑

pre-commit：代码提交前，仅对本次修改文件执行ESLint+Prettier校验修复，高效提效
commit-msg：校验本次提交备注合法性，不规范直接拦截commit
pre-push：代码推送远程前，执行全量代码质量扫描、单元测试校验，拦截风险代码推送

4.2 落地强制要求

项目初始化必须安装husky钩子，禁止卸载、禁用钩子
禁止使用 --no-verify 跳过校验、绕过钩子拦截
lint-staged仅校验变更文件，兼顾规范与开发效率

5. 大文件合规管控（Git LFS 强制规范）

解决普通Git存储大文件导致仓库臃肿、克隆卡顿、版本冗余问题，统一二进制文件、静态资源管理规范。

5.1 强制托管文件类型

以下文件必须纳入Git LFS托管，禁止直接提交代码仓库：

图片资源：png/jpg/gif/svg/webp
媒体资源：mp4/mp3/wav
压缩包：zip/rar/gz/tar
二进制文件：exe/dll/so
大型静态资源、离线包、字体文件

5.2 红线规则

禁止10MB以上文件直接提交代码仓库，必须使用LFS
已违规提交的大文件需及时清理历史，避免仓库臃肿

6. CI/CD流水线兜底校验（MR阶段最终拦截）

针对本地绕过校验、钩子失效、本地环境配置差异问题，流水线做最终兜底校验，任意校验不通过直接禁止合并MR。

6.1 流水线强制校验项

代码格式化校验：全量代码格式校验，杜绝格式错乱
代码质量扫描：检测漏洞、冗余代码、安全风险、硬编码敏感信息
单元测试校验：单元测试通过率100%，禁止测试失败代码合并
提交历史校验：校验分支提交记录规范性，杜绝混杂、脏提交
构建打包校验：确保项目可正常编译、打包，无构建报错

6.2 流水线红线规则

流水线阻断性问题必须修复，禁止强制合并
警告类问题需评估说明，禁止堆积大量代码告警
每次MR必须触发全量校验，无特殊豁免场景

7. 自动化版本日志生成（工程化落地成果）

基于规范的提交记录，全自动生成CHANGELOG版本日志，无需人工整理迭代内容：

feat自动汇总新增功能
fix自动汇总修复问题
perf自动汇总性能优化
refactor/docs/chore分类汇总工程优化与文档更新

实现版本迭代日志标准化、自动化，适配版本复盘、迭代归档、用户更新说明输出。

8. 工程化校验落地优先级

基础必选：Husky + Commitlint（保障提交规范基线）
代码质量必选：ESLint + Prettier（统一代码风格、拦截语法错误）
资源管控可选：Git LFS（大文件较多项目强制接入）
进阶落地：CI流水线全量校验 + 自动CHANGELOG生成

9. 工程化校验红线禁忌

禁止删除、修改、屏蔽项目husky、commitlint、eslint校验配置
禁止使用 git commit --no-verify 跳过本地校验拦截
禁止绕过LFS直接提交大型二进制文件
禁止流水线校验失败后强制合并MR、跳过卡点
禁止个人本地单独修改校验规则，团队配置统一唯一

九、日常操作流程模板（全场景标准化·可直接落地复制）

本章汇总团队100%高频Git标准操作模板，适配主干开发（Trunk）与GitFlow两套分支模型，覆盖日常开发、Bug修复、线上热更、任务切换、冲突解决、历史整理、版本打标、环境排错全场景。所有流程统一步骤、统一命令、统一规范、可直接复制执行，杜绝个人随意操作，统一团队协作口径，降低操作失误率，新人可直接对照落地。

通用前置准则（所有流程必守）

所有操作执行前优先同步远程基线，杜绝滞后开发、大规模冲突；
严格遵循分支命名、提交备注规范，禁止自定义随意格式；
仅私有临时分支可执行rebase、历史整理、安全强推，公共永久分支禁止重写历史；
强制推送统一使用 --force-with-lease，禁用危险--force；
临时分支MR合并完成后，必须立即清理本地+远程分支，保持仓库整洁。

1. 主干开发（Trunk）全流程模板（敏捷迭代主力）

1.1 新功能开发完整流程（日常迭代）

适用：新增业务功能、页面开发、接口迭代、模块优化，短周期迭代场景

# 1. 前置准备：同步主干最新基线（必做）
git pull origin main

# 2. 创建规范功能分支
git switch -c feat/任务ID-功能简短描述

# 3. 开发迭代：小粒度规范提交（禁止大批量堆积提交）
git add 变更文件路径
git commit -m "feat(模块名): 具体功能改动描述"

# 4. 开发自测完成，二次同步基线，预处理冲突
git pull origin main

# 5. 冲突解决、功能自测通过后推送远程
git push origin feat/任务ID-功能简短描述

# 6. 平台提交MR，完善单据信息、关联任务、填写测试说明
# 7. MR评审通过、CI校验通过后Squash合并至主干
# 8. 合并完成，清理无效分支
git branch -d feat/任务ID-功能简短描述
git push origin --delete feat/任务ID-功能简短描述

1.2 测试/线上普通Bug修复流程

适用：自测Bug、提测Bug、线上非阻断性问题修复，遵循最小改动原则

# 1. 同步主干最新稳定代码
git pull origin main

# 2. 创建Bug修复专属分支
git switch -c fix/任务ID-问题简短描述

# 3. 精准修复问题，完成本地功能自测
git add .
git commit -m "fix(模块名): 修复xx场景下xx异常问题"

# 4. 同步基线、解决冲突、推送远程分支
git pull origin main
git push origin fix/任务ID-问题简短描述

# 5. 提交MR评审合并，合并后清理分支
git branch -d fix/任务ID-问题简短描述
git push origin --delete fix/任务ID-问题简短描述

1.3 线上紧急热修复流程（Hotfix）

适用：生产阻断性故障、核心功能报错、用户大面积无法使用等紧急场景，优先保障快速回稳、版本可追溯

# 1. 切回主干，同步线上最新稳定基线
git switch main
git pull origin main

# 2. 创建热修复专属分支，标注版本与问题
git switch -c hotfix/补丁版本号-问题简短描述

# 3. 最小改动修复故障，禁止附带无关优化、新增功能
git add .
git commit -m "fix(模块名): 紧急修复线上xx阻断性故障"

# 4. 自测+测试快速回归，推送分支走加急MR通道
git push origin hotfix/补丁版本号-问题简短描述

# 5. MR合并主干、线上验证修复生效
# 6. 主干打补丁版本标签归档
git tag -a 补丁版本号 -m "补丁版本｜线上故障修复｜上线日期"
git push origin 补丁版本号

# 7. 销毁临时热修分支
git branch -d hotfix/补丁版本号-问题简短描述
git push origin --delete hotfix/补丁版本号-问题简短描述

2. GitFlow 全流程模板（多版本并行/正式迭代）

2.1 功能开发迭代流程

适用：固定版本迭代、多环境并行、中长期功能开发

# 1. 同步开发主干基线develop
git pull origin develop

# 2. 从develop创建功能分支
git switch -c feat/任务ID-功能描述 develop

# 3. 分段开发、规范提交、自测验证
git add .
git commit -m "feat(模块): 新增xx功能能力"

# 4. 迭代完成，同步develop基线解决冲突
git pull origin develop

# 5. 推送远程、提交MR，Squash合并至develop
git push origin feat/任务ID-功能描述

# 6. 合并完成，清理临时功能分支
git branch -d feat/任务ID-功能描述

2.2 版本发布定型流程

适用：迭代收尾、版本定型、预发布测试、上线准备

# 1. 同步最新开发基线
git pull origin develop

# 2. 创建预发布版本分支
git switch -c release/v主版本.次版本.补丁版本 develop

# 3. 仅修复Bug、优化配置，禁止新增业务功能
# 4. 测试全量回归，问题修复后规范提交

# 5. 测试通过，双向合并至master与develop
# 6. master分支打正式版本标签归档
# 7. 销毁release临时分支
git branch -d release/v主版本.次版本.补丁版本

2.3 GitFlow 线上热修复流程

# 1. 同步生产主干master
git switch master
git pull origin master

# 2. 基于线上稳定版本创建热修分支
git switch -c hotfix/版本号-问题描述 master

# 3. 精准修复线上问题并自测
git add .
git commit -m "fix(模块): 修复线上xx致命问题"

# 4. 分别合并至master(上线)、develop(同步迭代)
# 5. master更新补丁版本标签
# 6. 清理hotfix临时分支

3. 高频通用场景标准流程（两套模型通用）

3.1 任务临时切换/半成品储藏流程

适用：开发中途暂停、临时修Bug、紧急任务插入、基线同步，杜绝半成品代码丢失、污染分支

# 1. 查看本地改动，确认半成品状态
git status

# 2. 标准带备注储藏（禁止匿名储藏，可追溯）
git stash save "【任务ID】未完成：xx功能开发，临时暂停"

# 3. 查看储藏列表，确认保存成功
git stash list

# 4. 执行任务切换/基线同步/紧急Bug修复
git pull origin main

# 5. 回归原任务，恢复代码并清理储藏记录
git stash pop stash@{0}

3.2 私有分支代码冲突解决流程（标准变基）

适用：个人特性分支同步基线产生冲突，保证主干历史线性干净

# 1. 切换至当前开发的私有分支
git switch 私有分支名

# 2. 变基方式同步主干最新代码（优先推荐，线性历史）
git pull --rebase origin main

# 3. 逐文件解决冲突，保留双方有效业务逻辑，禁止粗暴覆盖删除
# 4. 单文件冲突解决后，加入暂存区
git add 冲突文件路径

# 5. 继续完成变基流程
git rebase --continue

# 异常回退：变基出错、冲突复杂可终止重来
git rebase --abort

# 6. 全部冲突解决完毕，安全推送远程私有分支
git push origin 私有分支名 --force-with-lease

3.3 MR前提交历史整理流程（仅私有分支可用）

适用：开发完成后合并零散提交、修正错误备注、清理无效提交，保证合入主干历史整洁规范

# 1. 查看当前分支简短提交历史
git log --oneline

# 2. 交互式整理最近N条提交记录
git rebase -i HEAD~N

# 操作指令说明：
# pick 保留当前提交
# squash 合并当前提交至上一条
# reword 修改提交备注
# drop 删除无效、调试、临时提交

# 3. 整理完成后，安全强推更新远程私有分支
git push origin 私有分支名 --force-with-lease

3.4 本地错误提交修正流程（未推送远程专用）

仅本地未推送远程的错误提交可修正，已推送远程禁止重写历史，只能新增修复提交

# 1. 修改上一次提交的备注信息
git commit --amend

# 2. 补充遗漏代码、修复局部问题，合并至上一次提交（不新增记录）
git add .
git commit --amend --no-edit

3.5 生产版本打标归档流程（统一标准）

所有线上正式上线完成后，必须立即打版归档，保证版本可追溯、可回滚、可审计

# 1. 切换主干并同步最新上线代码
git switch main
git pull origin main

# 2. 创建规范附注版本标签（必填清晰备注）
git tag -a v1.2.3 -m "v1.2.3｜新增xx功能、修复xx线上问题｜2026-06-26 正式上线"

# 3. 推送远程永久归档
git push origin v1.2.3

3.6 本地环境排查与异常修复流程

适配配置错乱、忽略失效、代码异常、基线不一致等日常排错场景

# 1. 全量排查本地Git配置（定位配置错乱问题）
git config --list --show-origin

# 2. 修复gitignore忽略规则失效问题
git rm --cached -r .
git add .

# 3. 图形化查看分支历史，追溯问题提交节点
git lg

# 4. 废弃本地所有改动，强制同步远程主干最新基线（谨慎使用）
git reset --hard origin/main