你刚改完一段前端样式，顺手敲下 git push，还没来得及切回聊天窗口跟同事说“我推了”，测试环境已经刷新出最新页面。这种“丝滑”的体验背后，其实是部署流水线在默默工作——而它的起点，往往就是一次普通的代码提交。
代码提交，不只是上传文件
很多人以为 git push 只是把代码扔到远程仓库。但在现代开发流程里，这一步更像是按下了“启动键”。只要仓库配置了 CI/CD 工具（比如 Jenkins、GitLab CI 或 GitHub Actions），系统就会立刻感知到新提交，并自动触发预设的部署流水线。
怎么知道该不该触发？靠的是“钩子”
远程仓库支持一种叫 Webhook 的机制。你可以把它理解为一个“通知电话”。当你向 main 分支提交代码时，仓库会立刻打一通“电话”给 CI 服务器，说：“有新代码来了，按流程走吧。”
这个 Webhook 通常在项目设置里配置，指定触发条件，比如只监听 main 分支的推送，或者只在合并 Pull Request 时启动。
一个简单的 GitHub Actions 示例
下面是一个典型的配置文件，放在项目根目录的 .github/workflows/deploy.yml 中：
name: Deploy on Push
on:
push:
branches:
- main
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Install dependencies
run: npm install
- name: Build project
run: npm run build
- name: Deploy to server
run: scp -r dist/* user@server:/var/www/html只要有人向 main 分支提交代码，GitHub 就会自动运行这个流程：拉代码、装依赖、打包、上传到服务器。全程无需人工干预。
公司内网也能玩这套
有些团队用的是自建 Git 服务，比如 GitLab 搭在办公网络内部。同样可以配置本地 Runner 执行任务。代码提交后，内网的 Jenkins 机器收到通知，拉取最新版本，跑测试、生成包，再推送到测试服务器。整个过程发生在局域网，速度快，也更安全。
运维同事再也不用半夜被叫起来“手动发个版”，开发也不用等别人帮忙部署看效果。写完就能测，发现问题立马修，再提交，流程再次自动跑起。
不是所有提交都该触发部署
有时候你只是提交了个文档更新，比如改了 README.md，这时候没必要跑全套构建。可以在配置里加过滤规则：
on:
push:
branches:
- main
paths:
- '**/*.js'
- '**/*.css'
- 'package.json'这样只有当 JavaScript、CSS 或配置文件变动时，才会真正触发流水线，避免资源浪费。
现在越来越多团队把“代码提交即部署”当成标准操作。它不只是技术升级，更改变了协作方式：每个人都能快速验证自己的改动，反馈周期缩短，项目推进自然更快。”}