企业官网建设流程全解析

看到这个标题，我第一反应是挺亲切的——Day02-14，代码提交和分支合并，05:45。这明显是某个前端或全栈培训课程第二天的第14节，时长不到六分钟。别小看这五分钟的内容，代码提交和分支合并是Git里使用频率最高的两个操作，也是新手从“一个人写代码”走向“团队协作”的第一道门槛。我可以负责任地说，把这五分钟里的每个操作吃透，比后面学一堆花哨的Git技巧都管用。

这篇内容不是单纯把视频里的命令复述一遍，而是把“提交”和“合并”背后的逻辑、实战中会踩的坑、以及课程里不会明说的经验全部展开。适合刚学完Git基础、正准备上手项目，或者用IDE图形界面点了很久“commit”但始终没搞懂原理的同学。

1. Git核心认知：提交和分支到底在解决什么问题

我见过太多新手上来就敲git add .和git commit -m "update"，然后一脸茫然地问“为什么老师说这样不行”。所以咱们先把底层逻辑捋清楚，磨刀不误砍柴工。

1.1 没有版本控制的痛：改坏了就回不去

想象一下你写毕业论文，文件夹里最后躺着“论文终版.doc”、“论文终版2.doc”、“论文真终版3.doc”、“论文打死不改4.doc”。这个场景就是最原始的版本管理：靠复制文件来留后路。

Git做的事情本质上是一样的，但它更高明——每一次提交（commit）都是一次完整的项目快照，而且只记录变化的部分，打包成一个唯一的版本号。好处是显而易见的：你改坏了代码，随时能退回到任意一个历史版本；你想看看上周改了哪个文件，打开提交历史一目了然。

我记得在某个模拟电商后台项目里，有个同学（就叫A同学吧）连续改了十几个文件，然后一次性提交。第二天他发现某个功能坏了，却完全想不起来改动过哪里，只能从一个一个文件往回翻。如果他能养成小步提交的习惯，git log一看就知道“哦，昨天下午那个提交把接口参数改坏了”，直接回退那一个提交就行，根本不用连坐。

1.2 提交的本质：快照加提交信息

很多人把提交理解成“存档”，这个类比没问题，但要补充两个特征。

第一，提交是廉价的。你不需要攒够多少改动才提交，一个修复、一个样式微调、一个文档补充，都可以单独提交。提交粒度越小，历史越清晰，排查问题越容易。

第二，提交信息是给人看的。机器根本不关心你写了什么，git commit -m "fix bug"和git commit -m "修复了商品列表页在ios端下拉刷新时价格显示错乱的问题（修复了xxx模块的yyy接口在zzz条件下返回异常，导致页面白屏），对Git来说没有区别，但对你的队友、对你两周后的自己，区别巨大。后面我会专门讲提交信息怎么写。

1.3 分支的本质：可以移动的指针

分支是Git里最容易理解错的概念。很多图形化工具把分支画成一棵树，于是大家以为分支是“代码的副本”，实际上不是。

分支就是一个指针，指向某一次提交。创建分支不需要复制任何代码，只需要创建一个新的指针。你切换到某个分支干活，提交了新的commit，那个指针就跟着往前移。这样一来，多个分支可以同时指向不同的提交点，互不干扰。

这也是分支为什么这么轻量的原因。你可以在一个项目里同时维护多个并行任务：一个分支修紧急bug，一个分支开发新功能，一个分支做实验性重构。每个分支都是独立的“平行世界”，合并的时候再把它们组合起来。

2. 代码提交的标准流程：从add到commit的每一步都要有数

课程视频里演示的应该是这样一套常规流程：改代码、git add、git commit、git status确认干净。这套流程人人会敲，但很多人的操作是有问题的。

2.1 提交三连：add、commit、status

标准操作序列如下：

# 1. 先看看改了哪些文件 git status # 2. 把要提交的文件加入暂存区 git add src/components/ProductList.vue src/api/product.js # 3. 提交 git commit -m "feat: 完成商品列表组件开发并接入接口" # 4. 确认工作区干净 git status

这里有两个细节需要展开。

第一个细节，git add要精确，不要无脑git add .。如果你同时改了功能代码和调试用的临时打印，一个提交就把它们混在一起，以后维护历史的时候想哭都来不及。正确做法是：只把属于当前功能的文件加入暂存区，其他改动留到下一个提交。

第二个细节，git commit之前务必运行一次git status和git diff。git status看的是有哪些文件改动，git diff看的是具体改了哪些行。这一步是低成本高收益的“自查环节”，能拦截掉大量低级错误，比如不小心提交了.env文件、提交了node_modules里的内容。

我在带模拟项目X的时候，有个同学提交完代码，另一位同学拉下来发现跑都跑不起来。排查了半天，发现他把本地调试用的数据库配置也提交上去了，导致别人拉下来连的是他本地的库。这就是典型的git add .惹的祸。

2.2 提交信息怎么写：一眼看懂是基本要求

提交信息没有绝对标准，但业内有个流传最广的约定俗成：<type>: <description>。

• feat:新增功能
• fix:修复bug
• docs:文档改动
• style:格式调整（不影响代码逻辑）
• refactor:重构（不新增功能也不修bug）
• test:测试相关
• chore:构建、工具链等杂项

举例：

git commit -m "feat: 商品列表页新增价格区间筛选功能" git commit -m "fix: 修复订单详情页在微信浏览器中无法滚动的问题"

不要写update、修改代码这样的信息。如果提交信息里看不出这个提交做了什么，它将来就没有任何参考价值——你对着一堆update根本不知道哪个提交对应哪个功能。

2.3 提交前自查清单

我通常会在提交前过一遍这套问题，建议你复制下来贴到终端旁边的便签上：

• 这个提交是否只包含一个逻辑单元？（也就是一个提交只做一件事）
• 是否包含不该提交的文件？（比如日志、密钥、依赖目录）
• 代码是否能在干净环境跑起来？（至少不要一提交就编译报错）
• 提交信息是否能让不了解上下文的人看懂？

提示：如果你发现自己提交的信息需要写很多字才能解释清楚，说明这个提交本身太大了，拆开重新提交。

2.4 发现提交错了怎么办：amend和reset

课程里可能只会教正常的提交命令，但实际开发中难免出错。这里先补两个最常用的修正工具。

git commit --amend：修改最近一次提交。比如你提交后发现漏了一个文件，或者提交信息写错了，先git add遗漏的文件，再执行：

git commit --amend

这个命令会把当前暂存区的内容合并到上一个提交里，并让你重新编辑提交信息。

git reset：撤销提交。最常用的是这三个参数：

git reset --soft HEAD~1 # 撤销提交但保留改动在暂存区 git reset --mixed HEAD~1 # 撤销提交并保留改动在工作区（默认） git reset --hard HEAD~1 # 彻底撤销提交并丢弃所有改动（慎用）

我自己的习惯是：提交错了优先用--soft或--mixed，尽量不碰--hard，因为--hard会直接丢掉代码改动，找回来的成本很高。

3. 分支合并实战：从场景出发理解merge和rebase

标题里“分支合并”是这个视频的重头戏。我结合视频演示的最常见场景——把一个开发分支合并回主分支——把整个流程和原理拆开讲。

3.1 分支的创建、切换与生命周期

标准的多人协作流程一般是这样的：

# 基于最新主分支创建新分支 git checkout main git pull origin main git checkout -b feature/login-page

然后在这个分支上开发、提交，最后合并回主分支。这个流程的好处是：主分支永远保持可发布状态，新功能在独立的分支上随便折腾，失败了直接删分支重来，不影响主分支。

实际操作中我会用git switch代替git checkout，语义更清晰：

git switch -c feature/login-page # 创建并切换 git switch main # 切换回去 git branch -d feature/login-page # 删除已合并的分支

删除分支前先用git branch -d（大写D是强制删除），如果分支有未合并的提交，-d会阻止删除，提醒你别误删东西。

3.2 两种合并方式：merge的三方合并机制

把分支合并回主分支，最直接的方式是git merge：

git switch main git merge feature/login-page

如果你在某个模拟项目里实操过就会看到这样的输出：

Merge made by the 'ort' strategy. src/views/login.vue | 12 ++++++++-- src/router/index.js | 2 ++

Git会找出两个分支的“共同祖先”提交，然后把你所在分支的改动和待合并分支的改动组合起来。只要两边的改动没有落在同一行，Git就能自动完成合并，这个过程叫三方合并（共同祖先、当前分支、目标分支）。

3.3 从标题延伸的场景：分支分叉、Fast-forward和合并记录

如果主分支从创建feature分支后一直没动过，合并就简单了——feature分支直接指向主分支的当前提交，主分支的指针直接快进到feature分支的位置，这叫Fast-forward（快进合并）。

但如果主分支也提交了新代码，情况就变成真正的三方合并，Git会生成一个额外的merge commit节点。这就是为什么团队规范里常常要求“小步提交、频繁同步主分支”——分叉越少，合并越干净。

3.4 三种合并方式的对比

关于rebase多说一句：git rebase会把当前分支的提交“重新放到”目标分支的最新提交之后，相当于把你的改动“移植”到最新的基础上。好处是历史线非常干净，坏处是它会改写提交历史，所以只推荐用于还未推送的本地分支。

4. 冲突解决：合并中最容易翻车的一环

只要涉及分支合并，就绕不开冲突。这也是很多初学者在合并时会卡住的地方。我见过有人在冲突文件里手动把两边代码拼在一起，结果拼错了，整个模块直接报错。

4.1 冲突是怎么产生的

简单说：两个分支修改了同一个文件的同一个位置，而且修改内容不一致，Git无法自动判断该听谁的。

比如你在feature/login分支改了src/utils/format.js第10行，另一位同学在main分支也改了同一行，合并时Git就会停下来，提示：

Auto-merging src/utils/format.js CONFLICT (content): Merge conflict in src/utils/format.js Automatic merge failed; fix conflicts and then commit the result.

4.2 冲突标记长什么样

打开冲突文件，你会看到这样的内容：

<<<<<<< HEAD export const formatPrice = (price) => price.toFixed(2); ======= export const formatPrice = (price) => Math.round(price * 100) / 100; >>>>>>> feature/login-page

<<<<<<< HEAD和=======之间是你当前分支（HEAD）的内容，=======和>>>>>>> feature/login-page之间是待合并分支的内容。你需要决定保留哪一份、还是把它们整合成一份新的代码。

4.3 手动解决冲突的正确步骤

第一步，不要慌。Git已经合并了绝大部分没有冲突的文件，你只需要处理标记出来的那几处。

第二步，逐个文件打开，手动编辑，确定地盘之后删掉所有冲突标记，保留最终代码。

第三步，重新提交：

git add . git commit -m "merge: 合并feature/login-page，解决format工具函数冲突"

这步提交就是“合并提交”，单独的merge commit由此产生。

我在实际教学中还会强调一点：解决冲突时不要只盯着冲突那一块代码，要往上翻一翻、往下翻一翻，确认没有遗漏的标记。用IDE自带的冲突解决工具（比如Visual Studio Code的“接受当前/接受传入/两者都要”按钮）会直观很多，适合新手。但原理你仍然要明白——工具只是帮你删掉标记、快速完成重复劳动，最终决策还是你自己做。

4.4 避免冲突的日常习惯

冲突不是完全能避免的，但完全可以减少：

• 任务拆细，分支生命周期不要拖太久（理想是1-2天）
• 开始新分支前先同步最新主分支
• 开发过程中定期把主分支合并进来
• 尽量避免多人同时改动同一个文件的同一区域

注意：有一种比较坑的情况是两个人改的是同一个文件但不同位置，Git通常能自动合并，但如果文件编码或换行符不一致（比如Windows的CRLF和Linux的LF），可能会产生一堆“假冲突”。团队统一换行符配置就能解决这个问题。

5. 提交和合并实战中的高频问题排查

这部分我觉得最有价值。下面这些问题，全是我在带项目过程中真实遇到过的，也基本覆盖了新手使用Git时最容易翻车的高频场景。

5.1 提交到了错误的分支怎么办

场景：你本来该在feature/login分支开发，结果不小心在main分支提交了。

处理方法：

# 切回正确分支 git switch feature/login # 把main分支上最新的提交带过来 git cherry-pick main

如果只有一个提交，cherry-pick是最好用的办法，它能把指定提交“复制”到当前分支。然后你再回到main分支把误提交的那条记录删掉：

git switch main git reset --mixed HEAD~1

5.2 合并完发现合并错了怎么回退

场景：你把feature/a合并进了main，结果发现代码有严重问题。

两种路线的选择：

• 还没推送到远程：直接git reset --hard HEAD~1（这个是合并提交，回退它会连同整个合并一起撤销）
• 已经推送到远程：不要reset，用git revert -m 1 HEAD生成一个反向提交，把这次合并的效果撤销掉

git revert和git reset的核心区别是：revert是新增一个提交来“抵消”旧提交的效果，历史里保留完整记录，不会破坏别人的工作区。reset是直接改写历史，如果代码已经推到远程，别人拉取时就会乱套。

5.3 分支合完了，哪些分支可以删

合并完成后，源分支一般都可以删除：

git branch -d feature/login-page

如果分支没被完全合并，-d会拒绝删除并给出提示。这时候你可以自查一下：是真不需要了，还是有提交漏了？如果确实确定不要了，才用git branch -D强制删除。

5.4 推送到远程前的最后一道检查

很多新手是在本地一通提交、合并、删除分支后，直接git push origin main。我建议推送之前先看一遍提交历史：

git log --oneline --graph

这个命令会以图形方式展示所有提交节点，箭头和分叉一眼就能看清。多花三十秒看一遍，能避免把乱七八糟的提交推到远程，也能在队友面前少挨骂。

5.5 提交和合并高频问题速查

6. 个人实操中的几个关键体会

写了这么多，最后分享几条我在实际操作中最深的体会，也是课程视频没时间展开的细节。

第一条，提交粒度要小到“紧急回退不心疼”。我宁愿一个下午产生八九个提交，也不要憋到下班一个“update”。因为回退的时候，小提交意味着你能精准定位到具体哪一行改动出了问题，而大提交只能整块回滚，连带损失正确的改动。

第二条，合并前先看git status和git diff，合并后跑一遍测试再继续干活。我见过有人在冲突解决时把整个函数体删除了一半，自己还没发现，往下写了两小时代码才被IDE报错炸出来。合并完成之后先做一次构建、跑一遍相关测试，是成本最低的保险。

第三条，rebase是利器，但别在共享分支上乱用。如果某个分支已经推送到远程、且其他同事也在用，你rebase改写历史，别人下次push就会出奇奇怪怪的冲突。记住一条：凡是别人也在用的分支，一律用merge，不要rebase。

这个Day02的课题看起来基础，但是基础的价值恰恰在于——你以后项目里的所有协作、版本管理、代码审查、自动化发布，全部建立在“提交”和“合并”这两个动作上。如果你现在用的还是“能跑就行”的提交方式，我强烈建议你今天就按这篇文章里的方法把流程改过来。基础打好，后面学什么都没那么怕。