git-workflow-and-versioning

name	git-workflow-and-versioning
description	Trunk-based development with atomic commits. Use when making any code change (always).

Git 工作流与版本管理

概述

基于主干开发（Trunk-based Development）与原子化提交的最佳实践。始终保持提交小而聚焦，频繁集成到主干。

何时使用

• 任何时候进行代码变更——这是日常开发的必备技能
• 提交代码、创建 PR 或合并分支时
• NOT for 管理发布版本（使用语义化版本控制）

核心流程

1. 主干开发：从主分支创建短生命周期特性分支（存活不超过 1-2 天）
2. 原子化提交：每个提交只做一件事——一个 Bug 修复、一个特性、一个重构，绝不混杂
3. 提交信息格式：

   <type>: <简短描述>
   
   <可选详细说明>
   

   类型：feat/fix/refactor/chore/docs/test/style
4. 提交即保存点（Commit-as-Save-Point）：在特性分支上频繁提交——把提交当作保存点，方便回溯和分步审查
5. 提交规模：每次提交约 100 行变更——超过 300 行应考虑拆分
6. 每日合并：每天至少合并一次主分支变更到特性分支，减少冲突
7. 永不强制推送：绝对不对共享分支（main、develop）执行 git push --force。使用 --force-with-lease 做必要修复

常见自我合理化

合理化	现实
这个改动太小不值得单独提交	没有"太小"的提交——原子化提交提升可追溯性
先写完所有代码再一次性提交	大提交难以 Review 和回滚——提交即保存点
我直接 push --force 修复一下	永远不要在共享分支上 force push——会毁掉别人的历史
明天再合入主分支也一样	每天合并减少冲突——不合并风险越大
提交信息随便写反正没人看	提交信息是给未来自己看的代码文档

红旗标志

• 提交包含超过 300 行变更
• 提交信息是 "fix"、"update" 或空
• 特性分支存活超过 3 天
• 在共享分支上使用 git push --force
• 一次提交包含多个无关功能的修改
• 合并冲突时覆盖他人代码

验证清单

• 每个提交只包含一个逻辑变更
• 提交信息遵循 <type>: <描述> 格式
• 提交变更量在 100 行左右，不超过 300 行
• 特性分支存活不超过 2 天
• 每天从主分支拉取最新变更
• 从不 force push 到共享分支
• PR 回顾提交历史清晰可追踪