28、Git与敏捷开发：Scrum中的Git实践、持续集成、持续交付、DevOps流程
聊到Git和敏捷开发，我得先说说自己的体会。刚入行那会儿，我以为Git就是个存代码的工具。后来带团队做Scrum，才真正明白——Git是敏捷的血管，CI/CD是心跳，DevOps是呼吸。这三者缺一个，项目就容易「缺氧」。
说白了，这一章就是讲怎么把Git嵌入到敏捷开发的每个环节里。不是让你背命令，而是让你理解：什么时候该分支，什么时候该合并，什么时候该触发自动化流水线。
Scrum中的Git实践：分支策略与协作节奏
Scrum有Sprint，有每日站会，有评审和回顾。Git怎么配合？我个人的经验是：分支策略必须匹配迭代节奏。
举个例子。我们团队用Scrum，每个Sprint两周。一开始大家各自在master上改，结果冲突不断，合并时像拆炸弹。后来我引入了功能分支 + 发布分支的模式，情况才好转。
推荐的分支模型
| 分支类型 | 用途 | 生命周期 |
|---|---|---|
main |
生产就绪代码 | 永久 |
develop |
集成开发分支 | 永久 |
feature/* |
每个用户故事 | Sprint内 |
release/* |
Sprint发布准备 | 发布前 |
hotfix/* |
紧急修复 | 按需 |
每个Sprint开始，我们从develop拉出feature/xxx分支。开发完成后，提Pull Request，代码评审通过后合并回develop。Sprint结束前，从develop拉出release/x.y.z分支，只修bug，不加新功能。
核心原则：main永远是可部署状态。develop是下一个Sprint的集成地。功能分支是隔离的沙箱。
我曾经遇到一个坑：有个同事直接在develop上改代码，结果Sprint中途要发布一个紧急补丁，develop里全是未完成的功能，根本不敢合并到main。嗯，从那以后我定了个规矩——develop分支禁止直接push，只能通过PR合并。
持续集成：让Git成为自动化的触发器
持续集成（CI）说白了就是：你每次push代码，机器自动帮你跑测试、检查代码风格、构建项目。我见过太多团队「写完代码扔一边，上线前才集成」，结果呢？集成那天就是灾难日。
Git和CI的配合其实很简单：用Webhook监听push事件。你推代码到远程仓库，CI服务器（比如Jenkins、GitLab CI、GitHub Actions）自动拉取最新代码，执行预设的流水线。
一个典型的CI流水线
# .gitlab-ci.yml 示例
stages:
- lint
- test
- build
lint-job:
stage: lint
script:
- npm run lint
test-job:
stage: test
script:
- npm test
build-job:
stage: build
script:
- npm run build
only:
- main
你想想看，每次PR合并前，CI自动跑一遍测试。如果测试失败，PR就不能合并。这相当于给代码质量上了道保险。
我的习惯：在PR模板里加一个checklist，要求开发者确认CI通过后再请求评审。这样能减少「CI红了还让人review」的尴尬情况。
持续交付：从Git到生产环境的自动化管道
持续交付（CD）是CI的延伸。CI保证代码没问题，CD保证代码能随时部署到生产环境。我参与过一个项目，从代码提交到上线只需要15分钟——全靠Git触发的自动化流水线。
CD的核心是部署流水线。每次合并到main分支，自动触发构建、测试、打包、部署到预发布环境。确认没问题后，一键部署到生产环境。
Git标签与版本管理
我建议用Git标签来标记版本。每次发布时，打一个语义化版本标签：
git tag -a v1.2.3 -m "Release version 1.2.3"
git push origin v1.2.3
CD流水线可以监听标签事件。比如GitLab CI里这样写：
deploy-production:
stage: deploy
script:
- ./deploy.sh production
only:
- tags
这样一来，只有打了标签的提交才会部署到生产环境。既安全又清晰。
注意：不要手动在服务器上改代码。我曾经见过有人直接在服务器上修改配置文件，结果下次部署时被覆盖了。所有变更必须通过Git，这是底线。
DevOps流程：Git作为单一事实来源
DevOps强调开发（Dev）和运维（Ops）的协作。Git在这里扮演什么角色？单一事实来源。代码、配置、基础设施定义（IaC）、流水线定义——全都存在Git仓库里。
我团队的做法是：
- 应用代码：存在
app/目录 - Dockerfile和K8s配置：存在
deploy/目录 - Ansible/Terraform脚本：存在
infra/目录 - CI/CD流水线定义：存在
.gitlab-ci.yml或.github/workflows/
所有变更都走Git工作流：提PR、评审、合并、自动部署。运维人员不再需要SSH到服务器改配置，开发人员也不再需要「帮我部署一下」这种口头沟通。
GitOps：用Git管理整个基础设施
GitOps是DevOps的一个演进方向。核心思想是：Git仓库里描述的目标状态，就是系统应该达到的状态。有个Operator（比如Argo CD）不断对比Git里的配置和实际运行状态，发现不一致就自动纠正。
举个例子。你修改了K8s的Deployment副本数，从3改成5，提交到Git。Argo CD检测到变化，自动执行kubectl apply，把集群里的副本数调整到5。整个过程不需要任何人登录服务器。
一句话总结：Git是声明式配置的存储库，自动化工具负责让现实符合预期。
知识体系总览
下面这张图是我梳理的本章核心逻辑。你可以看到Git如何贯穿Scrum、CI、CD和DevOps的每个环节。
你看，Git不只是版本控制工具。在敏捷开发里，它是协作的枢纽；在CI/CD里，它是自动化的触发器；在DevOps里，它是配置的权威来源。说白了，Git就是整个研发流程的「脊椎」。
最后分享一个经验：刚开始推行这些实践时，别追求一步到位。先搞定分支策略，再接入CI，然后逐步加上CD和GitOps。我见过最成功的团队，都是「小步快跑，持续改进」的。
公众号:蓝海资料掘金营，微信deep3321