企业官网建设流程全解析

1. 把Git当网盘，是多数新手的第一道坎

我第一次正经接触Git，是入职第一周被安排去看一份老项目交接文档。文档第一页写着“版本管理请使用Git，别再用xx项目_final_0520.zip这种命名方式”。我嘴上没吭声，心里却嘀咕：Git和网盘同步有什么区别？不就是把最新代码传上去，留着历史记录以防万一吗？结果没几天就因为乱用reset删掉了自己的本地提交，又不知道怎么找回来，硬着头皮在新分支里重打了一遍同名代码，事后被同事笑语了半天。

这段经历让我明白，学Git的第一关不在命令，而在心智模型。

Git真正做的事，是用“提交对象”构建一份完整历史。每次git commit，Git都会把项目当时的文件状态打包成一个快照，并记录下这次快照的作者、时间、父提交等信息。你完全可以把它当作单机游戏的存档机制：同一场冒险里可以保存十个档位，任何一个时刻都能读档，而且存档之间互不覆盖——网盘可没这个能力。

理解Git后，你只需要记住三个区域，后续所有命令都能靠这套地图推导出来：

• 工作区（working directory）：你用编辑器看到、改动的实际文件
• 暂存区（staging area / index）：决定“下一次提交要包含哪些改动”的中间区
• 版本库（repository，也就是.git目录）：所有提交记录和分支数据存放的地方

git add是把改动送进暂存区，git commit是把这个“购物车”固化成一次快照，git push是把本地快照同步到远端仓库。每次你觉得“Git怎么又乱了”的时候，先执行git status看看当前处在哪一步，再决定下一步操作，基本不会走偏。

2. 从安装到密钥配置：新手最易跳过、老司机也会翻车的三件事

2.1 别只知道下载安装包，系统包管理器更省心

如果你还在搜索引擎里找“git下载安装教程”，然后下载安装包一路Next，其实也没错，但有更省心的选择：

• Windows：用winget install --id Git.Git -e --source winget，安装和后续升级都方便得多。装完在Git Bash里输入git --version，能输出版本号就说明环境没问题。
• macOS：终端里直接敲git --version会自动触发Xcode Command Line Tools的安装提示，或者用brew install git拿最新版。
• Linux（Ubuntu/Debian）：sudo apt install git；如果是CentOS/Fedora类系统，对应sudo dnf install git。

安装本身没什么门道，但有一个坑非常隐蔽：行尾符。Windows文件里换行是CRLF，macOS/Linux是LF，如果团队跨平台协作，Git会因此产生大量“明明没改，为什么diff全变了”的假差异。Windows上建议全局配置git config --global core.autocrlf true，提交到仓库时自动转成LF；macOS/Linux则用git config --global core.autocrlf input，只负责提交时转换。

2.2 装完先配置身份，否则提交记录会变成“无名氏”

很多人clone完仓库就急着改代码，第一次commit之后才发现提交人显示成一串“guest”，原因就是没配user.name和user.email。这两项写在每次提交的作者字段里，建议全局配好：

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

不强制要求邮箱和Gitee/GitHub注册邮箱一致，但保持一致能让平台把提交精准关联到你的账号，图表、贡献统计都会正常显示，团队里定位问题责任人时也更省事。

顺手再配两个选项。一个是默认分支名：

git config --global init.defaultBranch main

否则git init初始化出来的仓库默认叫master，和远程默认的main不一致，后面推送时容易多出“分支名对不上”的麻烦。另一个是中文文件名显示：

git config --global core.quotepath false

不设置的话，git status遇到中文文件名会显示成\346\265\213等一串八进制转义，吓得新手以为文件损坏了。

2.3 三种配置级别和一张速查表

Git的配置分system、global、local三个层级，优先级从低到高是：system（机器所有用户）→ global（当前用户）→ local（当前仓库）。在某个仓库目录里执行不带--global的git config，改的就是这个仓库的local配置，更适合做存量老项目和新建标准不一致时的临时调整。

2.4 Gitee SSH密钥配置：全网都在搜的那步

“git配置gitee密钥”是热搜榜上的常客，流程其实固定。SSH密钥的作用是让Git走加密通道和远程仓库通信，省去每次push/pull输密码。

第一步，生成密钥对。在Git Bash或终端里执行：

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

一路回车，默认保存到~/.ssh/id_ed25519。密钥算法优先用ed25519，安全性高于老式RSA 2048，生成的密钥也更短；除非要兼容特别老的内网服务端，才需要用-t rsa -b 4096。

第二步，把公钥内容复制出来。Windows下用clip < ~/.ssh/id_ed25519.pub，macOS用pbcopy < ~/.ssh/id_ed25519.pub，Linux直接cat ~/.ssh/id_ed25519.pub手动复制。注意复制的是带.pub后缀的公钥，不是私钥——私钥一旦泄露，别人就能冒充你操作仓库。

第三步，打开Gitee个人设置里的“SSH公钥”页面，粘贴保存。然后测试连通性：

ssh -T git@gitee.com

看到类似“Hi xxx! You've successfully authenticated”的提示，就代表通了。最常见的排查点是：公钥复制时多带了空格或换行，或者不小心复制成了私钥内容，重新贴一次基本能解决。

3. 日常三步曲的底层逻辑：为什么add、commit、push是三步而不是一步

不少从SVN转到Git的人会问：提交为什么不能一步到位？先add再commit，多此一举吗？这个设计恰恰是Git好用的原因之一。

暂存区最实用的价值是“分批提交”。同一个文件里改了两处，一处是修复登录按钮样式，一处是调整接口超时时间，如果用git add .整体提交，两个毫无关联的改动就会混进同一个commit。后面某天需要单独回滚登录按钮修复，或者老板让你把这行加入发布说明，你就只能对着一个大杂烩提交干瞪眼。

正确做法是拆成两次提交：

git add src/components/login.tsx git commit -m "fix(login): 修复移动端登录按钮点击区域过小" git add src/utils/request.ts git commit -m "chore(request): 调整超时时间为15秒"

哪怕是同一个文件，也能用git add -p进入交互式分片暂存，逐个hunk选择要提交的片段。这个能力在SVN时代几乎不可能实现，属于Git真正值得用起來的高级习惯。

再说说commit信息。每次写git commit -m "update"，都等于给你的存档起名叫“草稿”，一个月后翻历史全靠猜。更推荐约定式提交的简化版——feat表示新功能，fix表示修bug，docs表示文档，chore表示杂务，refactor表示重构，后面用一句简洁说明描述做了什么。不用追求百分之百符合规范，但至少要让几周后的自己看得懂。

push和pull的关系也需要掰清楚。本地commit只是“存档到硬盘”，push才是把存档同步到远端；pull则拆成fetch（把远程新提交拉到本地仓库）和merge（合并进当前分支）两步。正因为默认pull会做merge，有时会弹出一个编辑器界面让你输入合并说明，看起来像卡死了。如果不想被这种“假卡死”吓到，建议把默认行为改成：

git config --global pull.rebase true

这样pull会直接采用“拉取远程最新 → 把本地未推送的提交重新排在主线之后”的方式，历史更干净，也不会频繁出现“Merge branch 'main' into ...”这类噪声。前提是你知道rebase的含义，这点后面单独展开。

最后，push被拒绝是每个新手都想砸键盘的时刻，原因通常是远程分支已经领先于本地分支。正确顺序是git pull --rebase，解决冲突后git add，需要时git rebase --continue，最后再git push。

4. commit --amend的正确用法与纪律：改错信息、漏提交的后悔药

“git commit --amend怎么使用”能进热搜，说明太多人都干过“提交完才发现不对”的事。先给结论：amend的作用是修改最近一条提交，既能改提交信息，也能把新的暂存内容并入上一条提交。

4.1 三种常用的amend姿势

第一种，只改提交信息。手滑把“feat: 新增用户列表”写成了“feat: 新用糊列表”：

git commit --amend -m "feat: 新增用户列表"

第二种，补提交漏掉的文件。先add再amend，不重新打开编辑器：

git add README.md git commit --amend --no-edit

--no-edit的意思是“沿用原提交信息，别让我再输一遍”。只补内容不动信息时特别顺手。

第三种，修改上一条提交的作者，适用于用错账号提交的情况：

git commit --amend --author="Alicia <alicia@example.com>" --no-edit

4.2 什么情况下绝对不能amend

最重要的纪律是：如果提交已经push到了共享分支，并且同事已经pull下去，就不能amend。

原因在于，amend的本质是“新建一个提交对象，替换掉原来的提交”。本地做没问题，一旦push到远程，就相当于改写了公共历史。同事下次pull时，Git会发现两头历史分叉，轻则报错喊冲突，重则让整个分支乱成一锅粥。

我自己在这上面吃过实亏。当时把一个提交推到团队dev分支后，又amend改了说明文字，最后直接用git push --force覆盖了远程。同事的本地代码瞬间脱离远程轨道，在群里被艾特了一下午。后来养成的判断标准是这样：

• 提交只在本地、从未push：随便amend，想改几次就几次
• 提交已push但在自己的私有分支，且没人和你协作：可以用git push --force-with-lease覆盖，但尽量少用
• 提交已push到共享分支：不要amend，改用新增commit或revert

顺带一提，如果确实需要强推，优先用--force-with-lease而不是--force。前者会检查远程分支是否还是你上次拉取的状态，防止误覆盖别人新推的内容——这个参数是很多事故的最后一道保险。

4.3 想改的不是最近一条，怎么办

amend只能修改最近一次提交。如果想改倒数第三条，就得用交互式rebase：

git rebase -i HEAD~3

Git会列出最近三条提交的待办清单。要把某一条改信息，把行首的pick改成reword；要把某一条合并到前一条，改成squash或fixup。squash会打开编辑器让你整理合并后的提交信息，fixup则直接沿用目标提交的信息，不弹编辑器，效率更高。只要这些提交还没推出去、还没被人拉取，这套操作就是安全的。

5. 看历史、比差异、撤改动：一套安全的版本回退手册

版本管理落到具体动作，无非三件事：看历史、比差异、撤改动。但很多人把这三步做成了“盲操作”，一遇上问题就reset --hard，最后连滚带爬地把代码删没了。

5.1 让git log好看又直观

默认的git log在提交一多时完全不想看。建议直接养成用这串的习惯：

git log --oneline --graph --all --decorate

--oneline让每次提交缩成一行，--graph画出分支分合图，--all显示所有分支，--decorate标出分支和标签指向。接手陌生老项目时，这一条命令足以让你快速理清项目主线和旁枝。想进一步看某次提交改了哪些文件，追加-p，比如git log -2 -p表示最近两条提交的完整diff。

5.2 diff也要分清对象

git diff有三个形态经常被混用：

• git diff：工作区与暂存区的差异，也就是“还没add的改动”
• git diff --cached（或--staged）：暂存区与版本库的差异，也就是“即将提交的内容”
• git diff HEAD：工作区与最近一次提交的差异，包含未暂存和已暂存的全部改动

调试时如果“明明改了，git diff却没反应”，先想想改动到底处于哪个区域。这个判断习惯能省掉大量困惑时间。

5.3 reset三档对照：soft、mixed、hard

git reset的本质是移动当前分支指针到指定提交，三档的差异在于指针移动后，暂存区和工作区的内容怎么处理。

举个典型场景：刚刚commit完，发现这次提交内容太杂，想拆成两个更清晰的提交，但代码完全不想丢：

git reset --soft HEAD~1

HEAD回退一个版本，暂存区和工作区原封不动，等于只取消了“提交”这个动作，接下来可以重新add、重新commit。如果只是想取消暂存状态、保留修改，用git reset HEAD（即--mixed）。

至于git reset --hard，我把它当核选项，只有确认“这部分改动真的不要了”或者“远端还有其他备份”才能用。更严重的风险在于：一旦基于被硬回退的分支继续提交并push，远程历史也会被强制改写，后果比amend严重得多。

5.4 已推送的改动，用revert而不是reset

reset适合处理本地未推送的提交。已经推到共享分支的错误提交，正确撤销姿势是git revert：

git revert a1b2c3d

它做的事是“生成一个新提交，反向套用a1b2c3d的改动”，让代码回到该提交之前的状态。关键优点是：新提交不改变原有历史，所有同事pull下来都安全。revert不需要记完整哈希，git revert HEAD就是撤销最近一次提交。

我的操作铁律很简单：本地回退用reset，远程撤销用revert，绝不混用，尤其不在团队分支上reset后强推。

5.5 不小心删了提交，reflog能救命

Git内部有个经常被新手忽略的机制——reflog，它记录了HEAD指针的每一次移动。哪怕执行了git reset --hard把分支指到了几天前，只要那些提交还没被系统清理，就有机会找回来：

git reflog

看到一条条“HEAD@{0}: reset: moving to xxx”类似记录后，找到误操作之前的提交哈希，然后：

git branch recover-branch <哈希>

用一条新分支指向那里，丢失的提交就“捞”回来了。我靠这招救过不止一次项目。所以真的不用怕Git操作，只要别在误操作后立刻乱改一堆东西，reflog几乎总留给一条后悔的缝隙。

6. 分支协作实战：rebase、merge与冲突处理的完整路径

6.1 分支不过是个会移动的标签

不少新手把分支想象成“代码的另一个副本”，其实是误会。Git里的分支只是一个指针，指向某次提交。创建dev分支，不是复制一份代码，只是多了一个标签，代价极低。正因如此，Git世界里频繁建分支、随时删分支都很正常，不用像以前印象里那样“动主干前先给全组拉个会”。

创建并切换分支有两种写法：

git checkout -b feature/login # 或者Git 2.23之后的新写法 git switch -c feature/login

两种等价。用完不再需要时，git branch -d feature/login即可删除。

6.2 merge与rebase：两种历史拼合思路

把feature分支的工作并入main，最常用merge：

git checkout main git merge --no-ff feature/login

--no-ff的意思是“不做快进合并”，强制保留一个合并提交，清楚说明“这里有一条分支被并进来了”，团队协作时历史可读性更好。如果feature上没有新提交，不写--no-ff时Git可能直接快进移动main指针，看起来像main自己长出了几个提交，不利于追溯。

rebase是另一套思路：把feature上的提交一个个“摘下来”，重新排到main最新提交后面：

git checkout feature/login git rebase main

结果是线性的提交记录，没有多余的merge commit，非常干净。代价是rebase改写了feature上提交的哈希，所以绝对不能在别人共享的分支上对别人的提交做rebase。我的个人经验：自己开发中的功能分支随便rebase保持整洁；多人协作的长效分支以merge为主。

6.3 冲突解决：第一次“撞车”真没那么可怕

冲突发生在Git合并时不知道“听谁的”。比如你和同事都改了同一个文件的同一段代码，Git会在文件里留这样的标记：

<<<<<<< HEAD 今天的方案：按钮显示“确认” ======= 同事的方案：按钮显示“确定” >>>>>>> feature/login

解决方式机械化：打开冲突文件，阅读两边代码，决定保留哪一份或合成逻辑正确的一份，然后删掉<<<<<<<、=======、>>>>>>>这三行标记，最后git add这个文件。

如果是merge过程，接着git commit完成合并；如果是rebase过程，执行git rebase --continue继续后续提交。想中途撤退，git merge --abort或git rebase --abort能回到操作前状态。

这里想强调心态：冲突不是灾难，是协作的必然摩擦。只有少数文件冲突时，十几分钟就能处理完；真正要警惕的是“一次合并冲突几十个文件”，那八成意味着有人在一个分支上闷头改了太久，没有及时同步主分支。

6.4 一个很值得养成的同步习惯

我反复和同事强调的习惯很简单：开始新任务前先git pull；准备push前先git pull --rebase；如果本地攒了两三条“临时提交”，push前用rebase -i先整理一遍再push。这样远程提交记录基本能保持清晰，代码review起来也省心。很多人抱怨Git麻烦，其实多数麻烦都来自没及时同步，而不是Git本身。

7. 我见过的“怪命令”和三个小习惯

7.1 IDE日志里那串神秘命令到底是什么

用IDE内置Git时，有时会在控制台看到这样一串命令：

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks log -p

我当年第一次看到也懵了，拆开看其实不神秘：

• -c diff.mnemonicprefix=false：临时覆盖配置，让diff不使用a/、b/这种缩写前缀，改为显示真实目录名，方便IDE解析
• -c core.quotepath=false：临时开启中文文件名友好显示
• --no-optional-locks：告诉Git本次操作不要加仓库可选锁，避免IDE频繁调用Git时互相阻塞

所以这不是什么骇人命令，而是JetBrains系列的IDE在调用Git时，为适配自身界面显示而追加的参数组合，对仓库本身没有副作用。理解了这点，以后在IDE或CI日志里再看到类似“怪命令”，就能明白只是“临时覆盖配置再执行命令”的组合动作而已。

7.2 用别名把高频命令磨顺手

Git支持给命令起别名，我的全局配置里长期保留这几行：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg "log --oneline --graph --all --decorate" git config --global alias.last "log -1 HEAD --stat"

为什么执着于别名？因为git status每天要敲无数次，手指会诚实告诉你，少敲一个字母都是胜利。

7.3 我做项目时的三个Git小习惯

最后分享三个实际踩过坑之后总结出来的习惯。

第一个：每个仓库创建时就写好.gitignore。Node项目忽略node_modules，Python项目忽略__pycache__和.venv，Java项目忽略target。不要在文件已经被跟踪之后才想起补.gitignore，因为Git会认为这些文件已经受管，此时需要git rm --cached逐个清理，平白多一道工序。好的.gitignore在项目交接时能省出大量口水。

第二个：重要操作前先执行git status和git diff。几乎每次“误删代码”“提交错文件”，都源于没看这两条命令。十秒钟的确认，能避免半小时的救火。

第三个：每完成一个能独立运行的单元就commit，不要攒一个月一次性提交。提交越频繁，将来用git bisect二分定位bug时越精准。每个commit就像面包切成片，别到放假前才开始切。

我常和新同事说的一句话是：Git是用来给自己兜底的，不是用来证明自己会多少花哨命令的。一个月后你再看仓库历史，如果每一段提交都能清楚说明当时为什么这么改，版本管理的价值才算真正兑现。