引言：从混乱提交到工程化协作

在多人在线服务器项目中，一个看似简单的需求往往跨越多个模块：数据库结构、核心逻辑、脚本配置。当团队成员在同一仓库中协作时，提交信息混乱、分支策略随意，会让 code review 变得痛苦，甚至引入难以追踪的回归。本文将围绕 Git 提交规范与分支协作，构建一套适用于团队（尤其是 AzerothCore / TrinityCore 这类大型 C++ 与脚本混编项目）的工程化工作流。

提交信息规范：让历史可读、可检索、可回溯

规范的提交信息是高效协作的地基。推荐采用 Conventional Commits 风格，统一使用 feat、fix、refactor、docs、test、chore 等类型前缀，并配合作用域与描述。

feat(core): 为坐骑模块增加飞行校验
fix(db): 修正坐骑 DBC 中种族限制字段
refactor(scripts): 重构骑乘状态机的状态切换
docs: 更新坐骑开发文档

类型 + 作用域 + 简洁描述的组合，让 git log --oneline 在几秒内就能定位目标改动，也方便后续自动生成 changelog。

分支模型：主干开发 + 功能分支

对于中小团队，不必引入复杂的 Git Flow，采用基于主干（trunk-based）的轻量分支模型即可：所有新功能在独立的 feature 分支上开发，通过 Pull Request / Merge Request 合并到主干。

# 从最新主干创建功能分支
git checkout main
git pull origin main
git checkout -b feature/mount-system

# 提交并推送到远程
git add .
git commit -m "feat(mount): 实现坐骑骑乘与下马状态机"
git push origin feature/mount-system

这种模型让主干始终保持可发布状态，每个功能分支职责单一，reviewer 也能在小范围内快速理解改动。

Rebase 与 Merge：保持历史整洁

合并前用 rebase 让分支基于最新主干，避免大量 merge commit 造成的历史噪音。但要注意：rebase 只用于本地或尚未共享的分支；已推送到远程并被他人使用的分支应使用 merge。

# 基于最新主干并整理提交
git fetch origin
git rebase origin/main

# 交互式整理提交
git rebase -i HEAD~3
# 将多个小提交合并为一个有意义的提交

用 git rebase -i 可以将若干零散提交 squash 成单一语义完整的提交，配合规范提交信息，形成清晰的历史线。

Code Review 与保护分支

在远程仓库上配置分支保护规则：主干禁止直接推送，必须通过合并请求并至少获得一位 reviewer 的批准。这样能拦截大部分低质量改动，让规范真正落地。

# 提交前运行测试与格式检查
make check
# 或
./run_tests.sh

# 确保不提交临时文件
git status
git diff --check

建议在 CI 中集成提交规范校验（如 commitlint）、静态检查与单元测试，形成”提交即验证”的反馈闭环。

结语

规范的提交信息、清晰的分支模型、克制的 rebase 使用与强制 review，共同构成可持续的协作工作流。对服务器开发团队而言，这不仅能减少合入冲突，还能让每一次改动都可追溯、可回滚，显著提升长期维护效率。好的 Git 习惯，是对代码库未来的一种投资。