合规feature分支必须从最新develop拉取，命名格式为feature/xxx-yyy，推送时设置上游；commit需以feat:/fix:/refactor:等前缀开头；pr前须rebase -i origin/develop线性化历史；合并前必跑go test ./...和golangci-lint run。
feature分支必须从develop拉，不能从master或别人未合入的feature分支拉——否则大概率在合入时触发不可控冲突，且破坏版本演进逻辑。
如何创建合规的feature分支
关键不是“能不能切”，而是“从哪切、怎么命名、是否同步上游”。Go项目协作中，develop是唯一可信的开发基线，所有新功能都应基于它：
- 先确保本地
develop最新：git checkout develop && git pull origin develop - 再新建并切换分支：
git checkout -b feature/user-login-jwt（命名含feature/前缀，用短横分隔，不带空格） - 推送时显式设置上游：
git push --set-upstream origin feature/user-login-jwt，避免后续git push失败
如果跳过第一步直接从旧develop或master拉，你的分支会缺失近期提交，等合并回develop时，Git可能把别人已合入的代码也当成“你的变更”来处理，导致误覆盖或冲突放大。
commit message为什么必须带Type:前缀
Go项目（尤其开源库如golang/go）依赖结构化提交信息驱动自动化流程，比如生成changelog、触发CI构建策略、过滤PR标题。不规范的message会让CI跳过测试或被维护者直接忽略：
- 必须以
Type:开头，常见值：feat（新功能）、fix（bug修复）、refactor（重构），test（测试） - 冒号后紧跟短横+描述，例如：
feat: add jwt token validation for user login - Body部分可选，但若涉及接口变更或breaking change，必须说明影响范围，比如
Breaking: User.LoginRequest now requires non-empty Token field
注意：GoLand默认提交框不校验格式，需手动填写；golangci-lint本身不检查commit，但CI脚本（如GitHub Actions）常集成commitlint做预检。
git rebase -i origin/develop不是可选项
在向develop发起PR前，必须将本地feature分支历史线性化并清理掉调试用的临时提交（如fix typo、try again）。直接merge会产生多余merge commit，污染主干历史：
- 执行
git rebase -i origin/develop后，编辑器会列出你所有未合入的提交，把想压缩的行前改为s（squash）或f（fixup） - 重写后的提交必须语义清晰、粒度合理——一个提交只做一件事，比如“实现JWT签发逻辑”或“添加单元测试覆盖RefreshToken路径”
- 如果rebase过程中出现冲突，解决后
git add . && git rebase --continue，切勿git commit或git merge
这步容易被跳过，但后果严重：多人并行开发时，未经rebase的feature分支一旦合入，会把其他人的提交也拖进你的PR diff里，审查者根本无法聚焦真实变更。
合并前必须跑通go test ./...和golangci-lint run
Go项目对代码质量卡得严，很多仓库CI配置了go vet、staticcheck、errcheck等插件。本地没跑就推，等于把失败留给CI，拖慢整个团队节奏：
- 运行
go test ./...确保所有包测试通过，特别注意新增代码是否覆盖了边界case（如空输入、超长token） - 运行
golangci-lint run --fast检查风格与潜在bug，重点看nil指针、未关闭的io.Closer、错误未处理等高频问题 - 如果项目启用了
go mod vendor，确认vendor/目录已更新（go mod vendor），否则CI可能因依赖路径不一致失败
最常被忽略的是测试覆盖率断言——有些项目CI要求新增代码行覆盖率≥80%，但go test -cover默认不递归子包，需明确用go test -coverprofile=coverage.out ./...生成报告再检查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
