Git 是 DevOps 流程中唯一被所有角色共同依赖的代码状态权威源，而非普通工具链一环；其分支策略、Hooks、子模块/子树等实践需匹配团队交付频率、自动化水平与协作模式。
Git 不是 DevOps 的“一部分”，而是整个流程里唯一被所有角色共同依赖的代码状态权威源。没有 Git，CI/CD 流水线不知道该构建哪个提交，SRE 无法追溯配置变更，开发无法安全并行，测试无法复现环境——它不是工具链中的一环，而是地基。
Git 分支策略怎么选：main / develop / feature 还是 trunk-based development？
选错策略会导致 PR 堆积、合并冲突频发、发布节奏失控。关键不是“哪种更先进”，而是看团队交付频率和测试自动化程度：
- 如果 CI 流水线能在
5 分钟内完成构建 + 单元测试 + 集成测试，且每个feature提交都带可开关的特性标志（feature flag），trunk-based development (TBD)是更轻量的选择；此时只保留main分支，所有功能直接向main提交，靠自动化 gate 控制质量 - 若测试周期长（>15 分钟）、上线需人工审批、或存在多版本并行维护（如 v2.1 和 v3.0 同时迭代），则
git flow衍生策略更可控：用release/v2.1分支冻结测试，hotfix/分支快速修线上问题，避免污染main - 注意：
develop分支在现代 CI 实践中容易成为“第二个 main”，导致开发者习惯性 push 而不触发完整流水线——除非你明确要求develop必须通过全部测试才能合入，否则不如去掉
Git Hooks 在 CI/CD 中的真实作用边界
pre-commit 和 pre-push Hook 只能做本地守门人，不能替代 CI 流水线。它们的价值在于把低级错误拦截在提交前，减少无效构建浪费：
-
pre-commit适合运行eslint、go fmt、black等秒级检查，但绝不应调用docker build或远程 API；否则开发者会禁用它 -
pre-push可校验分支命名是否符合规范（如必须匹配feature/xxx或hotfix/yyy），防止误推main；但不能做代码扫描——扫描必须由 CI 在干净环境中执行 - 注意：
husky或pre-commit框架安装后不会自动同步到所有协作者，必须写进README.md并在 CI 中加一道检查：“git ls-files .husky/非空”，否则团队实际使用率趋近于零
Git 子模块（submodule）与子树（subtree）在微服务中的取舍
当多个服务共享一套通用工具库（如日志封装、认证 client），是否该拆成独立仓库？拆了就面临依赖管理问题：
-
git submodule让主仓库只存子仓库的 commit hash，好处是版本精确、各服务可锁定不同版本；坏处是克隆时默认不拉子模块（需git clone --recurse-submodules），CI 脚本必须显式git submodule update --init，漏掉就编译失败 -
git subtree把子项目历史合并进主仓库目录，操作像普通文件，CI 无需额外指令；但升级依赖时要手动git subtree pull，且无法同时追踪多个子项目分支 - 更务实的做法：对强耦合基础库（如内部 RPC 协议生成器），用
subtree降低协作门槛；对弱耦合组件（如 UI 组件库），发布为npm/pip包，Git 只管源码，包管理器管版本——这才是 DevOps 中“关注点分离”的真实体现
Git 的复杂性从来不在命令本身，而在于它被迫承载了权限控制、环境隔离、发布节奏、回滚能力等本该由其他系统分担的责任。一旦开始用 git blame 查谁改坏了生产配置，或靠 git revert 救火而不是从流水线重跑，就说明 Git 正在替缺失的环节背锅。
