刚接触软件开发时，很多人会被各种分支、合并、提交搞得晕头转向。你可能在公司第一次拉代码，看到同事说‘去主干上提PR’，却不知道主干到底是什么。其实，主干开发（Trunk-Based Development）没那么神秘，它是一种被很多大厂采用的协作方式，掌握它，能让你更快融入团队节奏。
什么是主干开发？
简单来说，主干就是项目默认的主分支，通常叫 main 或 master。所有人的代码最终都要合到这条线上。和动不动就建十几个长期分支的做法不同，主干开发强调小步快跑——功能拆小，频繁提交，尽早合并。
比如你加一个登录按钮，不用等整个登录流程做完才提交。先把按钮界面写好，测完就推上去。后面再逐步添加点击事件、接口调用。这样就算中途有别人改了样式，冲突也少，容易解决。
为什么现在都推荐主干开发？
以前常见的情况是：一个人闷头开发两周，最后合并时发现几十个冲突文件，改得头皮发麻。主干开发通过高频集成，把这种‘合并地狱’拆成每天的小问题。
像谷歌、Facebook这些公司，工程师每天可能要合并几十次代码。他们不是写得快，而是流程顺。你提交一小块，CI自动跑测试，没问题就进主干。出问题也能快速定位，不会拖累整体进度。
新手怎么开始练？
可以在 GitHub 找些开源项目看看。比如看一个活跃项目的提交记录，会发现 commit 很短，每次只改一两个文件。试着自己模拟：建个本地仓库，每完成一个小任务就 commit 一次。
举个例子，你要写个计算器，不要一口气写完。先提交一个空页面，再提交带按钮的布局，然后是加法逻辑，一步步来。每次提交都像是在打卡，心里踏实。
几个实用建议
开启 Git 的 pull rebase 模式，避免多余的合并节点。命令可以设成：
git config --global pull.rebase true写提交信息别偷懒。不说“改了点东西”，而是写清楚“修复登录页手机号校验错误”。半年后再看，你自己都能明白当时干了啥。
本地功能没完又不想提交？用 git stash 先存起来：
git stash save "临时保存表单验证"等要用时再 pop 出来继续做。
配合工具事半功倍
装个 Git GUI 工具，比如 Sourcetree 或 GitKraken，比纯命令行直观。能看到分支线怎么走，哪里分叉了，哪里合并了，图形化一看就懂。
公司用 GitLab 或 GitHub 的，多留意 MR（Merge Request）或 PR 的评论区。老员工的 review 建议都是实战经验，比如“这块应该先判空”“函数太长了拆一下”，比看书还管用。
主干开发不是一天练成的。刚开始可能不习惯，总觉得“我还没弄好呢，不敢提交”。但越早提交，越早拿到反馈，反而能少走弯路。就像学骑车，与其在家琢磨理论，不如先蹬起来，歪歪扭扭也往前走。