小张刚进公司第三天，就被组长拉进一个叫「main 分支」的群里，消息刷得飞快：「已合并到 main」「CI 通过，准备上线」……他盯着自己本地 git status 显示的 feature/login 页面，有点懵：这 main 到底是啥？为啥大家都不在自己的分支上多待几天？
主干开发，不是“只用一个分支”那么简单
主干开发（Trunk-Based Development，简称 TBD），核心不是禁止建分支，而是限制长期存在的功能分支。它要求开发者每天至少一次把代码推送到主干（通常是 main 或 master），而不是攒一周再提个 500 行的 PR。
举个生活化的例子：就像合租厨房——没人单独划一块地盖个小灶台慢慢炖汤；大家共用一口锅，每人每次只加一小勺料、搅匀、尝味，保证整锅汤始终可喝、不出问题。
动手试试：三步跑通最简主干流程
假设你本地有个空项目，已经初始化了 Git：
git init
git remote add origin https://github.com/yourname/myapp.git第一步：确保主干干净起步
新建一个空的 main 分支并推上去：
git checkout -b main
echo "# My App" > README.md
git add README.md
git commit -m "init: add README"
git push -u origin main第二步：写点代码，立刻合入
别建 feature/login 分支了，直接在 main 上改：
echo "const login = () => console.log('logged in');" > auth.js
git add auth.js
git commit -m "feat: add basic login function"
git push看到没？没有 PR，没有 Code Review 等待，但前提是——你本地测试过了，而且团队约定好：谁提交，谁负责本地验证 + 过 CI。
为什么新手容易踩坑？
常见误区是以为「主干开发 = 不用分支」。其实你会频繁用临时分支，比如修线上 bug：
git checkout -b hotfix/500-error main
# 改一行代码，测试通过
git commit -m "fix: prevent null crash in api handler"
git push origin hotfix/500-error
git checkout main
git merge hotfix/500-error
git push
git branch -d hotfix/500-error关键在于：这个 hotfix 分支生命周期可能就 10 分钟，改完立刻合回 main，不挂三天等审批。
配套习惯，比命令更重要
主干开发能跑起来，靠的是三个“小而硬”的配合：
- 自动化测试必须有：每次 push 都触发单元测试 + 接口测试，失败自动拒收；
- 小批量提交：一次改 20 行，别一次塞 200 行新逻辑；
- 每日同步主干：早上上班第一件事，
git pull origin main，别让本地落后超过半天。
如果你现在用的是 GitHub，打开 Settings → Branches → Branch protection rules，勾选「Require status checks to pass before merging」，再填上你的 CI 任务名（比如 test），这就搭出了主干开发的第一道护栏。