如果你也在跟着某个前端实战训练营的节奏走大概率会对这种课程编排有印象一天拆成十几节每节只有几分钟上午还在配环境、起项目下午就已经把页头、轮播图、商品列表全部怼了出来。等到第二天下午讲师突然慢下来单独用一节讲“代码提交和分支合并”时长只有五分四十五秒。我第一次看到这个标题时心里是不太当回事的Git提交和分支合并这不是用了好多年的基本功吗。结果自己动手把两天写的代码推到远端又在新分支合并回主线时撞上一整屏冲突标记才知道这一节五分钟的内容里踩满了新手最容易忽略的坑。这篇我想顺着“Day02-14.代码提交和分支合并05:45”这个切片展开聊聊一个前端项目推进到第二天、功能模块基本成型时到底该怎么把代码提交干净、分支合并得漂亮以及在训练营这种高强度的节奏里哪些习惯能让你少返工。如果你正在跟类似的实战课程、或者自己接了个小项目准备认真做版本管理这篇可以直接当一份操作复盘来读。1. 课程到了Day02-14为什么必须停下来整理提交1.1 两天积累下来的代码状态有多乱跟着训练营做模拟项目进度是很快的。以我当时的模拟项目X为例Day01把开发环境、脚手架、Git仓库初始化全部搞定顺手搭好了目录结构Day02上午开始写首页顶部导航下午继续补轮播图、分类入口、商品列表骨架。到Day02-13结束的时候工作区里已经散落了二十多个文件有新建的组件文件、改到一半的样式、临时加的测试图片还有几处为了调试顺手写死的数据。这个状态非常典型就是“能跑但很乱”。大多数人这时候会直接敲一个git add .再git commit -m 完成了首页把几十个文件当一坨东西整体塞进提交记录里。课程在这个节点专门安排一节提交和合并本质上是想告诉你代码开发到某个阶段性成果时需要主动踩一次刹车把成果固化下来而不是稀里糊涂继续往下写。1.2 五分四十五秒里真正要解决什么问题标题里的“05:45”是视频时长但放在实际开发里它对应的是一整套动作查看工作区状态、把变更按逻辑分组暂存、写一条规范的提交信息、推送到远端仓库再把开发分支合并回主线。五分钟能演示完不代表五分钟能掌握。它更像是一个“操作样板间”告诉你在这个项目节点上标准动作长什么样。我当时听完这一节的直接感受是前面十几节都在教“如何写代码”这一节在教“如何让代码变成可回溯的资产”。提交记录本质上是项目的时间线哪天写了什么功能、修了什么bug、是谁动过哪一行代码全部靠它来还原。Day02这个节点刚好是第一波功能收口讲师在这时候安排提交和合并是在培养一种节奏感每完成一个功能块就停下来做一次提交和分支整理而不是等着全部做完再说。1.3 阶段提交为什么优于“憋大招”式的一次性提交很多自学的人有一个习惯项目做完了才想着去提交一下甚至有人项目做完了都没建过Git仓库。这种做法放到训练营节奏里会非常难受因为一旦后面某一步改崩了你想回退到昨天能跑的状态会发现根本无路可退。阶段提交的逻辑和写文章定期存档类似。你写了一下午中途存几次稿心里是有底的等全部写完再去找历史版本等于把赌注压在最后一刻。在Day02这个节点做提交刚好是“完成了一个相对完整的功能模块”——首页静态框架。这个阶段点选得很聪明不大不小足够独立成一条提交记录又能让接下来的分支合并有实际意义。2. 一次规范提交的完整链路从工作区到远程仓库2.1 动手之前先把仓库状态摸清楚我见过不少人的提交流程是凭感觉的觉得“改完了”就 add、commit、push一条龙往下走从来不看仓库现在是什么状态。上一节讲师演示的第一步就是git status当时我还觉得多余后来自己操作才明白这一步有多重要。git status git log --oneline -5git status会列出所有已修改、未跟踪、已暂存的文件。你能一眼看到哪些文件是新加的哪些是改过的哪些是被误删的。git log则是确认本地仓库已经有哪些提交、当前处于哪个分支。这两条命令花不了十秒钟但能避免很多“提交完发现多了个奇怪文件”的尴尬。我在实际操作中发现训练营的项目因为文件多很容易混入临时文件。比如为了调试轮播图有人会新建一个test.html或者把一张素材图扔在根目录。如果直接无脑git add .这些临时文件全会进到提交里之后每次拉代码的人都要为一堆无关文件买单。先看清状态就是在把“待提交清单”梳理清楚。2.2 用 git add 精确控制提交范围而不是一键全收课程演示里用的命令很简单git add src/components/Header.js src/components/Banner.js注意到没有讲师没有用git add .。这个细节我当时忽略了直到后面处理分支合并时才反应过来精确暂存才能保证一次提交只做一件事。如果整个工作区同时包含首页组件和调试文件git add .会把它们全部纳入同一次提交导致这条提交记录既包含新功能又莫名其妙带着垃圾文件。如果你觉得每次一个个文件写麻烦可以用git add -p进入交互式暂存Git会把每个文件按改动块拆开让你选择。这个命令对“一个文件里既有功能改动又有测试代码”的情况特别有用。不过在训练营这种高强度进度下最简单靠谱的做法是在git status里看清楚分组然后按功能块使用git add 文件路径。# 按功能分组暂存 git add src/components/Header.js git add src/components/Banner.js git add src/components/ProductList.js # 确认暂存内容 git status2.3 提交信息怎么写未来两天的你就靠它认路到git commit这一步课程重点强调了提交信息的规范性。这不是走形式而是提交记录就像项目给未来自己留下的索引。如果你写“更新了页面”或者“修改了一些东西”过两天想查“这个轮播图是哪个提交加的”只能一条条翻非常痛苦。我后来一直用的提交信息格式是约定式提交来源就是课程里提到的规范类型使用场景示例feat新功能、新页面、新组件feat: 完成首页顶部导航布局fix修复bugfix: 修复轮播图自动播放失效的问题docs文档变更docs: 补充项目启动说明style不影响代码逻辑的样式调整style: 调整商品列表间距refactor重构不改变外部行为refactor: 抽取公共轮播组件chore构建配置、依赖等杂项chore: 更新ESLint规则对应到Day02-14这个提交当时我的提交信息是git commit -m feat: 完成首页顶部导航、轮播图与商品列表静态布局一句话说清楚“做了什么”而且只描述这一个功能范围。听起来简单实际坚持下来的人真不多。你可以观察一下项目里其他人的提交记录大把的“update”“fix”“aaa”这种记录对团队协作毫无帮助。2.4 push 之前先 pull否则你永远会遇到“分叉”本地提交完成之后下一步是把提交推送到远程仓库。课程里在这里花了一点时间讲了git pull和git push的顺序问题原因是训练营里多人可能操作同一个仓库哪怕你是单人开发也可能存在本地仓库和远端仓库不同步的情况。正确的顺序永远是先拉取远端最新代码解决可能的冲突或分叉再推送本地提交。git pull origin main git push origin main我在跟课的时候犯过一个典型错误本地提交完之后直接git push结果提示远端有更新被拒绝了。当时我还纳闷明明自己没改远端的东西怎么会被拒。后来看日志才发现远端有别人合并进去的提交自己的本地提交是基于旧状态的Git为了保证历史不出错拒绝了这个“非快进”推送。解决办法也很简单先git pull把远端新提交拉到本地Git自动做一次合并然后再push就通了。注意不要养成“先push、被拒了再pull”的习惯顺序一乱提交历史很容易出现分叉后续每次合并都要处理多余的分叉点。3. 分支合并的现场操作merge 与 rebase 怎么选3.1 课程里的分支场景功能分支开发完了怎么办Day02-14后半段讲的是分支合并。场景很明确我们一直在feature/day02-home这个分支上开发首页功能现在功能完成并且提交好了需要把这部分代码合并到主分支main保证主线始终是可运行的状态。这个操作在训练营里的意义不只是一个“合并动作”而是训练一种工作流主分支永远保持稳定功能开发在独立分支上进行完成一个合并一个。哪怕是一个人开发这个习惯也值得养成它让主分支的每一次提交都处于可演示、可发布的状态。回到操作层面当时的流程是# 确保功能分支已提交 git status # 切换到目标分支并更新 git checkout main git pull origin main # 合并功能分支 git merge feature/day02-home这样做是有讲究的。先切换到main、先pull更新主线再执行合并能保证你合并时的基线是最新的。否则你在一个老旧的main上合并可能把别人已经修掉的问题重新带回来。3.2 merge 的直观体验保留历史但会多一个合并节点课程演示用的是git merge这也是一般团队最常用的合并方式。它做的事情很简单把两个分支的修改汇聚到一个分支上并生成一个新的合并提交。git merge feature/day02-home如果两个分支各自改动的文件互不相交Git会自动完成合并你甚至感觉不到过程。但如果两边动了同一个文件就会产生冲突Git会停下来让你处理。merge 最大的优点是不破坏任何一边的历史每个分支原来的提交记录都原样保留项目脉络清晰。缺点是历史会比较“散”因为多了一个分叉再合并的过程git log --graph看时间线有点像一棵树的枝丫。对于个人项目还好团队多人协作时一段时间过后这个图会变得很乱。3.3 rebase 的另一种选择让历史变成一条直线课程里还花了一小段提了一下git rebase当时没有细讲只说“也可以用rebase来合并让历史更干净”。很多新手听过这个词但一直没用过这里我把当时的实际感受展开一下。rebase 做的事情是把当前分支的提交“搬运”到目标分支的最新提交之后。比如你在feature/day02-home上有两条提交main上也有别人的两条新提交rebase 之后你的两条提交会被重新放到main最新提交的后面看起来整个历史是线性推进的没有分叉。git checkout feature/day02-home git rebase main git checkout main git merge feature/day02-home这样合并完main的历史是笔直的日志可读性很高。但代价是rebase 会重写提交的哈希值如果你已经把功能分支推到了远端并和别人共享了再rebase会产生麻烦因为别人的克隆仓库里还保存着旧哈希。所以rebase更适合“本地分支还没推送过”的场景训练营这种单人功能分支用它正合适。3.4 到底用 merge 还是 rebase一张表说清楚我的选择逻辑很多初学者纠结这个问题其实结合团队规范来选就行。我用过一段时间之后总结出这样的判断标准对比维度mergerebase历史形态保留分支分叉和合并节点线性历史无分叉冲突处理一次性解决可能要处理多次每个提交都可能要解决一次冲突对已有远程提交安全不修改历史会重写提交哈希已推送的慎用适合场景团队协作、主干合并个人开发、清理本地提交我的建议是在训练营、多人协作时不熟悉的项目里默认用 merge它最安全、最容易理解在个人独立功能分支上如果你喜欢干净的历史可以用 rebase 整理后再合并。Day02-14这节用的 merge 并没有什么问题关键是养成“先更新主线、再执行合并”的习惯顺序对了用哪种都不会出大乱子。提示任何时候不确定怎么选就选 merge。rebase 虽然历史好看一旦处理冲突不熟练改坏代码的风险远大于它带来的整洁感。4. 冲突未必是坏事一次真实冲突的定位与解决全流程4.1 冲突是怎么在合并那一刻冒出来的Day02-14这节本身没有演示冲突因为课程里的分支改动很规矩。但按我的经验训练营过半之后几乎每个人都会在分支合并且撞上一次冲突区别只是早撞晚撞。所以我当时在课程结束后故意把两个分支的同一个文件改了不同内容复现了一次冲突把解决流程完整走了一遍。冲突的本质是两个分支对同一个文件的同一行代码做了不同的修改Git无法判断哪边是对的只能停下来问你要哪个版本。就像两个同事同时在同一个表格里填了不同的手机号表格软件不知道该听谁的只能让你亲自确认。我在模拟项目X里复现冲突的方式在main分支把首页头部的标题文字改成“商城首页”在feature/day02-home分支把同样的文字改成“我的商城”。两边都提交了然后执行合并git checkout main git pull origin main git merge feature/day02-homeGit立刻返回一段报错Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.4.2 从报错信息到冲突标记一步步定位冲突代码报错之后先别慌课程里教的排查链路是稳定的先看状态再开文件最后解决。git status状态信息会明确告诉你哪个文件有冲突Git会把冲突文件标记为both modified。接下来打开这个文件我建议用编辑器直接搜冲突标记这三个标记是查找冲突位置的快捷键。当时文件里显示出来的内容大概是这样header classsite-header h1 classsite-title HEAD 商城首页 我的商城 feature/day02-home /h1 /header这段标记的含义很直白HEAD指当前分支也就是main的内容“我的商城”是被合并分支的内容。中间的分隔线把两个版本隔开你要做的就是在两个之间做出决定把不要的那部分连同标记一起删掉。4.3 手动解决冲突保留正确内容后重新提交解决冲突不是点一个按钮就完事而是要你真正读代码、做判断。在这个场景下我选择保留“商城首页”因为这是产品文案最终想用的名字。修改后的文件变成header classsite-header h1 classsite-title 商城首页 /h1 /header然后把文件标记为已解决git add index.html git commit -m merge: 合并 feature/day02-home 到 main解决首页标题冲突注意冲突解决之后的这次提交Git已经帮你暂存好了合并上下文。如果你用的是git merge提交信息可以保持默认也可以自己改写但强烈建议保留“merge”字样方便以后回溯时快速定位这次合并。到这里整个冲突解决流程就结束了再执行git push origin main推送成功。这里有一个细节如果解决冲突时你改动比较多涉及多个文件建议一个个git add后再统一提交不要急着 commit先回看一遍所有改动是否符合预期。4.4 面对冲突的正确心态它其实是帮你兜底很多新手第一次看到CONFLICT字样就以为代码坏了其实冲突是这个世界上绝大多数版本管理系统的正常机制。它说明Git在替你保守操作宁可停下来问人也不私自覆盖你的代码。真正该警惕的不是冲突本身而是平时提交太随意、导致冲突出现时根本不知道该保留哪边的代码。我在那次模拟冲突之后总结了几条减少冲突的习惯每个分支只改自己负责的模块开始改代码之前先git pull保证基线最新提交频率高一点、每个提交小一点冲突范围自然就小。这几条习惯在后来的训练营项目里帮我基本没有再遇上大冲突。5. 复盘这些提交和合并习惯让我在后续项目里少走了弯路5.1 提交节奏按功能点提交而不是按时间提交课程切片只有五分钟但它背后传递的提交理念值得在后面的所有项目里持续用。我给自己定的规则是一个功能模块完成就提交一次一个明显的bug修完就提交一次。宁可多提交几条也不要攒着一整天的工作量一次性提交。按功能点提交的好处是你的提交记录天然就是一份开发日志。比如想回滚某个功能只要找到对应的那一条提交git revert就完事。如果按时间一次性提交回滚一个功能往往意味着把一整天的工作全丢掉这个代价太大了。我在模拟项目X后面还实验过一个做法提交之前先看一遍git diff确认自己到底改了哪些行。这个动作虽然每次多花一两分钟但能拦住大量“不小心把测试代码带进去”的情况。5.2 远程同步时机push之前必pullpull时优先考虑rebase大多数提交冲突的根源不是合并时候的问题而是push之前没同步远端。我一直保持着“push 前先 pull”的习惯而在团队协作比较频繁时我会把拉取命令写成git pull --rebase origin main这样本地提交会先被暂存拉取远端更新后再放回最新基线上历史不会产生分叉。这个做法在训练营第二次协作开发时非常有用我们几个人同时提交靠这个命令把分叉控制在最小范围内。不过要注意如果本地提交已经推送到了公共分支就不要再用 rebase 了那会重写公共历史影响其他人。5.3 分支名和提交信息都是写给队友的信训练营到了中后期会开始多人协作同一个仓库。这时候你会发现分支名和提交信息的规范程度直接决定沟通成本高不高。我自己见过test、dev、fix-全部这种分支名也见过“asdfasdf”这种提交信息遇到这种队友真的很头大。我后来总结的分支命名规范是类型/功能描述比如feature/day02-home、fix/carousel-bug、refactor/common-components。对应的提交信息则一定包含“做了什么影响范围”。不要小看这一点当时我们组后期排bug全靠翻提交记录规范的提交信息能直接帮你锁定问题出现在哪一段代码。5.4 从五分钟的切片里真正带走的东西写到这里再回头看“Day02-14.代码提交和分支合并05:45”这个标题我会觉得这五分钟其实承担了比想象中更重的教学任务。它没有讲复杂的高级操作没有讲Git内部原理就是原原本本地演示了一个项目在功能成型节点上该怎样把代码提交干净、把分支合并好。而这恰恰是大多数教程不会单独拿出来讲的日常操作。我自己在整个训练营结束后回头看最值钱的不是写了多少组件、调了多少接口而是这些看起来不起眼的版本管理习惯。它们让我在有底气随便改代码的同时也能在出错时快速回到可运行状态。如果你现在也在跟课或者手头有个小项目正在开发建议别把这五分钟的内容看过就算亲手把提交、合并、冲突解决各走一遍后面返工的次数一定会少很多。最后分享一个小技巧每次提交完可以顺手把git log --oneline --graph的截图丢到项目群里。大家看着一笔笔清爽的提交记录排成一条线整个团队的提交质量都会不自觉变高。 
长河君 · 2026/10/17 10:34:31 · 阅读 1.2k Git提交与分支合并实战：前端训练营Day02-14复盘
如果你也在跟着某个前端实战训练营的节奏走大概率会对这种课程编排有印象一天拆成十几节每节只有几分钟上午还在配环境、起项目下午就已经把页头、轮播图、商品列表全部怼了出来。等到第二天下午讲师突然慢下来单独用一节讲“代码提交和分支合并”时长只有五分四十五秒。我第一次看到这个标题时心里是不太当回事的Git提交和分支合并这不是用了好多年的基本功吗。结果自己动手把两天写的代码推到远端又在新分支合并回主线时撞上一整屏冲突标记才知道这一节五分钟的内容里踩满了新手最容易忽略的坑。这篇我想顺着“Day02-14.代码提交和分支合并05:45”这个切片展开聊聊一个前端项目推进到第二天、功能模块基本成型时到底该怎么把代码提交干净、分支合并得漂亮以及在训练营这种高强度的节奏里哪些习惯能让你少返工。如果你正在跟类似的实战课程、或者自己接了个小项目准备认真做版本管理这篇可以直接当一份操作复盘来读。1. 课程到了Day02-14为什么必须停下来整理提交1.1 两天积累下来的代码状态有多乱跟着训练营做模拟项目进度是很快的。以我当时的模拟项目X为例Day01把开发环境、脚手架、Git仓库初始化全部搞定顺手搭好了目录结构Day02上午开始写首页顶部导航下午继续补轮播图、分类入口、商品列表骨架。到Day02-13结束的时候工作区里已经散落了二十多个文件有新建的组件文件、改到一半的样式、临时加的测试图片还有几处为了调试顺手写死的数据。这个状态非常典型就是“能跑但很乱”。大多数人这时候会直接敲一个git add .再git commit -m 完成了首页把几十个文件当一坨东西整体塞进提交记录里。课程在这个节点专门安排一节提交和合并本质上是想告诉你代码开发到某个阶段性成果时需要主动踩一次刹车把成果固化下来而不是稀里糊涂继续往下写。1.2 五分四十五秒里真正要解决什么问题标题里的“05:45”是视频时长但放在实际开发里它对应的是一整套动作查看工作区状态、把变更按逻辑分组暂存、写一条规范的提交信息、推送到远端仓库再把开发分支合并回主线。五分钟能演示完不代表五分钟能掌握。它更像是一个“操作样板间”告诉你在这个项目节点上标准动作长什么样。我当时听完这一节的直接感受是前面十几节都在教“如何写代码”这一节在教“如何让代码变成可回溯的资产”。提交记录本质上是项目的时间线哪天写了什么功能、修了什么bug、是谁动过哪一行代码全部靠它来还原。Day02这个节点刚好是第一波功能收口讲师在这时候安排提交和合并是在培养一种节奏感每完成一个功能块就停下来做一次提交和分支整理而不是等着全部做完再说。1.3 阶段提交为什么优于“憋大招”式的一次性提交很多自学的人有一个习惯项目做完了才想着去提交一下甚至有人项目做完了都没建过Git仓库。这种做法放到训练营节奏里会非常难受因为一旦后面某一步改崩了你想回退到昨天能跑的状态会发现根本无路可退。阶段提交的逻辑和写文章定期存档类似。你写了一下午中途存几次稿心里是有底的等全部写完再去找历史版本等于把赌注压在最后一刻。在Day02这个节点做提交刚好是“完成了一个相对完整的功能模块”——首页静态框架。这个阶段点选得很聪明不大不小足够独立成一条提交记录又能让接下来的分支合并有实际意义。2. 一次规范提交的完整链路从工作区到远程仓库2.1 动手之前先把仓库状态摸清楚我见过不少人的提交流程是凭感觉的觉得“改完了”就 add、commit、push一条龙往下走从来不看仓库现在是什么状态。上一节讲师演示的第一步就是git status当时我还觉得多余后来自己操作才明白这一步有多重要。git status git log --oneline -5git status会列出所有已修改、未跟踪、已暂存的文件。你能一眼看到哪些文件是新加的哪些是改过的哪些是被误删的。git log则是确认本地仓库已经有哪些提交、当前处于哪个分支。这两条命令花不了十秒钟但能避免很多“提交完发现多了个奇怪文件”的尴尬。我在实际操作中发现训练营的项目因为文件多很容易混入临时文件。比如为了调试轮播图有人会新建一个test.html或者把一张素材图扔在根目录。如果直接无脑git add .这些临时文件全会进到提交里之后每次拉代码的人都要为一堆无关文件买单。先看清状态就是在把“待提交清单”梳理清楚。2.2 用 git add 精确控制提交范围而不是一键全收课程演示里用的命令很简单git add src/components/Header.js src/components/Banner.js注意到没有讲师没有用git add .。这个细节我当时忽略了直到后面处理分支合并时才反应过来精确暂存才能保证一次提交只做一件事。如果整个工作区同时包含首页组件和调试文件git add .会把它们全部纳入同一次提交导致这条提交记录既包含新功能又莫名其妙带着垃圾文件。如果你觉得每次一个个文件写麻烦可以用git add -p进入交互式暂存Git会把每个文件按改动块拆开让你选择。这个命令对“一个文件里既有功能改动又有测试代码”的情况特别有用。不过在训练营这种高强度进度下最简单靠谱的做法是在git status里看清楚分组然后按功能块使用git add 文件路径。# 按功能分组暂存 git add src/components/Header.js git add src/components/Banner.js git add src/components/ProductList.js # 确认暂存内容 git status2.3 提交信息怎么写未来两天的你就靠它认路到git commit这一步课程重点强调了提交信息的规范性。这不是走形式而是提交记录就像项目给未来自己留下的索引。如果你写“更新了页面”或者“修改了一些东西”过两天想查“这个轮播图是哪个提交加的”只能一条条翻非常痛苦。我后来一直用的提交信息格式是约定式提交来源就是课程里提到的规范类型使用场景示例feat新功能、新页面、新组件feat: 完成首页顶部导航布局fix修复bugfix: 修复轮播图自动播放失效的问题docs文档变更docs: 补充项目启动说明style不影响代码逻辑的样式调整style: 调整商品列表间距refactor重构不改变外部行为refactor: 抽取公共轮播组件chore构建配置、依赖等杂项chore: 更新ESLint规则对应到Day02-14这个提交当时我的提交信息是git commit -m feat: 完成首页顶部导航、轮播图与商品列表静态布局一句话说清楚“做了什么”而且只描述这一个功能范围。听起来简单实际坚持下来的人真不多。你可以观察一下项目里其他人的提交记录大把的“update”“fix”“aaa”这种记录对团队协作毫无帮助。2.4 push 之前先 pull否则你永远会遇到“分叉”本地提交完成之后下一步是把提交推送到远程仓库。课程里在这里花了一点时间讲了git pull和git push的顺序问题原因是训练营里多人可能操作同一个仓库哪怕你是单人开发也可能存在本地仓库和远端仓库不同步的情况。正确的顺序永远是先拉取远端最新代码解决可能的冲突或分叉再推送本地提交。git pull origin main git push origin main我在跟课的时候犯过一个典型错误本地提交完之后直接git push结果提示远端有更新被拒绝了。当时我还纳闷明明自己没改远端的东西怎么会被拒。后来看日志才发现远端有别人合并进去的提交自己的本地提交是基于旧状态的Git为了保证历史不出错拒绝了这个“非快进”推送。解决办法也很简单先git pull把远端新提交拉到本地Git自动做一次合并然后再push就通了。注意不要养成“先push、被拒了再pull”的习惯顺序一乱提交历史很容易出现分叉后续每次合并都要处理多余的分叉点。3. 分支合并的现场操作merge 与 rebase 怎么选3.1 课程里的分支场景功能分支开发完了怎么办Day02-14后半段讲的是分支合并。场景很明确我们一直在feature/day02-home这个分支上开发首页功能现在功能完成并且提交好了需要把这部分代码合并到主分支main保证主线始终是可运行的状态。这个操作在训练营里的意义不只是一个“合并动作”而是训练一种工作流主分支永远保持稳定功能开发在独立分支上进行完成一个合并一个。哪怕是一个人开发这个习惯也值得养成它让主分支的每一次提交都处于可演示、可发布的状态。回到操作层面当时的流程是# 确保功能分支已提交 git status # 切换到目标分支并更新 git checkout main git pull origin main # 合并功能分支 git merge feature/day02-home这样做是有讲究的。先切换到main、先pull更新主线再执行合并能保证你合并时的基线是最新的。否则你在一个老旧的main上合并可能把别人已经修掉的问题重新带回来。3.2 merge 的直观体验保留历史但会多一个合并节点课程演示用的是git merge这也是一般团队最常用的合并方式。它做的事情很简单把两个分支的修改汇聚到一个分支上并生成一个新的合并提交。git merge feature/day02-home如果两个分支各自改动的文件互不相交Git会自动完成合并你甚至感觉不到过程。但如果两边动了同一个文件就会产生冲突Git会停下来让你处理。merge 最大的优点是不破坏任何一边的历史每个分支原来的提交记录都原样保留项目脉络清晰。缺点是历史会比较“散”因为多了一个分叉再合并的过程git log --graph看时间线有点像一棵树的枝丫。对于个人项目还好团队多人协作时一段时间过后这个图会变得很乱。3.3 rebase 的另一种选择让历史变成一条直线课程里还花了一小段提了一下git rebase当时没有细讲只说“也可以用rebase来合并让历史更干净”。很多新手听过这个词但一直没用过这里我把当时的实际感受展开一下。rebase 做的事情是把当前分支的提交“搬运”到目标分支的最新提交之后。比如你在feature/day02-home上有两条提交main上也有别人的两条新提交rebase 之后你的两条提交会被重新放到main最新提交的后面看起来整个历史是线性推进的没有分叉。git checkout feature/day02-home git rebase main git checkout main git merge feature/day02-home这样合并完main的历史是笔直的日志可读性很高。但代价是rebase 会重写提交的哈希值如果你已经把功能分支推到了远端并和别人共享了再rebase会产生麻烦因为别人的克隆仓库里还保存着旧哈希。所以rebase更适合“本地分支还没推送过”的场景训练营这种单人功能分支用它正合适。3.4 到底用 merge 还是 rebase一张表说清楚我的选择逻辑很多初学者纠结这个问题其实结合团队规范来选就行。我用过一段时间之后总结出这样的判断标准对比维度mergerebase历史形态保留分支分叉和合并节点线性历史无分叉冲突处理一次性解决可能要处理多次每个提交都可能要解决一次冲突对已有远程提交安全不修改历史会重写提交哈希已推送的慎用适合场景团队协作、主干合并个人开发、清理本地提交我的建议是在训练营、多人协作时不熟悉的项目里默认用 merge它最安全、最容易理解在个人独立功能分支上如果你喜欢干净的历史可以用 rebase 整理后再合并。Day02-14这节用的 merge 并没有什么问题关键是养成“先更新主线、再执行合并”的习惯顺序对了用哪种都不会出大乱子。提示任何时候不确定怎么选就选 merge。rebase 虽然历史好看一旦处理冲突不熟练改坏代码的风险远大于它带来的整洁感。4. 冲突未必是坏事一次真实冲突的定位与解决全流程4.1 冲突是怎么在合并那一刻冒出来的Day02-14这节本身没有演示冲突因为课程里的分支改动很规矩。但按我的经验训练营过半之后几乎每个人都会在分支合并且撞上一次冲突区别只是早撞晚撞。所以我当时在课程结束后故意把两个分支的同一个文件改了不同内容复现了一次冲突把解决流程完整走了一遍。冲突的本质是两个分支对同一个文件的同一行代码做了不同的修改Git无法判断哪边是对的只能停下来问你要哪个版本。就像两个同事同时在同一个表格里填了不同的手机号表格软件不知道该听谁的只能让你亲自确认。我在模拟项目X里复现冲突的方式在main分支把首页头部的标题文字改成“商城首页”在feature/day02-home分支把同样的文字改成“我的商城”。两边都提交了然后执行合并git checkout main git pull origin main git merge feature/day02-homeGit立刻返回一段报错Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.4.2 从报错信息到冲突标记一步步定位冲突代码报错之后先别慌课程里教的排查链路是稳定的先看状态再开文件最后解决。git status状态信息会明确告诉你哪个文件有冲突Git会把冲突文件标记为both modified。接下来打开这个文件我建议用编辑器直接搜冲突标记这三个标记是查找冲突位置的快捷键。当时文件里显示出来的内容大概是这样header classsite-header h1 classsite-title HEAD 商城首页 我的商城 feature/day02-home /h1 /header这段标记的含义很直白HEAD指当前分支也就是main的内容“我的商城”是被合并分支的内容。中间的分隔线把两个版本隔开你要做的就是在两个之间做出决定把不要的那部分连同标记一起删掉。4.3 手动解决冲突保留正确内容后重新提交解决冲突不是点一个按钮就完事而是要你真正读代码、做判断。在这个场景下我选择保留“商城首页”因为这是产品文案最终想用的名字。修改后的文件变成header classsite-header h1 classsite-title 商城首页 /h1 /header然后把文件标记为已解决git add index.html git commit -m merge: 合并 feature/day02-home 到 main解决首页标题冲突注意冲突解决之后的这次提交Git已经帮你暂存好了合并上下文。如果你用的是git merge提交信息可以保持默认也可以自己改写但强烈建议保留“merge”字样方便以后回溯时快速定位这次合并。到这里整个冲突解决流程就结束了再执行git push origin main推送成功。这里有一个细节如果解决冲突时你改动比较多涉及多个文件建议一个个git add后再统一提交不要急着 commit先回看一遍所有改动是否符合预期。4.4 面对冲突的正确心态它其实是帮你兜底很多新手第一次看到CONFLICT字样就以为代码坏了其实冲突是这个世界上绝大多数版本管理系统的正常机制。它说明Git在替你保守操作宁可停下来问人也不私自覆盖你的代码。真正该警惕的不是冲突本身而是平时提交太随意、导致冲突出现时根本不知道该保留哪边的代码。我在那次模拟冲突之后总结了几条减少冲突的习惯每个分支只改自己负责的模块开始改代码之前先git pull保证基线最新提交频率高一点、每个提交小一点冲突范围自然就小。这几条习惯在后来的训练营项目里帮我基本没有再遇上大冲突。5. 复盘这些提交和合并习惯让我在后续项目里少走了弯路5.1 提交节奏按功能点提交而不是按时间提交课程切片只有五分钟但它背后传递的提交理念值得在后面的所有项目里持续用。我给自己定的规则是一个功能模块完成就提交一次一个明显的bug修完就提交一次。宁可多提交几条也不要攒着一整天的工作量一次性提交。按功能点提交的好处是你的提交记录天然就是一份开发日志。比如想回滚某个功能只要找到对应的那一条提交git revert就完事。如果按时间一次性提交回滚一个功能往往意味着把一整天的工作全丢掉这个代价太大了。我在模拟项目X后面还实验过一个做法提交之前先看一遍git diff确认自己到底改了哪些行。这个动作虽然每次多花一两分钟但能拦住大量“不小心把测试代码带进去”的情况。5.2 远程同步时机push之前必pullpull时优先考虑rebase大多数提交冲突的根源不是合并时候的问题而是push之前没同步远端。我一直保持着“push 前先 pull”的习惯而在团队协作比较频繁时我会把拉取命令写成git pull --rebase origin main这样本地提交会先被暂存拉取远端更新后再放回最新基线上历史不会产生分叉。这个做法在训练营第二次协作开发时非常有用我们几个人同时提交靠这个命令把分叉控制在最小范围内。不过要注意如果本地提交已经推送到了公共分支就不要再用 rebase 了那会重写公共历史影响其他人。5.3 分支名和提交信息都是写给队友的信训练营到了中后期会开始多人协作同一个仓库。这时候你会发现分支名和提交信息的规范程度直接决定沟通成本高不高。我自己见过test、dev、fix-全部这种分支名也见过“asdfasdf”这种提交信息遇到这种队友真的很头大。我后来总结的分支命名规范是类型/功能描述比如feature/day02-home、fix/carousel-bug、refactor/common-components。对应的提交信息则一定包含“做了什么影响范围”。不要小看这一点当时我们组后期排bug全靠翻提交记录规范的提交信息能直接帮你锁定问题出现在哪一段代码。5.4 从五分钟的切片里真正带走的东西写到这里再回头看“Day02-14.代码提交和分支合并05:45”这个标题我会觉得这五分钟其实承担了比想象中更重的教学任务。它没有讲复杂的高级操作没有讲Git内部原理就是原原本本地演示了一个项目在功能成型节点上该怎样把代码提交干净、把分支合并好。而这恰恰是大多数教程不会单独拿出来讲的日常操作。我自己在整个训练营结束后回头看最值钱的不是写了多少组件、调了多少接口而是这些看起来不起眼的版本管理习惯。它们让我在有底气随便改代码的同时也能在出错时快速回到可运行状态。如果你现在也在跟课或者手头有个小项目正在开发建议别把这五分钟的内容看过就算亲手把提交、合并、冲突解决各走一遍后面返工的次数一定会少很多。最后分享一个小技巧每次提交完可以顺手把git log --oneline --graph的截图丢到项目群里。大家看着一笔笔清爽的提交记录排成一条线整个团队的提交质量都会不自觉变高。