企业官网建设流程全解析

刚把 Vue.js 项目跑起来那几天，我对 Git 的态度一直是"能用就行"。无非就是git add、git commit，把代码传上去别丢就行。直到有一次我把App.vue里组合式 API 的状态管理改了个天翻地覆，又花了一个小时试图改回原样，才意识到没有版本记录的开发就是裸奔。这篇笔记是我在 Vue.js 入门路上补抄的 Git 功课，从安装配置讲到分支和远程协作，配上了我在真实项目里踩过的坑。接下来这一路会包含：环境装好、把vue create生成的项目交给 Git、用日志和回退给手滑行为兜底、靠分支管理并发的功能开发、最后把代码同步到 Gitee 或 GitHub。如果你已经能用脚手架创建 Vue 项目，但还没系统学过 Git，这篇内容应该刚好卡在你的痒点上。

1. 在 Vue 项目里，Git 到底在管哪些糊涂账

1.1 为什么 Vue 入门要先过 Git 这一关

Vue 项目和以前写单个 HTML 文件完全不同。一个由vue create生成的标准项目里，有package.json、node_modules/、src/、public/，还有一堆配置文件。组件拆得越细，文件就越多，改动往往分散在几个甚至十几个文件里。

我今天改了Button.vue，明天改了store/index.js，后天升级了一个 npm 包。三天后想回退到"按钮还没改坏的时候"，如果没有版本管理，就只能靠记忆和运气。这种场景在 Vue 学习阶段尤其常见——很多人刚写完一个功能觉得思路不对，想回到几个 commit 之前的干净状态，结果发现所有文件都已经被覆盖了。

Git 解决的就是这笔糊涂账。它不是简单的"备份一次代码"，而是把项目每一次变化都记录成一个快照，并支持随时回到任意快照。对 Vue 开发来说，这意味着：

• 可以放心大胆改src/components下的组件，改坏了直接回退。
• 每次新增依赖，package.json的变化都看得一清二楚。
• 每个功能都有对应的提交记录，回溯问题不再靠翻聊天记录。

1.2 理解三个区：工作区、暂存区、本地仓库

Git 入门最绕不过去的就是"三个区"的概念：工作区、暂存区、本地仓库。很多命令记不住，根本原因是没搞懂这三个区之间的关系。

我用厨房做菜的流程来类比：

• 工作区（Workspace）：你正在切的菜，随手可以调整，对应你磁盘上看到的项目文件。
• 暂存区（Index/Staging Area）：备菜台上挑好的配料，还没下锅，但已经决定要用哪些了。对应git add后暂存起来的内容。
• 本地仓库（Repository）：已经装盘上桌、拍照留档的菜。对应git commit提交后的提交记录。

git add把文件从工作区放进暂存区，git commit把暂存区的内容固化成一次提交，写入本地仓库。git status就是帮你检查：三个区之间谁和谁不一致。

理解这一点之后，很多命令就不再是死记硬背了。比如git diff看的是工作区里还没暂存的改动，而git diff --staged看的是已经git add但还没提交的内容。每次操作前用git status看一眼，基本不会迷路。

1.3 Git 在 Vue 开发中的具体价值

学习阶段最容易犯的错，是把node_modules也当成"要保存的重要代码"。实际上，node_modules是npm install根据package.json自动生成的，完全不需要交给 Git 管。项目里真正要追踪的，是package.json和package-lock.json这两个文件——它们锁定了依赖的版本，换一台机器，只要执行npm install就能恢复出相同的环境。

另一个容易忽略的价值是"按功能回溯"。Vue 项目里，一次功能改动可能跨组件、跨状态管理、跨路由配置。如果每次改动都对应一个清晰的 commit，比如feat: 添加登录页表单校验，那么将来出了问题时，用git log就能定位到是哪个 commit 引入的。再配合git show，可以直接查看这次提交改了哪些文件、哪些行，效率比肉眼对比代码高得多。

2. 环境准备：Windows 和 macOS 下把 Git 装成顺手的样子

2.1 下载安装：为什么我建议直接用国内镜像

Git 官方下载站git-scm.com在国外，国内访问经常慢得让人怀疑人生。我在 Windows 上第一次下载时等了好几分钟，最后还断掉了。后来发现国内镜像非常好用，尤其是淘宝 npm 镜像：

• Windows：https://registry.npmmirror.com/binary.html?path=git-for-windows/
• macOS：推荐用 Homebrew 安装，命令是brew install git

Windows 安装包里有一个关键选项需要留意：在 "Adjusting your PATH environment" 这一步，选第二个选项 "Git from the command line and also from 3rd-party software"，这样 VS Code 和其他终端才能直接识别git命令。

还有一个让很多人头疼的选项是换行符转换。不同系统的换行符不一样，Windows 是 CRLF，macOS 和 Linux 是 LF。如果不希望 Git 在提交时把换行符改来改去，我建议在换行符设置中选择 "Checkout as-is, commit as-is"，也就是保持原样，不做转换。这样可以省掉一批莫名其妙的冲突和报警。

安装完成后，打开终端执行git --version，能正确输出版本号就说明安装成功了。

2.2 全局配置三件套，一次性配好

Git 装好之后，第一件事就是配置身份信息。每次git commit都会记录提交人，如果没配置，提交时会报错或者用一段很丑的默认信息。

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

--global表示这台机器上的所有 Git 仓库都使用这个身份。这份信息会写进每一次提交记录里，所以在代码托管平台（Gitee、GitHub）上最好保持一致，这样提交记录能关联到你的账号。

除了身份，还有两个配置我强烈建议顺手设置。

第一个是解决中文文件名显示乱码的问题。Git 默认会把中文文件名转义成类似\346\265\213的八进制编码，看着非常痛苦。设置core.quotepath为 false 可以解决：

git config --global core.quotepath false

第二个是确认换行符策略。Windows 推荐设置：

git config --global core.autocrlf true

macOS 推荐：

git config --global core.autocrlf input

这些都设完之后，用git config --list可以查看当前所有配置项，确认无误后就行。

2.3 让终端顺手：VS Code 里直接用 Git

入门阶段最顺手的组合是 VS Code + Git。VS Code 自带源代码管理面板，可以直观看到工作区里改动了哪些文件、暂存了什么内容，不用死记命令也能完成基本的提交。

不过我还是建议把终端命令也学起来，因为面板点来点去在处理分支冲突、查看历史时效率并不高。VS Code 的内置终端可以切换为 Git Bash（Windows 下），这样cd、ls、git status这些命令都直接可用。

还可以把 Git 的默认编辑器设置为 VS Code，这样 commit 信息想写多行时会自动用 VS Code 打开：

git config --global core.editor "code --wait"

设置完后，如果这里出现git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称这种报错，基本可以确定是安装 Git 时没有加入 PATH，或者安装后没有重启终端。重新安装并勾选 PATH 相关的选项，再打开一个新的终端窗口就能解决。

3. 把第一个 Vue 项目交给 Git：初始化、暂存、提交全流程

3.1 vue create 之后，Git 可能已经就位

如果你在安装 Vue CLI 时选择了使用 Git，那么vue create创建项目时会自动执行git init，把项目目录初始化为一个 Git 仓库。不放心的话，可以手动执行：

git init

git init会在当前目录下生成一个.git隐藏文件夹，这个文件夹里保存着整个项目的版本历史。日常操作中不要手动去改.git目录里的内容，否则可能把历史搞坏。

git init之后，用git status看看当前状态，如果是刚创建的项目，大概率会显示一堆"未跟踪的文件"（Untracked files），这意味着 Git 已经看到了这些文件，但还没有纳入版本管理。

3.2 .gitignore：node_modules 永远不该进仓库

这一步非常关键。vue create生成的模板里自带一个.gitignore文件，里面已经帮我们忽略了几类不该进仓库的内容，比如node_modules/、dist/、.DS_Store等。

node_modules不该提交，因为它是npm install的产物，体积巨大，动辄几百 MB，而且完全没有必要保存到版本库。package.json和package-lock.json才是真正需要提交的文件，它们是依赖的"配方"。

如果你发现git status里出现了node_modules，说明.gitignore没有生效。最可能的原因是：项目初始化时.gitignore还没创建，或者这个文件被改动过。处理方法是手动把这些路径补进去：

node_modules/ dist/ .env.local

如果已经不小心把node_modules提交进去了，可以用这个命令把它从 Git 的跟踪列表里移除，但保留本地文件：

git rm -r --cached node_modules

然后执行git commit -m "chore: 移除误提交的 node_modules"，之后新的.gitignore就会生效。

3.3 第一次提交：add、commit、status、diff 一条龙

理解了三个区之后，第一次提交就是一次"把菜选好、下锅记录"的过程。

先看当前文件状态：

git status

如果一切正常，就可以先把所有项目文件加入暂存区：

git add .

也可以精确添加指定文件，比如只暂存src/App.vue：

git add src/App.vue

git add .会把当前目录下所有未被忽略的改动都加入暂存区。确认暂存内容无误后，执行提交：

git commit -m "init: 初始化 Vue 项目"

提交信息非常重要。刚开始的时候我写过不少update、修改这种毫无信息量的提交信息，过几天再看根本想不起来改了啥。后来我养成了按类型前缀写提交信息的习惯，这也是目前社区比较通用的规范：

每次提交之前，我还会习惯性地用git diff检查一下工作区的改动：

git diff # 查看未暂存的改动 git diff --staged # 查看已暂存、还没提交的改动

提交前的这一步检查，能帮你拦截掉很多"手滑改错地方"的尴尬。

3.4 用 git log 看懂提交历史

提交了几次之后，git log就成了高频命令。默认的git log输出信息非常多，入门阶段我推荐三种简化视图。

最常用的是单行模式，每个提交只占一行：

git log --oneline

输出类似：

a1b2c3d (HEAD -> main) feat: 添加登录页面 e4f5a6b init: 初始化 Vue 项目

加上--graph可以看到分支合并的图形结构：

git log --oneline --graph --all

想查看某次提交到底改了什么，用git show加上那次提交的短哈希：

git show a1b2c3d

git log -p可以查看所有提交的详细差异，信息量大，适合排查问题时使用。入门阶段，只要掌握--oneline和--graph就足够应对大部分场景了。

4. 手滑现场急救：日志定位与版本回退

4.1 我能看到什么历史：日志三视图

版本回退的前提是能准确找到"我要回到哪一个时刻"。git log是唯一的凭据。

日常我基本只看两种视图：

git log --oneline git log --oneline --graph

第一种适合快速浏览提交顺序，第二种适合看分支结构和合并点。配合git show <commit>，可以查看任意一次提交的完整改动内容，这在排查"这段代码是谁改的、为什么这么改"时特别有用。

另外还有一个高频需求：只想看某个文件的历史。比如我想知道src/components/LoginForm.vue都经历过哪些修改：

git log --oneline -- src/components/LoginForm.vue

这样过滤出来的提交列表非常精准。

4.2 reset 三档位：把代码退回指定版本

回退操作最常用的是git reset，它有三个档位，区别在于"退到什么程度"。

先看一个具体场景：我在App.vue里改写了一堆组合式 API 的代码，结果控制台疯狂报错，想放弃今天的所有改动，回到上次提交时的状态。

git reset --hard HEAD

--hard会把工作区、暂存区都重置到 HEAD 指向的提交状态，所有未提交的改动直接消失。这是最"狠"的档位，但也是最常用的——前提是你确定不要这些改动了。

如果不确定要不要保留某些文件的改动，可以使用混合模式：

git reset HEAD~1

HEAD~1表示上一个提交。不带参数的 reset 默认是--mixed，它会把暂存区的内容清空，但保留工作区的文件改动。也就是说，文件内容还在，只是之前git add进去的东西被退出来了，状态变成了"未暂存"。

还有一个--soft档位，它只移动 HEAD 指针，不动暂存区和工作区。场景比较少见，一般用于"想重新组织提交信息"的时候。

三个档位的差别，我常用一句话总结：--soft只移指针，--mixed连暂存区一起退，--hard连工作区都直接覆盖。

需要特别提醒：如果只想丢弃工作区里某个文件的改动，不要用git reset，用：

git checkout -- src/App.vue

这个命令会把src/App.vue恢复到最近一次提交时的状态，其他文件不受影响。

4.3 回退后发现回错了：reflog 是后悔药

git reset --hard最吓人的地方是"改动直接消失"。但其实 Git 有一套机制在暗中记录你的每一次 HEAD 移动，这就是git reflog。

git reflog

输出会显示所有曾经的 HEAD 位置，包括被 reset 掉的那些提交。比如我不小心git reset --hard回到了两个提交之前，但过了十分钟发现原来的代码其实更好，只要在git reflog里找到对应的提交哈希，再执行一次：

git reset --hard <commit-hash>

就能"穿越"回去，把丢失的提交找回来。这个操作让我避免过至少三次崩溃。

需要留意：reflog记录的是本地仓库的 HEAD 移动历史，不是远程仓库的。如果某个提交已经被推送到远程，又被别人拉取走了，那就不适合用reset去回退——这时候应该用git revert。revert会生成一次新的提交，把之前的改动反向撤销，更适合公共分支上的操作。

5. 分支管理：Vue 功能开发不搞乱主线

5.1 分支的本质：一条条平行的修改线

刚开始用 Git 时，我觉得分支是个很玄的概念。后来发现它的本质就是"指向某个提交的指针"，没什么神秘的。

创建一个分支，就是创建一条可以独立移动的修改线：

git branch feature/login

切到新分支：

git switch feature/login

创建并切换一步到位：

git switch -c feature/login

切到分支之后，所有新提交都会落在feature/login这条线上，而原来的main分支停留在原地。两条线的提交互不干扰，直到你主动把它们合并。

5.2 一条靠谱的 Vue 功能开发流

在学习阶段，很多人都是在main分支上直接改代码，提交、再改。项目只有一个人时问题不大，但一旦开始多人协作，或者有多个功能并行开发，直接在main上改就会乱套。

我现在在 Vue 项目里基本遵循这样的流程：

1. main分支始终保持可用状态。
2. 开发新功能时，从main拉一条功能分支，比如feature/dashboard或fix/login-btn。
3. 在功能分支上完成开发和提交。
4. 功能验证通过后，切回main分支，把功能分支合并进来。
5. 合并完成后删除功能分支。

对应的命令长这样：

git switch main git switch -c feature/login # 在分支上开发、提交 git commit -m "feat: 添加登录页表单校验" # 开发完成，切回 main 并合并 git switch main git merge feature/login git branch -d feature/login

这个工作流的好处是：即使某个功能改到一半发现思路错了，直接在功能分支上重置或者丢弃即可，完全不影响main分支上已经可用的代码。

5.3 冲突并不可怕：组件修改冲突怎么处理

多人协作时，冲突几乎不可避免。我遇到的第一次冲突，是两个同事同时修改了src/components/Header.vue里的一段methods，一个改了用户信息展示逻辑，一个改了菜单点击事件。合并时 Git 发现两处改动在同一段代码附近，无法自动处理，就会报冲突。

冲突发生时，相关文件会变成类似这样：

methods: { <<<<<<< HEAD handleUserClick() { this.fetchUserInfo() } ======= handleUserClick() { this.showMenu = true } >>>>>>> feature/header-menu }

<<<<<<< HEAD到=======之间的内容，是当前分支的版本；=======到>>>>>>> feature/header-menu之间，是被合并分支的版本。

处理冲突的方法很简单：手动把两边代码都看一遍，决定保留哪边、还是两边都合并，然后把<<<<<<<、=======、>>>>>>>这些标记全部删除。保存文件后：

git add src/components/Header.vue git commit -m "merge: 合并 Header 组件冲突"

冲突不是 Bug，它是 Git 在保护代码。出现冲突后不要慌，也不要对着冲突标记乱删，逐段判断即可。

预防冲突的思路是：尽量拆小组件、减少多人同时改同一文件的概率；提交要小步勤快，频繁把main分支合回自己的功能分支，避免"憋大招"式的开发。

5.4 stash 临时储藏：做到一半要先切分支

这个场景我几乎每周都会遇到：正在feature/login分支上写登录功能，写到一半还没提交，突然来了一个线上 bug 需要立刻修。此时工作区是脏的，直接切分支会带上这些半成品改动，容易造成混乱。

正确做法是把半成品临时储藏起来：

git stash

执行后工作区会回到上次提交时的干净状态，所有未提交的改动都被保存到一个"储藏列表"里。修复完 bug、切回开发分支后，再把储藏的内容恢复出来：

git stash pop

常用命令：

git stash # 储藏未提交的改动 git stash list # 查看储藏列表 git stash pop # 恢复最近一次储藏并删除该记录 git stash apply # 恢复最近一次储藏但保留记录

注意，git stash默认不会储藏未跟踪的文件。如果你有新建的文件不想提交也要被带过去，需要加上-u参数：

git stash -u

6. 标签与远程仓库：从本机到 Gitee / GitHub 的日常协作

6.1 标签：给版本号一个锚点

分支会不断前进，但版本号应该固定下来。比如我把 Vue 项目开发到第一个里程碑，打了v1.0.0的标签，以后任何时候切到这个标签，都能回到这个版本的状态。

打标签：

git tag v1.0.0

推荐使用附注标签，把版本说明写清楚：

git tag -a v1.0.0 -m "第一个可发布版本"

查看已有标签：

git tag

标签默认不会跟随push传远程，需要显式推送：

git push origin --tags

删除本地标签和远程标签分别是：

git tag -d v1.0.0 git push origin :refs/tags/v1.0.0

对 Vue 项目来说，标签的典型用途是配合版本号做发布节点。每发一个版本打一个标签，回头排查问题时直接git checkout v1.0.0，就能复现当时的代码状态。

6.2 远程仓库的日常：clone / push / pull

本机的 Git 仓库只能自己访问，想要备份、协作、多设备同步，就必须推送到远程仓库。国内用 Gitee 体验比 GitHub 顺畅不少，创建仓库时选"空仓库"即可。

假设我在 Gitee 上创建了一个名为vue-demo的仓库，接下来在本机项目里关联远程地址：

git remote add origin git@gitee.com:你的用户名/vue-demo.git

然后把本地main分支推送上去：

git push -u origin main

-u的作用是设置上游分支，以后直接git push和git pull就会默认操作origin/main。

换一台电脑，或者同事要接手这个项目，只需要：

git clone git@gitee.com:你的用户名/vue-demo.git

日常同步代码的两个命令：

git pull # 拉取远程更新并合并到当前分支 git push # 把本地提交推送到远程

6.3 SSH 免密配置：一次设置，到处不用输密码

每次git push都输账号密码很烦，SSH 免密是标配。先检查本地是否已经有密钥：

ls ~/.ssh

如果还没有，生成一个：

ssh-keygen -t ed25519 -C "你的邮箱"

一路回车即可，生成的文件在~/.ssh/id_ed25519.pub。用编辑器打开这个公钥文件，把内容完整复制，添加到 Gitee 或 GitHub 的 SSH 公钥管理页面。

验证是否配置成功：

ssh -T git@gitee.com

看到欢迎语就说明免密配置成功了。以后 clone、push 都走 SSH 协议，不会再被问密码。

6.4 远程冲突：push 被拒之后的正确处理

第一次遇到push被拒绝时，我以为是代码被删了。其实报错信息很明确：远程分支有本地没有的提交，直接推送会覆盖别人的内容，所以 Git 拒绝了。

标准解法是先把远程的更新拉下来，解决冲突后再推送：

git pull --rebase origin main

--rebase的作用是把本地未推送的提交临时摘下来，应用在远程最新提交的后面。过程中如果遇到冲突，按第 5.3 节的方法手动处理，处理完后：

git add 冲突文件 git rebase --continue

最后：

git push

这里解释一下为什么会用rebase而不是默认的merge。rebase生成的提交历史是一条直线，更干净，适合个人功能分支与远程主线同步的场景。多人协作如果都遵守"pull 用 rebase、合回主分支用 merge"的约定，日志会清晰很多。

个人建议：新手阶段不用把rebase想得太复杂，把它当成"在别人最新提交之上重新应用我的提交"就好。只要记住不要对已经推送到公共分支的提交执行 rebase，就不会捅出大篓子。

按我自己一路踩坑过来的体会，Vue 项目和 Git 的组合，最舒服的状态就是"小步提交、频繁回看"。每完成一个小功能就提交一次，提交之前花十秒看一眼git diff；不确定某个操作会不会破坏代码时，先执行git stash或者打一个标签，给自己留好退路。刚开始用 Git 的时候命令记不全很正常，我到现在也还会敲git status确认状态，但这不丢人，反而能帮你少犯很多错。希望这篇笔记能让你在写 Vue 代码的时候，不用再担心"改坏了怎么办"。