git无法保证接口定义一致，因其仅比对文件字节或行级差异，不理解代码语义：同名接口因路径、包名、导入不同即被视为不同文件；逻辑不兼容但注释改动则被判定无冲突，导致运行时panic。
跨组织 Git 合并本身不提供接口定义或代码规范校验能力——它只做内容合并，不关心语义一致性。所谓“一致性”必须靠外部机制保障，不是 git merge 或 git cherry-pick 能解决的问题。
为什么 git 无法保证接口定义一致
Git 是内容快照系统，只比对文件字节或行级差异。两个组织各自定义的 UserService 接口，哪怕方法签名完全相同，只要文件路径、包名、导入语句不同，Git 就认为是“不同文件”；反之，若仅注释改动但逻辑已不兼容，Git 也认为“无冲突”。
典型场景：
• A 组织的 api/v1/user.go 返回 CreatedAt string
• B 组织同名接口返回 CreatedAt time.Time
Git 合并时不会报错，但运行时 panic。
必须配套的三类强制检查点
要让跨组织合并“安全”，得在 Git 流程外加三层拦截：
- CI 阶段跑契约测试：用
OpenAPI或Protobuf定义服务契约，合并 PR 前比对接口变更是否向后兼容（工具如openapi-diff、protoc-gen-validate） - 静态扫描强制统一 import 路径：比如要求所有 Go 接口必须从
github.com/orgname/api/v2导入，用gofumpt+ 自定义 linter 拦截非法路径 - 提交前 hook 校验 commit message 格式：跨组织协作必须用 Conventional Commits，且
feat(api): add user search这类 message 要能被自动化解析出影响模块，触发对应接口的回归验证
合并时最容易忽略的兼容性陷阱
很多人只关注函数签名，却漏掉这些隐性破坏点：
- 枚举值增删：A 组织新增
UserStatusArchived，B 组织未同步 enum 定义，JSON 反序列化直接失败 - 字段 tag 差异：Go struct 中
json:"user_id"vsjson:"userId"，看似小写/驼峰差异，但下游 SDK 生成会彻底错乱 - 错误码范围重叠：双方都用 HTTP 400 表示参数错误，但 A 组织扩展了
X-Error-Code: 4001，B 组织没约定就复用同一码值，导致错误归因混乱 - 依赖版本锁死不一致：
go.mod中github.com/some/lib v1.2.0和v1.2.1看似小版本，但若该 lib 的接口在 patch 版本做了破坏性变更（常见于未遵循 semver 的私有库），合并后编译通过、运行崩溃
真正起作用的从来不是分支怎么合，而是合之前有没有把接口契约、类型定义、错误体系、依赖约束这四层钉死在 CI 流水线里。Git 只负责搬砖，砖缝里要不要加钢筋，得靠你亲手焊。
