企业官网建设流程全解析

先说个我自己踩过的坑。早几年我在某团队做一个小项目，代码全靠压缩包管理，每次合代码都跟拆炸弹一样。同事把改完的目录打成 zip 发过来，我解压覆盖，结果他改过的文件全被我弄丢了，最后只能靠在聊天记录里逐条比对哪个文件该留、哪个该删。那次之后我才下决心把 Git 基本命令从零系统过一遍，又跟着实际开发流程完整跑了几轮迭代，才算真正把它用明白。这篇文章就围绕这两件事展开：Git 基本命令在真实项目里的用法，以及一个正规团队日常开发时都会走的 Git 工作流。刚接触版本控制的新手可以照着操作，已经会 add、commit 但没搞懂分支和远程协作的同学，也能补上缺失的那几块拼图。

1. Git 解决的不是"存代码"，而是"管变化"

1.1 压缩包式协作的真实痛感

我自己踩过的最深的一个坑，就是用压缩包管理代码。当时项目不大，团队就两个人，启动时图省事，约定"谁改完谁把文件夹打成 zip 发一份"。听起来没什么不对，结果两周之后灾难就来了：我这边解压覆盖了同事的改动，同事那边又基于旧版本改了新代码，两个人改的同一个文件在各自的 zip 里出现了两个互不兼容的版本。到最后我们只能打印出文件逐行对比，一边看一边问"这里是不是你改的"，比查账还累。

这种模式根本的问题在于三点：改了什么没人记录、谁改的说不清楚、想回到上一个可用版本没有任何可能。而 Git 这类版本控制系统，恰恰就是为这三个问题设计的。它把项目每一次变化都记录成一个 commit，commit 里有完整的文件内容、提交人、提交时间和一条说明；同时提供一套命令让你能在任意记录之间切换、对比、合并。学会 Git 基本命令，本质上是学会"用工具管理变化"，而不是单纯记住几条语法。

1.2 一次提交的内部结构：快照、树对象、父指针

先说一个很多人初学 Git 时不知道的事实：Git 保存的不是文件的差异补丁，而是快照。每当你执行一次 git commit，Git 会把当前所有被跟踪文件的状态整体保存下来，形成一个 commit 对象。这个对象里有一棵记录文件内容的树对象、作者和提交者信息、提交时间、提交说明，以及一个或多个父提交指针——第一个提交没有父指针，普通提交指向上一个提交，合并提交会指向多个父提交。它们串起来就是一条完整的提交链，也就是你常听到的"历史"。

基于快照而不是补丁，给 Git 带来一个非常大的优势：任意两个提交之间的对比、回退、开分支都很干净，不需要从某个基准点一个个补丁重放。日常你执行 git log、git diff、git checkout 能这么快，底层都是这个快照模型在支撑。这一点对理解后面的分支操作很重要，因为"历史"其实只是一个个快照节点相连，而分支和 HEAD 不过是指向这些节点的指针。

1.3 四个区域：工作区、暂存区、本地仓库、远程仓库

接下来是一个必须建立的心智模型：Git 里的文件有四种存在状态，对应四个位置。工作区是你磁盘上直接看到的目录，你在这里改代码；暂存区也叫索引，是执行 git add 之后文件变更进入的中间区域，可以理解为"购物车"，你可以分多次把想提交的改动放进去；本地仓库是 git commit 之后快照真正存放的位置；远程仓库则是托管在服务器上、方便多人共享的那一份仓库。

很多人把"提交"当成一步，其实是两步：git add 把改动放进暂存区，git commit 把暂存区固化成快照。这样设计的好处是，你可以把一个功能开发中的若干次改动，整理成逻辑完整的若干次提交，而不是把所有乱糟糟的中间状态一股脑写进历史。后面讲提交颗粒度时还会再提到，先把这个模型放在脑子里：改了文件不 add，Git 不知道你要提交什么；add 了不 commit，Git 不会存进历史；commit 了不 push，别人看不到你的东西。

2. 动手第一步：配置环境、拉代码、建立第一次提交

2.1 安装之后必须做的两个配置：身份信息与默认分支

拿到一台新机器准备用 Git，第一件事不是建仓库，而是先确认身份信息。因为每一次 commit 都要记录"谁在什么时候提交了这段代码"，这个信息就来自 user.name 和 user.email。命令很简单：

git config --global user.name "你的名字" git config --global user.email "you@example.com"

--global表示全局生效，写入用户主目录下的~/.gitconfig。如果漏了这一步，轻则历史里留下一串乱码式作者名，重则提交时报错直接中断。有些团队还会在 CI 或代码平台里校验提交邮箱是否匹配公司域名，不匹配就禁止合入，所以邮箱最好用长期有效、跟工作账号一致的那个。

另外两个建议顺手配一下：git config --global init.defaultBranch main把默认分支名从 master 改成 main；git config --global core.editor "code --wait"把编辑器改成你熟悉的程序，这样遇到需要写多行提交说明的时候不会卡在 Vim 里出不来。注意配置是有三级优先级的：system 全局机器级、global 用户级、local 仓库级，仓库级优先，同一个键在三个层级的取值会就近覆盖。

2.2 clone 与 init：两种起步方式怎么选

配置好身份之后，你会面对两种起步方式。第一种是空项目从零开始，在目录里执行git init，Git 会生成一个 .git 隐藏目录，里面装着这个仓库的全部历史与配置。如果你是从已有项目接手到本地，更常见的是第二种：git clone <url>。clone 会把远程仓库的完整历史连同所有分支一次性拉到本地，并且自动建立好远程追踪关系：默认远端叫 origin，本地默认分支自动关联到远端对应分支，之后你 push、pull 都不需要每次指定地址。

git init之后如果想要推送到远程，需要手动补一步git remote add origin <url>；而git clone则把这一步省掉了。从实际开发的角度看，绝大多数场景都是从 clone 开始的——进了团队接任务，第一步永远是拉代码，而不是新建仓库。新建仓库这个操作，通常只有项目启动那一次会用到。建议新手把这两个命令的场景分清楚：init 是造一块新地皮，clone 是接手一块已有地皮。

2.3 首次提交链路：status、diff、add、commit

代码拉到本地，改完第一版之后，怎么把它提交上去？完整链路是：先看状态，再看差异，然后暂存，最后提交。git status会告诉你当前工作区和暂存区分别处于什么状态，哪些文件被修改、新增、删除；git diff会展示工作区与暂存区之间的具体差异；确认无误后git add <文件或目录>把改动放进暂存区；最后git commit -m "说明"生成一次提交。举个例子：

git status # 查看整体状态 git diff # 看改了哪些具体内容 git add src/utils/api.js git status # 确认暂存内容 git commit -m "feat(api): add request wrapper"

有几个细节新手容易栽跟头。git commit -am "..."这条简写只能把已跟踪文件的修改直接提交，但对新文件不生效，新文件必须先 add 一次才能纳入版本控制。另外不要把 add 写成一个万能动作，git add .确实省事，但会把调试日志、临时代码、密钥文件全部拖进暂存区，很多事故就是这么来的。我自己的习惯是：每次提交前必看一遍git diff，哪怕只是改动了几行，也要知道这次提交到底动了什么。

2.4 提交之后怎么读懂历史

提交一旦多了，就要学会读历史。最常用的几个命令：

git log --oneline # 一行一个提交 git log --graph --decorate --oneline --all # 图形化看分支关系 git show <commit哈希> # 看某个提交的详细改动 git blame <文件路径> # 逐行看谁在哪个提交里写了这行代码

git log --oneline适合快速浏览，--graph会把分支合并关系画成 ASCII 图，排查分支分叉时非常好用。git blame这个命令名字听着凶，场景却非常实用：线上某个变量行为诡异，点开文件逐行看，很快就能定位到是哪个提交、为哪个需求改的，再顺着提交说明和代码评审记录去找上下文。

到这里你其实已经掌握了 Git 最核心的本地闭环：修改、查看、暂存、提交、追溯。后面要讲的分支、合并、远程协作，都建立在这套闭环之上。

3. 分支与合并：日常开发真正的战场

3.1 为什么 Git 的分支便宜到可以随手创建

很多从 SVN 切过来的同事最不适应的一点，就是 Git 分支怎么这么"廉价"。创建分支的命令是：

git branch feature/xxx # 创建分支 git branch feature/xxx <某个commit> # 基于任意提交开分支 git checkout -b feature/xxx # 创建并切换 git switch -c feature/xxx # 更语义化的写法

理解了第一章说的指针模型就明白了：在 Git 里创建一个分支，本质只是创建一个指向某个 commit 的指针，没有任何文件被复制。这个操作的时间开销几乎是零，所以 Git 工作流鼓励"一个功能开一个分支"，功能做完合回主干后把分支删掉，整个过程非常轻快。分支名本身也不是神奇的东西，它只是历史链上一个会移动的标签，随着你在该分支上不断提交，标签所指的 commit 会一直往前走。正是这种轻量设计，让 Git 拥有了后来所有协作模式的自由度。

3.2 切换分支的正确姿势：switch、checkout、stash

切分支最传统的命令是git checkout <分支>，2.23 版本之后 Git 提供了语义更清晰的git switch，两套命令同时存在，建议新项目统一用 switch 做切换。但这里最大的坑不是命令写法，而是"工作区有未提交的改动时能不能切分支"。Git 允许你带着改动切走，唯一的前提是这些改动和要切换到的目标分支之间没有冲突；万一有冲突，Git 会直接拒绝切换，这时候就得把手头的活先处理掉。

处理未提交改动有三个思路：如果改动还没整理好，先用git stash把现场存起来，切到别的分支处理完再git stash pop恢复；如果改动本身是完整的提交候选，也可以先 commit 到当前分支再切走；如果只是临时探测代码不想留，那就直接还原。这里有个经验：stash 用多了容易乱，我习惯任何 stash 之前先git stash list看一眼，并且在 stash 的说明里写清楚是哪个功能的改动，否则三天后你面对十几个 stash 条目，根本分不清哪个是哪个。

3.3 merge 的三种合并方式与冲突解决

功能开发完，要把分支合回主干，一般分成两种情况。如果目标分支从开出到合并之间没有任何新提交，Git 默认做 fast-forward，直接把目标分支指针快速移动到当前分支顶端，历史是一条直线，不会留下合并节点；如果两条分支都有各自的新提交，Git 会做一次三方合并，生成一个带有两个父提交的合并提交。有些团队希望保留"功能合入"的痕迹，会强制非快进合并git merge --no-ff feature/xxx，哪怕能快进也故意留下一个合并节点，这样 git log --graph 里功能边界一目了然。两种策略没有绝对对错，看团队习惯。

冲突是最让人头大的场景。它发生在两个人同时改了同一文件的同一区域时，Git 不知道听谁的，只能把冲突标记写进文件：

<<<<<<< HEAD 这里是当前分支的内容 ======= 这里是待合入分支的内容 >>>>>>> feature/xxx

解决冲突的本质不是"选一边赢"，而是搞清楚两个版本各自的意图，然后把代码整理成既保留双方合理逻辑、又符合当前需求的样子。手动改好之后，执行git add <文件>标记为已解决，最后用git commit完成合入。这里务必注意：冲突解决阶段不要带任何情绪去判断"谁的代码更好"，先看提交说明和注释理解思路，再决定怎么融合，很多线上故障就是因为合并时把对方的逻辑理解错了。

3.4 rebase：整理历史，但有一条公共红线

rebase 是初学时最容易混淆的命令。git rebase <目标分支>做的事，是把当前分支上的提交一个一个"摘下来"，重新放置到目标分支当前顶端之后，最终效果是当前分支的历史变成一条"原本目标分支历史 + 你这段改动"的直线。它和 merge 的结果最终都是把两边代码合在一起，但历史形状完全不同。什么时候值得用？你的功能分支从主干出来后，主干又合入了几次别人的修改，你想把功能分支更新到最新，同时让最终历史看起来干净线性，git pull --rebase或者git rebase main就很合适。

但 rebase 有一条绝对不能碰的红线：不要对已经推到公共分支的提交执行 rebase。一旦你重写了这些提交，它们的哈希全部变了，队友的本地历史和你远程的历史会像分叉的铁轨一样对不上，最后只能靠冲突和痛苦的手动整理来收尾。判断标准很简单：这个提交是否已经被别人 clone、fetch、pull 过？只要答案是"是"，就别用 rebase 动它。rebase 过程中遇到冲突，处理方式和 merge 类似，改完后git add并执行git rebase --continue；想放弃这场折腾就git rebase --abort，回到 rebase 前状态。

4. 一个功能从需求到合入主干：标准工作流完整拆解

4.1 先画一张协作地图：主干、功能分支、PR 与发布

在大多数正规开发团队里，Git 工作流都围绕着一条被保护的主干分支展开，通常是 main 或者 master，直接往主干 push 通常被禁止，一切变更必须经过分支、合并请求和代码评审。典型的地图是这样的：主干永远保持可发布状态；新的功能从主干开出生命周期短暂的功能分支，命名类似 feature/user-login、fix/cart-price；开发完成后把分支推到远程，开一个合并请求（Pull Request 或 Merge Request），评审通过后合入主干；主干再通过打 tag 的方式标记发布版本。另外还有一条从主干分出的维护分支，用于线上紧急修复，命名一般是 hotfix/xxx。

很多新手不理解：为什么要绕这么大一圈，直接在主干上改不香吗？答案很简单：主干上同时会有多个人在开发，如果每个人都直接改主干，代码会立刻互相踩踏；而把每个功能隔离在独立分支里，再通过评审和自动化检查合入，主干才能在任意时刻保持"拿下来就能跑"的状态。这套流程不是 Git 强制的，而是团队在版本控制之上约定的纪律，但 Git 的分支能力让这套纪律可以低成本执行。

4.2 跑一遍完整路径：拉最新主干、开分支、开发、提交、推送

用一个真实场景把这套流程落地。假设团队约定主干叫 main，需求编号 1024，你接到任务要做登录接口。第一步，先把本地主干更新到和远程一致：

git switch main git pull --rebase

--rebase的意思是如果本地主干上有自己的提交，先把它重放到远程最新提交之上，保持线性历史。第二步，基于最新主干开功能分支：

git switch -c feature/1024-login

开发过程中保持小步提交：每完成一个可运行的小功能点就 commit 一次，提交信息写清楚做了什么、为什么。代码写完后，把分支推到远程并设置上游关联：

git push -u origin feature/1024-login

-u会建立本地分支与远程分支的追踪关系，之后在这条分支上直接git push、git pull就能省略参数。接下来去托管平台建合并请求，找至少一个人 review。评审提出意见后，不用重新开分支，就在同一个功能分支上继续改、继续提交、继续 push，合并请求会自动更新，所有讨论和历史都留在同一个地方。

4.3 远程协作的底层命令：fetch、pull、push、remote

一旦多人协作，本地和远程的关系就要搞清。git fetch只从远程下载最新数据，不改动你任何工作区内容，是最安全的"看看别人干了什么"的方式；git pull其实是git fetch加一个合并动作，默认走 merge；git push把本地提交推送到远程。fetch 然后自己决定怎么合，是更可控的习惯，尤其是你想避免自动合并带来意外冲突的时候。

push 被拒绝是新手最常见的挫折来源：你改了几天推到远程，结果发现别人的提交已经先一步推上去了，Git 为了不覆盖别人把请求直接打回。标准解法就是先git pull --rebase把你的改动重放到别人最新提交之后，再重新 push。这里有个细节建议：多人同时开发同一功能分支时，每次 push 前先 pull --rebase，把冲突尽量提前暴露在自己本地，而不是等在远程平台上爆雷。远程仓库本身用git remote -v查看，可以看到关联了哪些地址，一个项目可以有多个远程，但常规协作一个 origin 就够。

4.4 合并策略：merge commit、squash、rebase merge 怎么选

功能分支评审通过之后，合入主干的策略其实有讲究。最常见的三种合并方式：

从团队维护历史的角度看，我比较推荐功能开发用 squash merge，因为它既保留了"这是一个完整功能"的边界，又避免了开发过程中的零碎提交污染主线；对于那些需要保留逐步骤审计痕迹的场景，比如安全相关功能，可以改用 merge commit。关键是团队要在项目一开始就把这条规矩定下来，而不是每个人按喜好来，否则主干 log 很快就会变成一条混着各种风格的毛线。

5. 提交写砸了怎么办：reset、revert、reflog 的止血方案

5.1 reset 的三个模式：--soft、--mixed、--hard

改代码肯定会犯错，提交之后又发现不想这么提交了，这时候最常用的就是git reset。它本质是移动 HEAD 指针，根据移动范围的不同分成三档。

git reset --soft <commit>：只把 HEAD 移到目标提交，暂存区和工作区都不动，适合你刚 commit 完发现漏了文件想重新组织提交的场景，相当于"提交已经拆开但内容还在购物车里"。git reset --mixed <commit>（不带参数时的默认模式）：移动 HEAD，并把暂存区重置到目标提交的状态，但工作区内容保留，适合把错误 add 的文件撤销出暂存区，或者想把近几次提交全部拆回未暂存状态重新整理。git reset --hard <commit>：三个区域全部重置到目标提交，之前的改动彻底消失，是最危险的一档，执行前至少要确认目标提交就是你要去的地方。

举例：A 同学提交了三次，结果发现第一次提交里混进了环境变量，他可以用git reset --soft HEAD~3把三次提交全部展开回暂存区，清理后再重新提交，历史就不会留下那三笔脏记录。注意--hard不是完全不能碰，只是用之前要三思：请先git log把当前提交哈希抄下来，万一后悔还能用后面的 reflog 救回来。

5.2 revert：不重写历史的安全撤销

reset 的问题在于它是向后改写历史的，如果错误提交已经推到公共分支，reset 一下再强推，轻则别人本地历史乱掉，重则所有人的协作节奏被打乱。公共分支上要撤销一笔提交，正解是git revert <commit>。revert 不会删除原有提交，而是创建一个新的反向提交，把那次改动的内容倒回去，但历史里原提交和这次反向提交都还在，别人 pull 时只是普通地多了一笔提交，不会产生冲突型分叉。

什么场景用 revert？功能上线后引入故障，需要快速回滚，从主干把出问题的合并提交 revert 掉，就既能在最短时间内恢复线上，又保留了完整的事故和恢复痕迹。revert 偶尔也会遇到冲突，处理流程和普通合并一样：改完文件、git add、git commit。对比一下：本地私有分支、还没推出去的提交，用 reset；已经推到公共分支、别人可能基于它继续开发的提交，用 revert。这条分界线基本就是两个命令的分工逻辑。

5.3 reflog：所有操作后悔药的来源

讲了这么多，最绝望的场景是：我执行了git reset --hard，然后发现重置错了，我的提交全没了怎么办？答案是 Git 有一个被低估的命令git reflog。reflog 会把 HEAD 每一次移动都记录下来，包括 reset、merge、checkout、rebase，即使某个提交已经"不属于"任何分支了，只要它还在本地仓库对象库里，reflog 里就还能看到它的哈希。

实际找回流程是这样的：git reflog输出一行行"操作 + 到达的提交哈希"记录，找到你 reset 之前的那一行，把对应的哈希记下来，然后执行git reset --hard <那个哈希>，瞬间回到历史现场。我拿这个办法帮同事救回过一次误删的整周工作量，他当时脸色已经白了，看到 git log 又变回熟悉的那串提交，才缓过气。经验之谈：reflog 是本地私有的，每个开发者只能看到自己这台机器上的操作历史，所以它适合救本地，不适合救远程；远程误删的分支如果有人在合入前 clone 过，同样可以用类似方式找人要。

6. 团队协作里反复犯的错误和我的工作习惯

6.1 .gitignore、大文件、敏感信息的处理

几乎每个团队都发生过"密钥被提交进仓库"的事故。事后的处理很麻烦：你把文件从工作区删掉并加入 .gitignore 没用，因为历史里还留着；要彻底清干净得用专门工具重写历史，并且所有协作者都得重新 clone。所以正确思路是防患于未然：项目初始化时就建好 .gitignore，把依赖目录、构建产物、本地配置、环境变量文件全部排除；提交之前再看一眼 git status，有没有不该出现的文件。常用的 .gitignore 模板网上有很多，按语言和框架抄一份就能覆盖 80% 场景。

如果已经不小心把大文件或者不应提交的文件提交了，还在本地、没有推到远程，最简单的是git rm --cached <文件>把它从暂存区移除但保留本地文件，然后补一条 .gitignore 并提交；如果已经推到远程，就要评估影响面：小文件可以尽快在新提交里删掉并轮换密钥，大文件则需要更彻底的历史清理，代价是所有人的克隆都会受影响，最好在低峰期协调处理。不要抱有"随手提交一下没事"的侥幸，管理好 .gitignore 是团队协作最基本的安全卫生习惯。

6.2 原子提交与提交信息规范

行业内对 Git 历史质量有个隐形的评判标准：看提交能不能当代码文档读。这背后是两个习惯，一是原子提交，一次提交只做一件逻辑上的事，不要把"修了登录 Bug"和"顺手格式化整个目录"混在一起，否则将来用 git blame 回溯某个变动时，会被无关改动干扰很久；二是提交信息要能解释为什么，而不仅是做了什么。常见的约定俗成格式可以是这样：

<type>(<scope>): <subject> feat(auth): add password reset endpoint fix(cart): correct tax calculation on mobile docs(readme): update deployment steps

type 用 feat、fix、docs、refactor、test 这一组词，一眼就能在 log 里看出提交性质。提交说明正文里还可以写清楚上下文、影响范围、关联的需求编号。我自己的原则是：如果一条提交说明需要解释超过三句话，说明这次提交塞的东西太多了，拆成两条更合适。养成这个习惯之后，团队里审代码、查问题、做发布说明都会变得非常顺畅。

6.3 容易被忽略的三类小毛病

最后聊几个不常出现在教程里、但真实协作中总能遇到的细节。第一是换行符问题，Windows 和 Linux、macOS 对行尾处理不同，文件里如果混了 CRLF 和 LF，diff 会把整个文件标成改动，代码评审时满屏红绿根本没法看。团队统一约定core.autocrlf的行为，Windows 上设为 true、macOS/Linux 上设为 input，基本能避开大部分问题。第二是文件名大小写，macOS 默认文件系统对大小写不敏感，本地叫 README.md 推上去变成了 readme.md 可能会在 Linux 构建机上直接失败，一旦发现要及时用git mv纠正大小写。第三是 submodule，能用包管理器或工具链解决的依赖就不要用 submodule，这东西的同步、更新、冲突处理成本远高于收益，我见过不止一个团队最终把它拆掉。养成"看到异常先查配置和平台差异"的排查习惯，能少踩很多远程环境的坑。

6.4 我现在每天在用的 Git 习惯

讲到这里，我把自己每天实际在用的流程浓缩一下，给刚开始用 Git 的同学一个"抄作业"的版本。早上开工第一件事，git switch main && git pull --rebase，确保本地主干最新；动手做需求前先开功能分支，绝不在主干上直接改；开发过程中每次提交前执行git diff快速审视改动，提交信息按规范写，一次提交只做一件事；下班前或者告一段落时git push，推送前如果远端有新提交就再 pull --rebase 一次，把冲突留在自己这里；功能完成开合并请求，评审中被打回的修改继续在同一个功能分支上提交，保持讨论和代码历史的连贯性。这套习惯不一定适合所有团队，但它是被大量项目验证过、能覆盖大多数日常协作场景的通用版本。等你遇到更复杂的情况，比如仓库历史重构、代码评审抢合并、多人长期维护重基线，就需要再往深处学一层了。但在那之前，把本文这些基本命令真正练熟，已经足够你在真实开发中站稳脚跟了。