分支命名要清晰，别让人猜谜
在后端项目里，多人协作是常态。如果某天你看到分支名是 fix、test 或者 zhangsan_dev，是不是一头雾水？这类命名等于没写。
推荐用前缀 + 描述的方式，比如：
feature/user-login—— 新增用户登录功能bugfix/order-status—— 修复订单状态更新异常hotfix/payment-timeout—— 紧急修复支付超时问题refactor/db-query—— 重构数据库查询逻辑
这样一看就知道这个分支干啥的，合并时也不容易搞混。
提交信息不是随便写几个字
很多人提交代码只写“修改”、“更新”或者“fix bug”，这种信息对排查问题毫无帮助。
一个合格的 commit message 应该说明“做了什么”和“为什么做”。例如：
feat(order): add retry logic for payment timeout
When payment request times out, automatically retry up to 3 times.
This reduces failed orders due to transient network issues.再比如一个修复类提交：
fix(invoice): prevent null pointer when user has no billing address
Check if billing address exists before accessing fields.
Fixes #1245这样的记录，几个月后回溯日志时也能快速定位上下文。
小步提交，别堆大包
有人习惯攒一天的改动一次性提交，几百行代码塞在一个 commit 里。一旦出问题，根本没法精准回滚。
正确的做法是：改一点，测一点，提交一点。比如你加了个接口，又改了校验逻辑，还调了超时时间，那就分三个 commit 提交，每个专注一个变更点。
这样别人 review 代码轻松，CI/CD 出错也能快速定位。
合并请求要有仪式感
在 GitLab 或 GitHub 上提 Merge Request 不是点了按钮就完事。标题要简洁明确，描述里写清楚改动范围、影响模块、是否需要配置变更。
如果有测试截图或日志片段，也可以贴上。别让 reviewer 自己去翻代码猜意图。
另外，记得关联相关 Issue 编号，比如 Closes #789，这样任务闭环更清晰。
保护主干分支，别直接 push
main 或 master 分支必须设为受保护分支，禁止直接推送。所有变更必须通过 MR/PR 经过至少一人 review 才能合入。
可以设置 CI 检查通过才允许合并，比如单元测试、代码格式检查、安全扫描等。这就像家门口装个门禁，外人不能随便进。
合理使用 .gitignore
后端项目常生成日志、临时文件、本地配置，比如 logs/、.env.local、node_modules/ 或 target/，这些都不该进仓库。
项目初始化时就把通用忽略项加好，避免误提交敏感信息或巨量无用文件。常见内容如下：
# 忽略本地环境配置
.env.local
config/local.php
# 忽略日志
logs/*.log
*.log
# 忽略依赖包
node_modules/
vendor/
target/
# IDE 临时文件
.idea/
.vscode/
*.swp标签管理版本发布
每次上线生产环境，打个 tag，比如 v1.4.0，方便后续追踪和回滚。
可以用语义化版本规则：v<主版本>.<次版本>.<修订号>。功能新增升次版本，bug 修复升修订号，架构调整升主版本。
查看历史发布版本时，直接 git tag -l 就能列出所有节点，比翻提交记录高效多了。
定期清理过期分支
功能上线后，对应的 feature 分支就可以删了。很多人图省事留着，结果仓库里一堆“僵尸分支”，看着像废弃项目。
建议 MR 合并后自动删除源分支，GitLab 和 GitHub 都支持这个选项。本地也定期执行：
git fetch --prune
git branch -vv | grep ": gone]" | awk '{print $1}' | xargs git branch -d清理掉那些远程已删除的本地跟踪分支。