企业官网建设流程全解析

1. 先别慌：把Git想象成“会存档的游戏”

如果你也是那种一打开Git教程，看了三行就默默关掉的人，我特别理解。现在的教程要么把“分布式版本控制系统”挂在嘴边，要么直接丢出一长串命令让你硬记。但这篇Git操作手册，我想换个讲法：不背术语，不绕弯子，帮你把Git当成一个“会存档的游戏”，再一步步走完从本地提交到远程协作的完整流程。它适合刚接触Git的同学，也适合那些用了半年、一遇到合并冲突就发怵的老朋友。我保证命令一个不少，但所有的解释都会用大白话。

1.1 快照到底是什么东西

初次听到“Git存的是快照”，很多人会懵。我的理解是：快照不是“这次改了什么”的差异记录，而是“拍了一张当前所有文件的照片”。Git会把每个文件的内容按哈希值存储下来，每次提交时生成一个commit对象，这个对象记录了当时所有文件的完整状态。

为什么用完整快照而不是只存差异？因为恢复起来快。你要切回三个月前的某个版本，Git直接调出当时的完整文件就行，不用先把所有差异从头到尾算一遍。代价是仓库会变大，但Git对相同内容的文件做了去重，所以实际情况没有想象中那么夸张。这也是Git分支操作非常便宜的底层原因——分支创建时只是复制了一个指针，根本没复制文件。

如果你曾经用文件夹备份过代码，应该体会过那种痛苦：一个项目复制出七八个带日期的文件夹，过两周自己都想不起来哪个是最新的。Git的快照机制从根本上解决了这个问题，它让你放一百个心：随便改，随时能回到任意一个历史时间点。

1.2 三个区域是新手第一道坎

大多数人一上来就卡在暂存区这个概念。我用一个比喻：你要给朋友寄一盒水果。工作台是水果篮（工作区），你往里放苹果、放香蕉，这是在工作区修改；你把这些水果装进打包盒（暂存区），这叫add；你把盒子交给快递员发出（提交），这叫commit。所以add只是把改动装进打包盒，还没有真正发出去；commit才是生成一个正式的存档点。

为什么要分两步？因为一个提交应该是“一个逻辑完整的改动”。假如你改了三个文件：两个是在修一个bug，第三个是顺手调整样式。你完全可以只把前两个文件add进当前提交，第三个留到下一次提交。这样以后看日志，每个提交在做什么一目了然。

用git status可以看到三个区域的实时状态，配合git diff查看没add的改动，git diff --cached查看已经add的改动。养成提交前先看看diff的习惯，比你事后追后悔药要轻松得多。

1.3 HEAD、master、main这些词别怕

后面所有命令都会碰到HEAD。它就是一个“当前你在哪”的指针，指向当前分支，也间接指向最新的提交。以前Git默认分支叫master，现在新仓库更流行叫main，两者本质上一样，只是名字不同。不要被这些词吓到，它们就是一条主线的名字。

看到HEAD -> main这种提示，意思是“你现在站在main分支的最新提交上”。这些概念现在不需要死记，后面实际操作中会反复出现，用几次自然就熟了。我见过太多人第一阶段就纠结“HEAD到底在指向谁”，结果命令行没跑几遍就放弃了。真的没必要，先把流程跑通，回头再看这句话，你会觉得简直不要太直白。

2. 环境准备：装好Git，配好身份，不然代码“没有署名”

2.1 不同系统上的安装方式

先说结论：不要纠结“最新版”“稳定版”哪个更好，能装上就行。

Windows用户直接到官网下载安装包，一路下一步。唯一要留意的是，安装时如果有“Adjusting your PATH”的选项，务必选“Git from the command line and also from 3rd-party software”。macOS可以先用Homebrew执行brew install git，不熟悉Homebrew的话去官网下dmg安装包也可以。Linux用户直接用发行版自带的包管理器，比如sudo apt install git或sudo yum install git。

装完在终端敲一句git --version，能输出版本号就说明安装成功了。这一步过了，剩下的都是流程问题。我教过的新手里，没见过谁卡在这一步超过十分钟。

2.2 第一次提交前必做的三件事

第一次提交一定会碰到的错误是：Please tell me who you are.这不是系统在为难你，而是Git不知道该在提交记录上写谁的名字。至少配置两个全局参数：

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

用git config --list可以查看当前生效的配置。注意，user.email不一定要和某个代码平台的账号一致，但建议一致，这样平台才能把你提交的记录对应到你个人账号上。如果同一台机器上不同项目需要不同署名，可以在某个仓库内不带--global重新配置，仓库内的配置会覆盖全局配置。

还有一件事很容易被忽略：配置默认编辑器。如果你不配置，某些命令（比如后面要讲到的git commit --amend）会默认打开vi编辑器。不熟悉vi的人会卡在“怎么退出”这个荒诞问题上，别问我怎么知道的。建议把你熟悉的编辑器设置成默认编辑器：

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

上面这句是配置成VS Code，如果你习惯别的编辑器，换成对应命令即可。

2.3 两个必须提前避开的坑：换行符和中文乱码

第一是换行符。不同操作系统对换行符的处理不一样，Windows默认CRLF，Linux和macOS默认LF。如果在Windows上拉了别人（大多在Linux上）提交的代码，经常看到 “LF will be replaced by CRLF” 的警告。最稳妥的做法是在Windows上把core.autocrlf设置为true，让Git在提交时自动把CRLF转成LF，检出时再转回CRLF：

git config --global core.autocrlf true

这个配置不做，diff的时候会出现“整个文件都变了”的假象，代码里明明只动了一行，git却告诉你几百行都改了。遇到这种灵异事件，先检查换行符配置，多半能解决。

第二个坑是中文路径和中文提交信息乱码。Windows上如果git status显示的是八进制编码而不是中文文件名，执行这条命令就能解决：

git config --global core.quotepath false

这两条配置做完，后面能省下大量“莫名其妙”的时间。环境配置这件事，不要嫌烦，前人踩过的坑，你用一分钟填平，非常划算。

3. 本地仓库五连招：init、add、commit一个都不落

3.1 从零开始建一个仓库

先找个目录演示一遍完整流程：

mkdir git-demo cd git-demo git init echo "# 我的第一个项目" > README.md git add README.md git commit -m "docs: 初始化项目，添加README"

git init只是让这个目录变成一个“被Git接管”的目录，它会在文件夹里生成一个隐藏的.git目录，所有版本信息都存在这里。平时工作完全不需要动这个目录，知道它的存在就够了。

git add README.md把README装进暂存区，git commit才真正形成第一个版本。很多人改了文件、git status也能看到、但一commit就提示 “nothing to commit”，这就是忘了git add。记住这个节奏：改文件 →git status看状态 →git add对应文件 →git commit。顺序不对，操作一定别扭。

3.2 git status和git diff是“体检报告”

git status告诉你有几个文件改了、几个被删了、几个还没提交。git diff专门看“工作区和暂存区之间到底差了什么内容”。提交前养成先diff再commit的习惯。

我看到太多人直接git add .然后git commit，等到想回退时才发现一个提交里混着十个互不相干的功能，那场面简直灾难。改完代码先git diff扫一眼，确认改动内容和自己预期一致，再决定要不要add和commit。这个习惯花不了三十秒钟，但能帮你躲掉很多清理历史的苦力活。

3.3 .gitignore：这些文件一辈子都不该进仓库

node_modules目录、编译产物、.env环境变量、IDE的配置文件夹，这些都不应该提交。处理方式是项目根目录放一个.gitignore文件：

node_modules/ dist/ .env *.log .idea/ .vscode/

.gitignore是Git专门用来无视某些文件的黑名单。这里有一个特别容易踩的坑：如果某个文件已经被跟踪提交过，再加入.gitignore不会让它“消失”，需要执行：

git rm --cached 文件名

这会把文件从版本控制里移除，但保留在本地磁盘上。至于.env这种敏感文件，一旦被提交过并且push到了远程，最正确的做法是立即轮换密钥，因为历史记录里已经有人能看到了。删除文件并提交根本不够，切记。

3.4 提交信息怎么写：从“update”到“电梯播报”

提交信息是写给未来的自己和同事看的。我现在习惯用一种简单的格式：前缀冒号加一句描述。feat表示新功能，fix表示修bug，docs表示文档改动，refactor表示重构。比如：

git commit -m "fix: 修复登录超时后页面白屏的问题"

这比“update”“修改了一些东西”“不知道改了啥”要友好得多。想象一下，三个月后的你回来看日志，你最希望看到什么样的提交说明？按这个标准写就行。不要小看这一步，项目成员的提交信息风格，基本决定了项目历史可读性的天花板。

4. 分支操作：别怕，分支就是“平行世界的存档线”

4.1 分支是一条可移动的线，不是文件夹副本

很多人以为分支就是把代码复制一份。实际上，Git创建分支的开销小得几乎为零，因为它只是创建了一个指向某个提交的指针。你可以把分支理解成“便利贴”，贴在那个提交上。你在便利贴上继续提交，便利贴就跟着新提交往前滑；主线上的便利贴还停在原处。HEAD标记着你现在正站在哪张便利贴前。

团队协作里，主分支一般用来放“永远可运行”的版本，开发新功能、修bug都在临时分支上做，做完了再合并回主分支。这样主分支始终干净、稳定。如果你在本地一个人写项目，也建议用分支，因为你可以随时开一条实验分支去尝试一个方案，不行就删掉，对主干零影响。

4.2 创建、切换、删除分支的常用命令

新版Git建议用switch代替checkout切换分支，命令更直观，不容易和“恢复文件”搞混：

git branch feature/login # 创建分支 git switch feature/login # 切换到该分支 git switch -c feature/logout # 创建并切换 git branch -d feature/login # 删除已合并分支

切分支后，工作区的文件会变成那个分支的“存档内容”。注意：当前分支有未提交的改动时切换分支会有风险，轻则把改动带到新分支，重则因为文件冲突拒绝切换。我现在养成一个习惯：切分支前先git status看一眼，确认干净了再动。这个习惯救过我太多次。

4.3 合并分支与冲突处理流程

把feature合并回主分支，先切回主分支再执行git merge：

git switch main git merge feature/login

如果两个分支没改同一个文件，Git能够自动完成合并。如果改了同一处，就会提示冲突。别怕，这恰恰是Git保护你的方式：它把两个版本的冲突区域用标记标了出来，要你拍板决定保留哪个。

打开冲突文件，你会看到：

<<<<<<< HEAD 原来的内容 ======= 分支里的内容 >>>>>>> feature/login

意思是用主分支的内容，还是用feature分支里的内容？手动把不需要的版本删掉，同时把<<<<<<<、=======、>>>>>>>这三行标记也删干净，然后git add这个文件，再git commit，冲突就算解决了。解决完可以跑一遍测试，因为有冲突的代码往往是两个功能叠在一起，你不能保证手选的结果一定正确。第一次遇到冲突时不要慌，Git没有坏掉，只是需要你做一个决定而已。

4.4 分支命名与协作习惯

团队协作时，分支名最好能一眼看懂。feature/xxx表示新功能，fix/xxx表示修复，chore/xxx表示杂项维护。尽量一个分支只干一件事，功能做完、合并、删除。长期不合并的“僵尸分支”是团队协作的隐形杀手。

我见过最头疼的情况是：某同学开了一个分支，写了一半，搁置了三个月，然后所有人都忘了这个分支的存在。等到某天他突然把它合并回主干，带来一堆过时代码和冲突。避免这个问题的方法只有一个，分支尽量短命，一个功能一个分支，干完就合，合完就删。

5. 远程仓库：clone、push、pull，把本地代码“搬回主线”

5.1 把本地仓库关联到一个远程仓库

远程仓库本质上就是一个放在服务器上的Git仓库，可以是某个代码托管平台提供的仓库，也可以是公司内网自建的Git服务。不管哪种，操作逻辑都一样。关联命令：

git remote add origin 仓库地址

origin是远程仓库在你本地的别名，你也可以叫它别的名字，但大家约定俗成叫origin。用git remote -v可以查看当前关联的远程地址。如果你修改了远程仓库地址，不用删除重加，一条命令改掉就行：

git remote set-url origin 新的仓库地址

还有一种方式是用git clone直接克隆一个已有仓库到本地，它会自动把远程地址配置好，省去了手动关联的步骤。克隆操作相当于是“把远程仓库完整复刻到本地”，包括全部历史记录。

5.2 push和pull的日常节奏

把本地提交推上去：

git push origin main

把远程的最新提交拉下来：

git pull origin main

pull其实做了两件事：先把远程分支同步到本地，再把远程分支合并到当前分支。所以pull完如果提示冲突，处理流程和本地merge冲突一模一样。

关于push时可能要输入账号密码的情况，如果用的是HTTPS协议，配置好凭据助手可以避免重复输入；如果用的是SSH协议，需要提前把公钥配到托管平台。具体操作每个平台略有差异，直接看对应平台的官方文档比到处问人要快。

我现在的工作习惯很简单：开始办公前先pull，告一段落或下班前push。核心原则是不要长时间不pull。冲突越积越多，解决成本高到你后悔当初的懒惰。

5.3 常见错误：push被rejected

最典型的是git push后提示 “non-fast-forward” 或 “rejected”。意思是本地落后于远程，远程有你没有的提交。解决办法很清楚：

git pull origin main git push origin main

先把远程的拉下来合并，再把本地推上去。如果合完有冲突，解决冲突之后再次add、commit，然后push。这里不建议新手一上来就用rebase来整理历史，merge虽然会多一条合并记录，但对理解Git的运作机制更友好。等你搞清楚commit、merge、rebase的区别，再考虑优化历史也不迟。

6. 撤销与回退：commit做错了，怎么安全地“反悔”

6.1 改了文件但还没add

想放弃工作区的修改，恢复成上一次提交的状态：

git restore 文件名

旧版命令是git checkout -- 文件名，也能用，但单词含义不清，新手容易懵。restore更直观：把这个文件恢复到暂存区或最近一次提交里的样子。注意：这个命令会直接覆盖你的修改，并且没有确认提示，所以不要手滑。如果你是真心不想要这些改动了，用它没问题；如果只是不确定，先移到一边再说。

6.2 已经add但还没commit

想把这个文件撤出暂存区：

git restore --staged 文件名

文件内容不会变，只是它不再是“准备提交”的状态。如果你想把文件内容也还原，再加一步git restore 文件名。这一对restore命令覆盖了“已改未add”和“已add未commit”两种最日常的撤销需求，掌握了它们，你的操作容错率会高很多。

6.3 已经commit但想退回版本

这时就要区分reset的三种模式了。命令后面的参数决定了你丢到哪一层：

git reset --soft HEAD~1 # 回到上一个提交，但改动保留在暂存区 git reset --mixed HEAD~1 # 回到上一个提交，改动保留在工作区（默认） git reset --hard HEAD~1 # 回到上一个提交，改动完全丢弃

--hard看着最爽，但丢弃的内容无法轻易找回。我的建议是：如果不是确定不要了，优先用--soft或--mixed。HEAD~1表示上一个提交，也可以用提交哈希值指到任意历史位置。

顺带说一句，网上很多教程会让新手直接git reset --hard，我觉得这种教学方式非常不负责任。我自己早期就干过一次，按reset --hard把改了一整天的代码全干没了，还好后来知道有git reflog才救回来。现在我做任何reset前都会先看一眼git log和git status。先搞清楚自己在哪儿、要到哪儿，再动刀。

6.4 已经push到远程了怎么办

公共分支上的历史是“大家的”，硬reset再强推会让其他协作的人一头雾水。安全做法是生成一个反向提交：

git revert 某个提交的哈希

revert会新建一个提交，把之前那次的改动全部撤销回去。它不改写历史，只是“加一个去后悔药的存档”。这样别人拉代码时不会遇到任何冲突，也能在revert提交信息里看到你撤销的理由。提交历史可能不那么干净，但公共分支的安全比漂亮更重要。

6.5 临时藏起手里的改动：git stash

正在开发一半，突然要切分支去修一个紧急bug。手里这些改动不想提交也不能丢，怎么办？

git stash # 把当前改动暂存到一个堆栈里 git stash pop # 回到原分支后取回来

stash就像一个临时储物柜，会把工作区和暂存区的修改收拾起来，还你一个干净的工作区。切过去修完bug，再切回来，git stash pop就能拿回原来的改动。万一pop之后有冲突，手动解决后正常add、commit即可。如果stash多了，用git stash list查看堆栈里存了什么。这个命令对开发者来说是那种“不是每天都用，但一旦用上就能救命”的存在。

7. 常见问题排查实录：这些报错和“灵异事件”我都帮你趟过

7.1 Please tell me who you are

首次提交最常见。解法就是回到第2章配置user.name和user.email。如果你不想用全局身份，在当前仓库内配置一份也行。这个报错本身不是技术问题，是Git在提醒你“做人要留名”。

7.2 LF will be replaced by CRLF

换行符警告。按第2章的core.autocrlf配置好即可。这个警告本身不致命，但会造成diff看起来“整个文件都变了”，让人误以为程序出了问题。在Windows上做开发不配置这个，后面基本天天都要和它打交道。

7.3 中文名文件显示成乱码路径

git status看到的是一串像"\345\233\276\347\211\207.png"的内容，执行：

git config --global core.quotepath false

然后重开终端就好了。类似这样的小配置，做一次就一劳永逸，属于“第一次遇到必须查，查完就再也不会忘”的问题。

7.4 detached HEAD 状态

提示你处于分离头指针状态。原因是直接checkout了某个哈希值而不是分支名，HEAD不再指向任何分支。在这个状态下继续提交，会形成一个“没有分支引用”的提交，最不设防的情况下，一旦切走就可能找不回来了。

如果只是临时看看代码，直接切回原分支即可。如果你想保留这里的改动，执行git switch -c 新分支名，把它变成一个有名字的正式分支。这个状态本身不可怕，可怕的是你在这个状态下提交了东西然后直接切走。

7.5 误删了分支或者文件

分支被误删，只要还记得删除前的分支名，先用git reflog查看操作记录，找到对应哈希，再用git switch -c 分支名 哈希救回来。文件被误删且还没提交过，用git restore 文件名恢复。Git不是一个一次性的世界，很多操作都可以挽回，前提是别乱用--hard，并且知道reflog的存在。

7.6 提交完发现信息写错了或者漏了文件

如果还没push，用git commit --amend来修改上一次提交。它会打开编辑器让你重写信息，也可以先git add漏掉的文件再amend。但有两件事必须记住：amend会改变提交的哈希，只适合修改“最近的”那一次提交；已经push到远程的提交千万别用amend，否则别人pull时会看到历史变了，导致一堆同步问题。

我常用的速查表：

8. 几个让我省心的Git习惯，越早养成越顺

8.1 小步提交是最好的后悔药

我现在提交的标准是“一个提交只做一件逻辑上的事”。每次commit足够小而清晰，出了问题才知道去哪个提交里排查。很多初学者喜欢憋着一周再commit，结果一提交就是几百行的diff，任何人看到都头皮发麻。宁可在十分钟内提交两次，也不要攒一天的改动。小步提交还有一个隐藏好处：可以随时回到任何一个中间状态去验证，这比“全局回退”要安全得多。

8.2 用命令别名把高频操作变短

那些高频命令可以设成别名：

git config --global alias.lg "log --graph --oneline --decorate" git config --global alias.s "status -sb" git config --global alias.cm "commit -m"

之后git lg看整个分支历史，比原版log命令舒服不少。git s则很轻量，随时能看到分支跟踪情况和待提交改动。别小看这一个小配置，它每次省两秒，但一天下来就是几十秒钟的注意力，而且大幅降低了敲错命令的概率。

8.3 永远不要把密钥和账号密码提交进仓库

.env、密钥文件应该直接写在.gitignore里。一旦失手提交并且push了，不要只删除文件再提交，因为历史记录里还留着完整内容。正确的处理是立刻轮换密钥、账号密码，必要时使用工具改写仓库历史。太多真实案例就是因为一个.env被提交，整个服务被拖垮。这已经不是Git操作层面的建议，而是安全底线。

8.4 提交前看一眼git status和git diff

听起来像废话，但我真的见过太多人提交完才发现把不该提交的文件带上了。提交前花三十秒用git status确认要提交的文件范围，再用git diff扫一遍改动内容，能避免绝大多数尴尬。尤其是用git add .顺手全加的习惯，迟早会出事。

最后说一句真心话。Git一开始确实让人觉得处处是坑，但它最神奇的地方是：一旦你理解了“提交就是存档、分支就是平行世界、HEAD就是你现在站的位置”这三个比喻，绝大多数命令都是顺着这个逻辑自然生长出来的。我后来教新人也从不让他们背命令，而是先玩一玩“改动→暂存→提交”这个基础流程，等直觉建立起来以后，命令自然就记住了。这篇Git操作手册能覆盖的只是常用主干，把它当作压惊的速查手册刚刚好。等把这些命令用熟，再去看进阶的变基、精选提交、子模块，会轻松得多。我不会祝你“顺利”，因为照着摸一遍，真的不需要运气。