Git 协作与提交边界

Git 的价值不只是保存代码版本，更是让团队能回答：改了什么、为什么改、如何验证、出问题怎样回退。好的协作习惯从控制一次提交的边界开始。

一个提交只完成一个可描述的变化

理想提交能用一句动词开头的话说明，例如“补充订单取消的权限校验”或“调整文章列表的空状态”。格式化、重命名和行为修改最好拆开，否则评审和回滚都会变困难。

好：修复筛选条件切换后旧请求覆盖结果
差：修改页面、接口、样式和配置

提交前检查暂存区，而不是默认把整个工作区都加入。这样能避免调试文件、个人配置和无关修改混入历史。

分支表达工作目的

功能、修复和实验应在独立分支完成。分支名称包含日期或任务语义，让其他人能迅速判断它的背景；长期分支定期合入主线，减少最后一次合并的冲突规模。

时机	建议动作
开始一项独立需求	从最新主线创建功能分支
发现无关改动	暂存、拆分或与负责人确认
准备评审	整理提交、补足验证说明
合并后出现问题	用小提交定位并可控回退

评审的是行为，不只是代码风格

提交描述应包含改动原因、影响范围和验证方式。评审时优先检查输入边界、权限、失败路径、数据一致性和兼容性；格式问题交给自动化工具。

提交前的最小清单

• git status 确认暂存区只有本次改动。
• 查看 diff，重点检查删除、配置和敏感信息。
• 运行与改动相称的构建、测试或静态检查。
• 提交说明写明结果与原因，而不是只写“update”。

小而完整的提交会成为未来排障、回滚和理解系统的可靠路标。