企业官网建设流程全解析

你多半见过这样的场景：新同学用Git，永远只会三连“add-commit-push”；老同学遇到线上分支出了岔子，第一反应是重新clone；更夸张的是有人把整个项目源码打成zip，文件名后缀加上“最终版”“终极版”“打死不改版”，然后发到群里。这种操作我看过太多次了。Git不只是一个“保存快照”的工具，它是一套完整的版本管理方法论。这篇系统性指南按照真实开发中的工作流来组织：怎么配置、怎么提交、怎么分支协作、怎么在翻车之后找回数据，最后附一张《核心Git命令速查表》，可以打印出来贴在工位上。无论你是刚入行的新人，还是用了两三年Git但从来没系统学过的人，这篇文章都能帮你补齐盲区。

1. 吃透Git的设计思路，比记一百条命令更管用

1.1 分布式根本：每个克隆都是完整仓库

先放下命令，说说底层。Git和SVN最大的区别不在于命令不同，在于哲学不同。SVN时代，你需要连上中央服务器才能查看历史、提交代码；Git把整个历史连同分支状态全部复制到本地。这意味着没有服务器也能提交，断网也能查看每一次改动。有一次我在高铁上写代码，网络时断时续，全靠着本地仓库写完了一个功能，到站之后再推送。那种“不依赖网络”的安全感，是集中式版本控制永远给不了的。

这种设计带来的另一个好处是备份。只要有人完整克隆过这个仓库，远端被清空也有一份救命的副本在别人电脑里。你可以把Git仓库理解成一块带时间机器的硬盘：每个克隆都不是子集，而是全集。这也是为什么很多团队从一开始就要求所有人都拥有完整仓库，而不是只拉某个分支的快照。

1.2 三区模型：一次提交背后发生了什么

Git的日常操作其实是在三个区域之间搬运内容：工作区、暂存区、提交区。

• 工作区是编辑器里正在改的文件，脏乱差，随便折腾。
• 暂存区像一个购物车，你只把想要打包的东西放进去。
• 提交区是历史仓库，每当git commit，Git就把购物车里的内容打成一个不可变快照。

理解这个模型非常关键。很多人的困惑都出在“我明明提交了为什么没有推送”“我改了文件为什么status显示有变化”。比如你改了文件之后又改了回来，Git会认为这个文件根本没变过，因为Git比较的是内容哈希，不是文件修改时间。这解释了为什么有些人在两个分支之间来回切换时，会看到自己未提交的改动“跟着跑”。说到底，工作区是物理存在的文件，分支的切换只是改变了当前工作目录里文件的“导出状态”。

1.3 分支是指针，不是文件夹

这是另一层认知刷新：Git里的分支不是目录里的多个备份，它只是一个指向某次提交的可移动指针。新建分支、切换分支、删除分支，代价都极低，因为根本没有复制文件。真正重要的是提交对象之间的有向图和它们构成的链。

理解“分支是指针”之后，很多命令就自然能推理出来了。比如git merge做的是“把两个分支的共同祖先和当前两条线做三方合并，生成一个新提交”，而git rebase做的是“把自己的提交摘下来，接到另一个基线上重放”。它们处理的对象不是文件副本，而是提交链。这一节不展开策略对比，后面会有专门小节。

2. 开始之前：把环境调成最顺手的状态

2.1 安装与第一眼体检

无论你用Windows、macOS还是Linux，第一步都是确认系统里有没有Git。打开终端执行：

git --version

如果没有，Windows推荐用官方安装包，安装时注意勾选“Git Bash Here”和“将Git加入PATH”。macOS上如果你装过Xcode Command Line Tools，通常会自带Git；没有的话通过命令行安装。Linux发行版基本都有包管理器，一条命令搞定。

装好之后，先别急着建仓库，跑一遍体检：

git config --list --show-origin

这个命令会列出所有生效的配置项以及它们来自哪个文件。我用它的频率非常高，因为很多诡异的“为什么这里提交人的名字是这个”问题，八成是某层配置覆盖了另一层配置。

2.2 全局配置三板斧

新机器第一步，永远先设置用户名和邮箱，不然提交会失败或者出现一串随机的系统名。

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

这里的邮箱不一定非要真实邮箱，但最好和你的远程代码托管平台账号邮箱保持一致，提交记录才能对应上个人头像。如果不同，平台会把同一个人的提交认成两个人，这对代码评审阶段特别尴尬。

除了身份，还有几个容易踩坑的全局项。第一，换行符转换。跨平台协作时，Windows下默认CRLF，Linux和macOS下是LF，Git默认会根据平台转换。如果你只想统一成LF，可以在系统层面配置：

git config --global core.autocrlf true # Windows 常用设置

或者在你的仓库里加一个.gitattributes文件，把具体文件类型都声明成LF，这是目前团队协作里比较稳妥的方案。第二，中文乱码问题。老版本Git在查看中文文件名时会显示成一串数字码，你可以在配置里设置：

git config --global core.quotepath false

这样git status和git log输出里的中文就能正常显示了。

2.3 配置的作用域与优先级

Git配置分三层：system、global、local。简单说，system影响整台机器所有用户，global影响你当前用户的所有仓库，local只影响当前仓库。优先级是local大于global大于system。这意味着你在某个项目里临时想换一个邮箱，直接在当前仓库执行：

git config user.name "临时马甲" git config user.email "temp@example.com"

这个仓库里的提交就会用它，不会影响你其他项目。搞懂这层之后，遇到“我在这个项目里明明设置了xx，为什么没生效”的问题，先检查是不是在错误的目录里，再看local配置是不是写值写错了。

3. 日常开发中离不开的核心操作

3.1 初始化、提交、查看历史的完整闭环

从一个空目录开始：

git init echo "# demo" > README.md git add README.md git commit -m "chore: init project"

git init会在当前目录生成一个.git文件夹，这是仓库本体。git add把文件放入暂存区，git commit把暂存区固化成一个提交。这里有一个新人最容易忽略的点：add和commit是两个动作，commit并不包含工作区里没有add过的改动。如果你只是改了一个文件然后想当然地commit，你会发现提交里根本没有这个改动。所以每次提交前，强烈建议先跑一遍：

git status

看看哪些文件还在暂存区外“漂流”。提交信息也有门道，我一般用约定式提交的格式：type(scope): description，比如feat(user): 增加登录弹窗。type可以是fix、docs、refactor、test等。短横线一行描述就够了，提交信息写得太长反而没人愿意细看。

3.2 查看历史：log的几种打开方式

刚学Git时，我只用git log，但看得一头雾水。后来找到几个舒服的姿势：

git log --oneline --graph --all

--oneline压缩成一行，--graph画出分叉图，--all包含所有分支。如果你只想看最近几条：

git log -5 --oneline

如果想精确到某个文件的演化历史：

git log --follow -- README.md

--follow能跟踪文件的重命名。日常排查bug时，我还会加：

git log -S"某个关键字"

这个-S参数会找出所有增加或删除过该字符串的提交，用来定位某些配置是什么时候被改的，极其好用。

3.3 进入暂存区之后的反悔操作

改了又不想提交，或者提交之后想回到过去，这是最高频的撤销场景。先区分清楚：你改的东西到底在哪个区？

如果工作区有改动且尚未add，想直接丢弃：

git restore README.md

如果你的修改已经add进了暂存区，想撤销暂存（保留工作区的改动）：

git restore --staged README.md

看，git restore靠参数区分操作区域，看起来像“把文件恢复原样”。更激进的情况是提交错了，想放弃最近一次提交并回到提交前状态：

git reset --hard HEAD~1

--hard会把工作区和暂存区一起重置，风险极大，它会直接丢弃提交里的内容和所有未提交改动。在没有备份的情况下使用，等于删库跑路。我一般会先：

git branch backup-before-reset

在reset之前创建分支指向当前HEAD，这样即使reset失误也能找回。这种习惯很廉价，但能挽回大量后悔的时间。

3.4 临时保存现场：git stash的正确用法

还在写一半的代码里插入新任务，是每个开发都逃不过的场景。这时候提交又不合适，直接切换分支又会把半成品带过去。我的答案是stash：

git stash push -m "half-done login page"

这条命令会把你当前工作区和暂存区的改动保存到一个栈式存储里，然后让工作区回到干净状态。之后可以安心切换分支。想恢复时：

git stash pop

如果多个stash并存，可以用：

git stash list git stash apply stash@{0}

stash pop会移除栈里的记录，apply则只应用不删除，两者的取舍取决于你接下来还要不要这份改动。还有一个实用参数：

git stash push --keep-index

它只保存未被暂存的改动，而先保留那些已经git add的内容。这个技巧在做“只提测已暂存内容”的拆分提交时很救命。

4. 分支与协作：一个人也要按团队流程来

4.1 分支的常见生命周期

在项目里我习惯这样管理分支：main永远是生产可用状态；develop是集成分支；功能分支从develop切出，命名用feature/xxx；修复用fix/xxx。创建和切换：

git switch -c feature/login

git switch -c等于过去的git checkout -b，语义更清晰。老版本的Git里没有switch命令，但你既然系统学，建议直接用新语义。切分支之前先看一眼工作区：

git status

如果工作区有未提交的改动，切换分支时这些改动会被带过去，一旦分支间文件差异较大，可能导致切换失败或文件被覆盖，所以尽量保持工作区干净，或者用stash临时保存起来。我会把“工作区干净”当成纪律，凡是准备换分支的先处理手头改动，不拖泥带水。

4.2 merge与rebase：两种合入风格

merge和rebase是协作中的分水岭。merge保留“我在哪分叉、我在哪合入”的真实路径；rebase把提交变成一条直线。

git merge feature/login

Git会自动创建一个合并提交，历史是一条会拐弯的铁路。如果两条分支在同一个地方都有修改，会报冲突，需要手动解决。

rebase就不一样：

git switch feature/login git rebase develop

这条命令把feature上从分叉点之后的提交逐个摘下来，再重新接到develop的最新提交上。结果是feature的提交变成一条干净的直线，看起来就像你是在最新develop的基础上开发的，代码评审时非常好追踪。但在共享分支上，rebase有个致命禁忌：永远不要对别人已经推送过的提交做rebase，因为提交哈希会变化，你会把别人的历史“篡改”掉。这一点我栽过跟头，后来在团队里直接约定，推送出去的分支原则上只用merge，本地未推送的提交可以随意rebase。

4.3 与远程仓库的日常同步

把本地仓库和远程关联起来：

git remote add origin https://代码托管平台/用户名/project.git git push -u origin main

git push -u的含义是把当前分支推到origin/main，并建立追踪关系，之后直接git push就能推送。这里会涉及身份认证，主流方案是SSH key或者HTTPS令牌。SSH方式需要先在本机生成密钥对，然后把公钥填写到托管平台的设置里：

ssh-keygen -t ed25519 -C "you@example.com" cat ~/.ssh/id_ed25519.pub

复制公钥到平台的SSH keys页面即可。这样做的好处是以后推送和拉取不需要每次输密码。HTTPS方式则需要申请一个访问令牌，令牌有有效期，过期后需要重新配置。

拉取代码默认用：

git pull

但pull其实等于fetch加merge。如果你不想自动合并，可以先：

git fetch git diff origin/main git merge origin/main

这样你能在合并之前看清楚远程有哪些变化。对于长期分支，我的做法是尽量按固定的工作节奏拉取，避免在已经落后的分支继续开发，减少后面的冲突面。

4.4 冲突解决：第一次撞上不慌

冲突是Git最容易劝退新人的点。实际发生冲突时，Git会在冲突文件里插入类似这样的标记：

<<<<<<< HEAD 你的改动 ======= 别人的改动 >>>>>>> feature/login

这里HEAD代表当前分支的内容，=======下面是另一条分支的内容。你需要手动决定保留什么，删除标记，然后再提交。新手常犯的错误是只删掉一边，把两边都删掉，或者不小心把整个冲突段删掉。我的建议是先把冲突的每一处都读一遍，确认哪边是对的，大概率结论是“两边都要”。大多数场景是双方修改了同一区域但语义不同，需要合并，这种情况下我会直接和写那部分代码的同事碰一下，而不是自己拍板。

解决完冲突之后，git add该文件，然后继续merge或rebase流程：

git add . git commit # 只有merge场景需要手动提交

如果是在rebase过程中冲突，则用：

git rebase --continue

如果确实解决不了，想退回之前的状态：

git rebase --abort

或者

git merge --abort

这两种abort都是为了保命存在的，不要不好意思用。

5. 翻车现场：惨痛经历的排查与修复

5.1 误删分支？reflog是最后的生命线

有一次我准备清理已合并的功能分支，手一快把还在开发的分支也给删了，当时还没推送到远程。我吓得不行，但马上冷静下来执行：

git reflog

reflog会记录你本机分支指针的每一次移动，包括删除分支前HEAD指向的位置。找到对应的提交哈希后：

git branch restored-branch <commit-hash>

分支就回来了。reflog默认保留30天左右的可回溯记录，这个时间窗口比很多人的备份频率都长。所以一旦发生类似事故，先别急着用网上的“数据恢复工具”，先查reflog。

5.2 提交错了或者想改历史

如果你刚才的提交信息写错了，或者忘记加文件：

git commit --amend

这个命令会把当前暂存区的改动合并进上一次提交，同时允许你重写提交信息。它非常方便，但同样只适用于本地未推送的提交，已经推送到远程就不要amended了，否则会让协作者的分支变得不可同步。

如果你只是想撤销某一次已提交的修改，而不是回退整个分支：

git revert <commit-hash>

revert会生成一个反向提交，它不会改写历史，所以可以在共享分支上安全使用。这和reset最大的区别就在这里：reset直接把分支指针拉到过去，等于“时间倒流”；revert则是“发射一枚反向的补丁”，保留历史轨迹，适合团队协作。

5.3 大小写误判、文件权限和行尾符

这类问题不显眼，但坑坏过很多人。第一个坑：Git对文件名大小写敏感，而Windows和macOS默认不敏感。你在本地把README.md重命名为readme.md，Git可能感知不到变化，需要：

git mv -f README.md readme.md

第二个坑：换行符。之前提过用.gitattributes统一。如果你把Git配置成不自动转换，所有跨平台拉下来的代码都可能显示成“整个文件都是修改”，实际上只是换行符不同。解决办法是在.gitattributes里声明文本文件的eol=lf，然后批量normalize重写。第三个坑：文件权限位。有时你只改了644变成755，Git会认为文件变了。这种情况要看是不是误加了执行权限，必要时修改回644并提交。

5.4 误执行了hard reset之后怎么办

前面说过reset --hard很危险。万一真执行了，还有机会。先别乱做操作，马上：

git reflog

找到reset之前的HEAD所指提交，然后：

git reset --hard <原来的提交hash>

整个过程我在一次协作事故中用到过：有人把develop硬回退了三天，整个团队都有点慌。我通过reflog定位到操作前的指针，先新建分支保护现场，再reset回去，十分钟解决了。所以每次你准备执行高风险命令，我都会额外提醒一句：先建一个分支或打一个tag，成本几乎为零，但数据可恢复。

5.5 误提交敏感信息后的补救

偶尔会把数据库密码、接口令牌之类的东西不小心提交上去了。先做三个动作：立刻撤出该文件、修改密钥本身、重写历史。第一步“撤出”指的是从仓库里删除该文件或把内容换成占位符，然后提交。第二步是去托管平台或服务端把旧令牌作废，生成新的。第三步比较麻烦，因为提交之后历史里仍然存在敏感信息，普通删除文件不影响旧提交。要重写历史，可以用专门的工具，比如git filter-repo，或者用一个稍笨但可靠的方式：rebase到更早的提交，把文件从历史里翻出来删除。无论哪种方式，核心判断是：只要信息真的发出去了，就不要只靠改历史来“销毁”，令牌失效应永远优先于历史清理。历史清理的意义更多在于防止它继续留在全网代码备份里，而不是补救泄露本身。

6. 《核心Git命令速查表》

6.1 配置与仓库状态

6.2 日常提交与历史

6.3 分支与合并

6.4 撤销与恢复

6.5 远程协作

速查表就是平时查用的，不用背。配合下面的实操习惯，你会慢慢形成肌肉记忆。

7. 我最想提的三个实操习惯

7.1 小步提交

在写这篇文章之前，我回想了一下这几年在Git上踩过和看别人踩过的坑，排在最前面的习惯是“小步提交”。一次提交尽量只做一个逻辑改动，不要把重构和加功能混在一起提交。小步提交的好处不只是历史干净，更重要的是revert和git bisect这类工具能精确地找到是哪一次改动引入了问题。我见过一个项目把一整周的新功能放一个提交里，出bug之后排查起来完全没有粒度，只能干瞪眼。

7.2 先拉后推

推送之前先git fetch看看远程，或者直接git pull，确保自己不是基于过时的本地分支在开发。远程分支一旦被别人更新，而你硬推，被拒绝是小事，更麻烦的是可能把别人的提交困在分叉里。养成先拉后推的习惯，很多冲突都能避免。

7.3 关键节点打tag

发布版本、里程碑节点、重要功能合入，都打一个tag：

git tag -a v1.0.0 -m "release 1.0.0" git push origin v1.0.0

tag是不可变的锚点，万一真出问题，可以随时从tag切出修复分支。这些习惯成本都很低，长时间坚持下来，你维护的项目会明显比同龄人的更“干净”。

我在实际使用中还有一个很个人的体会：Git的知识不是线性的，不要试图一口气吞下所有命令。先把add、commit、status、log、switch、merge、pull、push这八个操作练到肌肉记忆，再一点点扩展。当你意识到“Git不会轻易删掉我的代码”时，你对版本控制的信心才算真正建立起来。

最后再留一个建议：把这篇文章里的速查表复制到你自己的工作文档里，每次遇到不会的命令先查一遍再动手。我不会说“坚持就是胜利”这种话，我只知道，把Git用成坏习惯的人，终究会有一天在会议上看着自己丢失的代码愣住；而保持警惕、按工作流操作的人，永远有后悔药可吃。愿你用不到reflog，也愿你敢用reflog。