企业官网建设流程全解析

如果你也在跟着某个前端实战训练营的节奏走，大概率会对这种课程编排有印象：一天拆成十几节，每节只有几分钟，上午还在配环境、起项目，下午就已经把页头、轮播图、商品列表全部怼了出来。等到第二天下午，讲师突然慢下来，单独用一节讲“代码提交和分支合并”，时长只有五分四十五秒。我第一次看到这个标题时心里是不太当回事的，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 -5

git 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 status

2.3 提交信息怎么写，未来两天的你就靠它认路

到git commit这一步，课程重点强调了提交信息的规范性。这不是走形式，而是提交记录就像项目给未来自己留下的索引。如果你写“更新了页面”或者“修改了一些东西”，过两天想查“这个轮播图是哪个提交加的”，只能一条条翻，非常痛苦。

我后来一直用的提交信息格式是约定式提交，来源就是课程里提到的规范：

对应到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：一张表说清楚我的选择逻辑

很多初学者纠结这个问题，其实结合团队规范来选就行。我用过一段时间之后，总结出这样的判断标准：

我的建议是：在训练营、多人协作时不熟悉的项目里默认用 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-home

Git立刻返回一段报错：

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 class="site-header"> <h1 class="site-title"> <<<<<<< HEAD 商城首页 ======= 我的商城 >>>>>>> feature/day02-home </h1> </header>

这段标记的含义很直白：HEAD指当前分支（也就是main）的内容，“我的商城”是被合并分支的内容。中间的分隔线把两个版本隔开，你要做的就是在两个之间做出决定，把不要的那部分连同标记一起删掉。

4.3 手动解决冲突：保留正确内容后重新提交

解决冲突不是点一个按钮就完事，而是要你真正读代码、做判断。在这个场景下，我选择保留“商城首页”，因为这是产品文案最终想用的名字。修改后的文件变成：

<header class="site-header"> <h1 class="site-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之前必pull，pull时优先考虑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的截图丢到项目群里。大家看着一笔笔清爽的提交记录排成一条线，整个团队的提交质量都会不自觉变高。