企业官网建设流程全解析

先讲个最常见的场景：你写了几天代码，突然把之前能用的功能改坏了，想回到昨天那个还不错的版本，结果手头只有一个被覆盖过的文件，崩溃不崩溃。还有，你和别人一起做一个项目，你改了头部，他改了底部，互相把文件传来传去，覆盖来覆盖去，最后连谁改了什么、为什么要这么改都说不清楚。如果你经历过这些，那么 Git 就是你的解药，它不是为了装酷才存在的命令行工具，而是让文件版本管理这件事变得有迹可循的底层基础设施。

这篇内容不假设你有任何命令行基础，只要求你认识几个常见英文单词。我会从安装开始，一步步把本地仓库、提交、分支、连接 GitHub 这些关键环节都过一遍。你可能已经听过很多关于 Git 的碎片知识，但这里会把它们串成一条完整主线。学完之后，你可以把本地代码推到 GitHub，也能拉取别人的仓库，日常开发完全够用。如果你之前总觉得 Git 命令很唬人，我尽量用人话解释清楚背后逻辑，并且附上可以直接照着敲的操作步骤。

1. 先彻底理解 Git：它不是网盘，是一个时间机器

1.1 用游戏存档理解 Git 的版本机制

很多人第一次接触 Git 时，最容易产生的误解是：Git 是不是类似网盘，把我的文件同步到云端保存一份。如果只是这样，那普通网盘就够了，没必要专门学一套命令。真正让 Git 强大的，是它对“版本”的管理方式。

你可以把 Git 理解成游戏里的存档系统。玩单机游戏时，你会在关键时刻存档，之后不管走了多远、把角色玩成什么样，只要读档就能回到那个时间点。Git 的 commit（提交）就是存档。每次提交时，Git 会把当前所有被跟踪文件的状态拍成一张快照，保存在本地仓库里，并记下这次提交的作者、时间、备注信息。以后你可以随时跳到任意一次提交上，查看当时的代码长什么样，甚至可以回退到那个状态继续开发。

这和网盘有本质区别。网盘同步的是“最新版文件”，你永远只有一个当前状态，过去的版本要么靠文件备份，要么就没了。Git 管理的是“版本演变史”，每一次改动都被记录在案，形成一条清楚的时间线。项目出问题时，你不光能回退，还能通过提交历史定位是哪一次改动引入了问题。

1.2 没有网络也能用的分布式版本控制

更妙的是，Git 是分布式的。传统版本管理工具往往有一个中央服务器，所有人提交都要连上服务器才能操作，一旦断网或者服务器挂了，工作就没法继续。Git 把逻辑反过来了：每一位使用者的电脑里都有一份完整的仓库，包含全部历史记录，而不是只有中央服务器有权威副本。

这意味着，你在飞机上、地铁里、没网的咖啡馆里，都可以正常提交代码、查看历史、创建分支。所有操作都在本地瞬间完成，只有当你需要和别人交换代码时，才依赖网络。这种设计带来的安全感很强。我见过一些团队，所有代码都托管在远程平台上，但开发主力几乎每天只在最后同步时才联网，平时全部在本地仓库里操作，完全没有阻塞感。

1.3 Git 与 GitHub：工具和托管平台的差别

Git 是本地运行的版本管理工具，GitHub 则是帮你托管远程仓库的平台。你本地提交后的历史记录，可以通过 git push 推送到 GitHub；别人也可以通过 git clone 从 GitHub 拉取仓库。简单说，Git 是本地引擎，GitHub 是云端停车场。

需要特别注意的是，Git 不需要 GitHub 也能用，你完全可以只在自己电脑上用 Git 管理各种文件，不连接任何远程平台。GitHub 的价值在于协作和备份：代码放到云端后，团队可以共享，多台设备可以同步，公开项目也能让更多人看到和参与。类似的代码托管平台还有不少，但 GitHub 对初学者最友好，资料多、界面直观，所以大多数人的第一课都从连接 GitHub 开始。

2. 环境准备：从下载安装到第一行配置

2.1 Windows 系统安装 Git

Windows 下安装 Git 其实没有任何技术含量。去 Git 官网下载对应系统的 64 位安装包，双击运行，一路点击 Next 使用默认选项就行。有一个安装提示会让你选择 PATH 环境变量配置，默认选项是 “Git from the command line and also from 3rd-party software”，这个建议保留，否则以后在其他终端里可能调不到 git 命令。

安装完成后，在开始菜单里你应该能找到 Git Bash。Git Bash 是一个更接近 Linux 风格的终端，里面能使用大部分常用命令，对新手比较友好。打开之后，先验证安装是否成功：

git --version

如果能看到类似git version 2.xx.x.windows.x的输出，就是装好了。如果提示找不到命令，多半是安装时 PATH 选项没选对，重新安装一次即可。

2.2 macOS 和 Linux 下怎么装

macOS 用户想省事的话，可以下载官方安装包，双击后按向导安装。不过更常见的做法是通过系统自带的包管理工具安装，比如在终端里执行对应的包管理器命令，Mac 上常见的是：

brew install git

没有装包管理器也可以用 pkg 安装包。安装完成后同样执行git --version确认。

Linux 环境比较多样，但原理都一样，用系统包管理器装起来最快。比如使用 apt 的发行版：

sudo apt update sudo apt install git

使用 dnf 的发行版：

sudo dnf install git

安装完成后键入git --version验证。如果你在 Linux 服务器上工作，还得注意系统时间要准确，否则后面连接远程仓库时可能出现证书校验失败之类的问题，这一点比 Windows 更容易被忽略。

2.3 安装后第一件事：配置用户名和邮箱

安装完 Git 后，第一件事不是急着建仓库，而是告诉 Git “你是谁”。Git 每一次提交都会记录作者信息，如果没有配置，提交时会直接报错，或者替你在每台机器上猜测一个奇怪的默认身份。

打开终端，执行下面两条命令：

git config --global user.name "Your Name" git config --global user.email "you@example.com"

用户名建议用你习惯的英文昵称，邮箱建议填你注册 GitHub 时用的邮箱，这样提交记录能和 GitHub 账号关联起来。--global的意思是全局生效，之后这台电脑上所有仓库都会使用这个身份信息。

你可以随时用下面的命令查看当前配置：

git config --global --list

如果哪天想改，直接重新执行上面两条命令即可。这个配置只影响提交记录里的署名，不会影响下载别人的代码。

2.4 提前避开换行符和中文乱码

不少新手在 Windows 上提交代码时，会看到一条提示：LF will be replaced by CRLF。这不是错误，只是 Git 在提醒你换行符差异。Linux 和 macOS 默认用 LF，Windows 默认用 CRLF，如果团队跨平台协作，很容易导致整个文件被误判为修改。最省心的做法是安装时保持默认的 autocrlf 设置，提交时 Git 会自动把 CRLF 转换成 LF，检出时再转回 CRLF。

另一个常见坑是中文乱码。如果你的代码或提交信息包含中文，文件请尽量统一使用 UTF-8 编码保存。在 Windows 自带的记事本里编辑文件时，用户容易习惯用 GBK 或其他编码，提交后别人打开就乱码。命令行里也建议用支持 UTF-8 的终端，不然看到的中文提交信息可能全是句号或问号。

3. 本地仓库零基础实操：提交第一个版本

3.1 git init：创建仓库

现在可以开始第一个真正意义上的 Git 项目了。新建一个测试目录，比如叫 demo-project，然后进入这个目录，执行：

git init

执行后，目录下会多出一个隐藏的.git文件夹，这就是 Git 存放所有版本元数据和历史记录的地方。从此这个目录就是 Git 仓库了，之后你在里面做的提交，都会记录在这个.git文件夹里。

很多初学者不理解为什么突然出现一个隐藏目录，甚至担心是不是中毒了。其实正是这个.git目录让一切版本管理成为可能。它包含了整个仓库的完整历史，把这个目录删掉，就等于删掉了 Git 记录，但不会删除当前文件。不要轻易删除它，否则历史全没了。

3.2 git status：紧盯文件当前状态

初始化仓库后，先创建一个普通文件，比如README.md，写上一句话，比如 “hello git”。然后执行：

git status

你会看到类似这样的输出：当前在哪个分支，目前还没有任何提交，README.md处于untracked状态。untracked 的中文意思就是“未被跟踪”，表示 Git 还没有登记这个文件，后续的版本记录里不会包含它。

这一步看起来很基础，但我建议你养成随手git status的习惯。它不会改任何东西，只是把当前仓库状态原原本本告诉你，什么文件是新加的，哪些文件被修改过，哪些已经进入暂存区。熟练后你会发现，大部分时候，看看git status就知道自己接下来该执行什么命令了。

3.3 git add 与 git commit：把快照真正记录下来

要把文件纳入 Git 管理，必须先在 GUI 工具或命令行里告诉 Git：把这些文件的当前状态加入下次提交。命令是：

git add README.md

如果你想把当前目录下所有新增和修改都加进去，可以用：

git add .

执行完git add后，再执行git status，你会发现README.md变成了绿色，状态变为Changes to be committed。这说明文件已经被放进了暂存区，也就是一个“待提交清单”。

然后，把暂存区内容固化成一次提交：

git commit -m "first commit"

-m后面的是提交信息，建议写得如同一句简短说明，告诉别人这次改动做了什么。执行成功后，Git 会输出这次提交的简要信息，例如一个文件改变，以及一个长长的提交编号。

这里可以用一个生活类比：git add是把商品放进购物车，git commit才是去收银台结账。结账后，这一组改动变成一个不可变的存档点，永远记录在时间线里。你可以多次 add 后再 commit，也可以分多次 add 和 commit，完全取决于你希望每一次提交保存什么逻辑单元。

3.4 git log：回看你走过的每一步

提交完成后，执行：

git log --oneline

你会看到一列提交历史，每条包括一个短的提交编号和提交信息。第一次提交的编号是随机生成的十六进制字符串，它其实就是这次仓库状态的唯一指纹。以后不管过了多久，只要这个编号还在，你就能通过它找到对应版本。

我在实际使用中非常依赖git log。写代码时总觉得自己的记忆可靠，但项目一多、改动一多，记忆很快就会模糊。提交信息就像给未来的自己留的便条，因此我强烈建议提交时不要用 “update”、“fix” 这种含糊话，尽量写明白，比如 “修复登录页面手机端样式错位”。好的提交历史会让排查问题轻松很多。

4. 连接 GitHub：把代码推到远程仓库

4.1 在 GitHub 上创建一个远程仓库

本地仓库已经能记录版本了，但代码只在你自己的电脑上，一旦硬盘坏了，一切可能化为乌有。把代码同步到 GitHub，相当于多了一层备份，也是协作的前提。

登录 GitHub 后，点击页面右上角的加号，选择新建仓库。给仓库起个名字，不用纠结大小写，建议简短、能反映项目功能。公开或私有按需选择，初学者可以先选私有，之后想展示再调整为公开。

这里有一个很重要的坑：如果你的本地已经有了一个 Git 仓库，创建 GitHub 仓库时，不要勾选 “Add a README file”“Add .gitignore” 或者 “Choose a license” 这些初始化选项。否则 GitHub 会帮你生成一次独立的初始提交，而你的本地仓库也有自己的提交历史，两边没有共同的起点，第一次 push 时会因为“两个不相关的历史”被拒绝。很多人第一次连接失败都栽在这个细节上。

4.2 HTTPS 还是 SSH：两种连接方式怎么选

连接 GitHub 远程仓库有两种主流方式：HTTPS 和 SSH。它们都能实现同样的目标，但工作方式不同。

对零基础来说，HTTPS 更容易理解：远程地址就是一个普通网址，配上访问令牌就能推送。SSH 则需要在本地生成一对密钥，把公钥放到 GitHub 账号里，之后连接时不需要反复输入密码。我个人的建议是，第一节课先用 HTTPS 把整个流程跑通，理解 push 和 pull 是怎么回事，之后再去配置 SSH 体验免密推送。

无论选哪种，远程地址里的用户名和仓库名都要替换成你自己的，否则你推送到的是别人的仓库，GitHub 会拒绝你的连接。

4.3 HTTPS + Token 实操：别再输密码了

在本地仓库里，把远程地址添加进去：

git remote add origin https://github.com/你的用户名/你的仓库名.git

这里的origin是一个习惯默认名，代表远程仓库。添加后可以执行：

git remote -v

看到输出了远程地址，说明绑定成功。

然后执行推送命令：

git push -u origin main

注意，如果你的 Git 默认分支叫 master，就把 main 换成 master。-u参数的意思是第一次推送时建立本地分支与远程分支的关联，以后直接输入git push就能推送。

执行后，弹出窗口或命令行提示让你输入用户名和密码。用户名填你的 GitHub 用户名，密码一栏绝对不能填 GitHub 账号密码，而要填 Personal Access Token，也就是个人访问令牌。GitHub 出于安全原因，早已不支持直接用账号密码操作仓库，必须使用令牌。

生成令牌的方法是：GitHub 页面右上角头像进入 Settings，然后找到 Developer settings，选择 Personal access tokens，点击 Generate new token。生成时建议勾选 repo 相关的权限范围。令牌只会完整显示一次，之后不会再看得到，所以生成后立刻复制保存。把令牌当成密码，任何人都不能给。如果你不小心泄露了，立刻到 GitHub 里把它删掉并重新生成。

为了避免每次 push 都输入一堆信息，你可以让 Git 记住凭据：

git config --global credential.helper cache

这会在一段时间内缓存凭据，不同系统下的缓存时长和方式略有差异，但至少不用每次敲令牌。

4.4 SSH 密钥配置：一劳永逸的免密方案

如果你觉得每次输入令牌还是太烦，可以配置 SSH。先在本地生成一份密钥对：

ssh-keygen -t ed25519 -C "you@example.com"

执行后，它会问保存位置，直接按回车使用默认路径即可。还会问你是否设置 passphrase，这相当于密钥的额外口令，建议设置，虽然每次第一次使用可能要点一遍，但安全性更好。如果你只在自己的电脑上用，也可以直接回车跳过。

生成完成后，找到公钥文件，通常是在~/.ssh/id_ed25519.pub，用任意文本编辑器打开，把里面的内容完整复制。然后在 GitHub 的 Settings 里找到 SSH and GPG keys，点击 New SSH key，粘贴进去，保存。

之后需要把远程地址改成 SSH 格式。可以执行：

git remote set-url origin git@github.com:你的用户名/你的仓库名.git

验证连接是否成功：

ssh -T git@github.com

第一次连接时终端会问你是否信任这台主机，输入 yes 回车即可。如果配置正常，你会看到一段成功认证的提示。之后git push就不需要再输入密码了。

4.5 push 之后怎么日常更新

推送成功后，你的代码已经在 GitHub 上出现了。以后每次工作流的节奏就变成：

1. 先git status看看当前状态。
2. 改完文件后git add，再git commit -m "这次改了什么"。
3. 推送前先git pull，把远程新提交拉下来，减少冲突。
4. 执行git push，把本地新提交推上去。

如果你是单独开发，远程没有别人动过，第三步几乎不会出问题。但只要和他人协作，务必养成“先 pull 再 push”的习惯。我见过太多人写完代码直接 push，结果被拒绝，然后才慌慌张张去处理冲突，反而浪费更多时间。

还有一个小建议：本地工作区有未提交修改时，git pull可能报错，提示会覆盖本地修改。这时候要么先把修改提交了，要么用git stash暂时存起来，拉完再取回。新手阶段不用太深入git stash，但至少要知道这个报错不是 Git 故障，而是保护机制。

5. 这些高频操作，让你的 Git 水平从“会用”到“熟练”

5.1 分支：并行开发不打架的秘诀

分支是 Git 里最值得认真理解的概念。简单说，分支就是一个可移动的指针，指向某次提交。主分支通常叫 main 或 master，当我们新建分支时，其实就是从当前提交点分出一条新的时间线，在这个分支上的提交不会影响主分支。

创建一个新分支并切换过去：

git switch -c feature/login

这条命令同时完成新建和切换，比较方便。查看当前分支：

git branch

切换到已有分支：

git switch main

合并分支：

git merge feature/login

为什么要用分支？想象你在维护一个已上线项目，临时需要加一个新功能，同时又不想影响正在运行的稳定版本。你可以在 main 分支上保持稳定代码，在 feature 分支上大胆尝试，等测试没问题再合并回去。如果尝试失败，直接删除分支就行，主分支毫发无损。

我在实际开发中见过许多新手从一开始就不建分支，所有改动都直接提交到 main。一个人开发时问题不大，两个人以上就会开始互相干扰。哪怕只是学习阶段，我也建议养成“每次新功能新开分支”的习惯，这会让你的提交历史干净很多。

5.2 撤销与回滚：找到最适合的后悔药

新手最怕改错东西，但 Git 最让人安心的一点就是：大部分错误都能挽回。关键是搞清楚自己处于哪个阶段，再选择对应的命令。

如果修改了文件但还没 add，后悔了，想让文件回到上一次提交的状态：

git restore 文件名

如果已经把文件 add 到暂存区，想撤出来但保留修改：

git restore --staged 文件名

如果已经提交了，但只是想撤销这次提交并保留改动内容：

git reset --soft HEAD~1

如果想彻底回到上一个提交状态，连改动一起放弃：

git reset --hard HEAD~1

这个命令非常危险，它会直接丢弃暂存区和工作区的变化。如果你已经把这些改动推送到远程，情况会更复杂，因为重置会导致本地和远程历史不一致，通常不建议对已推送的提交使用reset --hard。

对于已经推送到 GitHub 的提交，推荐使用git revert生成一次“反向提交”，这是一种安全的撤销方式，因为它不改变已有历史，只是新建一个提交把之前的内容回退。团队协作时，尽量使用 revert 而不是 reset，避免把其他人拉取到的历史弄乱。

5.3 克隆仓库：拿到别人代码的正确姿势

GitHub 上最吸引人的功能之一是你可以把别人的开源项目复制到本地查看、修改甚至贡献代码。这个操作叫 clone，也就是克隆。

在项目主页找到 Code 按钮，复制 HTTPS 或 SSH 地址，然后执行：

git clone https://github.com/用户名/仓库名.git

Git 会自动创建一个以仓库名命名的文件夹，把远程完整历史都拉下来，同时自动配置好远程地址。克隆完成后，你不需要执行git init，因为整个仓库已经在本地了。

要注意 clone 和 fork 的区别。clone 是把远程仓库复制到你自己电脑上，和 GitHub 上的原仓库没有直接关联关系；fork 是在 GitHub 上把别人的仓库复制一份到你的账号下。通常流程是：先 fork 到自己账号，再 clone 到本地，修改后 push 到自己的 fork，最后通过 Pull Request 向原仓库提交贡献。新手不用急着理解整套流程，先会用 clone 拉取代码，后面自然就懂了。

6. 新手踩坑实录：常见报错与解决思路

6.1 fatal: Please tell me who you are

第一次提交时最容易遇到这个报错。它本身不是故障，而是 Git 在提醒你，提交需要作者信息但你还没有配置用户名和邮箱。解决方法是回到环境准备部分，执行那两条git config --global命令。

如果你是在某个仓库里单独配置身份，也可以不加--global：

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

这个配置只对当前仓库生效。很多团队项目要求成员用公司邮箱提交，这时就可以在仓库内覆盖全局配置。

6.2 远程连接超时或失败

推送时偶尔会遇到超时、连接失败或 SSL 相关的问题。这种报错很泛，排查时先按顺序检查：

• 检查网络连接是否正常，最简单的方法是在浏览器里打开 GitHub 页面。
• 检查远程地址有没有拼错，执行git remote -v查看。
• 尝试换一种连接方式，HTTPS 连不上就换 SSH，SSH 连不上就换 HTTPS。
• 如果是在公司或学校内网，可能存在网络限制，先咨询网络管理员有没有白名单或专用通道。

不要盲目照搬网上各种修改系统配置的偏方，尤其不要随便关闭 SSL 校验，这会让你的连接变得不安全。很多时候问题只是临时网络波动，换个时间再试就通了。

6.3 push 被拒绝：non-fast-forward

执行git push时如果看到类似non-fast-forward或fetch first的提示，意思是远程仓库有一些你本地没有的提交，你的推送会覆盖掉远程其他人的更新。Git 出于保护机制拒绝了这个操作。

解决方案是先拉取远程提交，再尝试推送：

git pull --rebase origin main

--rebase会把你的本地提交放到远程最新提交之后，比直接 pull 多出的一次合并提交更清爽。如果拉取过程中提示冲突，处理方式和下面的冲突解决一致。解决完冲突后继续完成 rebase，然后推送。

6.4 合并冲突：出现 conflict 不用慌

多人修改同一个文件的同一段内容时，Git 不知道应该保留谁的版本，就会标记为冲突。打开冲突文件，你会看到类似的内容：

<<<<<<< HEAD 你当前分支的代码 ======= 别人分支的代码 >>>>>>> feature/login

尖括号、等号这些标记不是代码，是 Git 提示冲突位置的辅助信息。你需要手动决定保留哪部分，或者把两边内容都整合起来。编辑完之后删除标记行，保存文件，然后执行：

git add 文件名 git commit -m "resolve merge conflict"

日常协作中，冲突是正常现象，不要一看到冲突就觉得天塌了。最好的减少冲突习惯是：频繁 pull、频繁 push、每次改动范围尽量小、避免长时间在同一个分支上各自改动。

6.5 误删文件如何恢复

如果你只是删除了工作区文件但还没提交，想恢复：

git restore 文件名

如果删除已经提交过，但仍想让文件回到最近一次提交里的样子，同样可以用git restore。只要这个文件在最近一次提交里存在，Git 就能把它找回来。

如果误删的是一个还没有 commit 过的新文件，Git 爱莫能助，因为它在任何历史中都不存在。这也是为什么我建议新文件创建后尽早提交，提交本身就是备份。很多新手因为觉得“还没写完不用提交”，结果电脑出问题或误操作后追悔莫及。小步提交不会干扰开发，反而给你提供无数个可以回去的安全点。

最后分享一个我自己在实际操作里的体会：学 Git 最忌讳的是死背命令。真正管用的方法是先建立“版本时间线”这个模型，想清楚当前文件在哪个状态，下一步应该往哪里放。每次开始工作前先看一眼git status，每次提交都用一句话讲清楚这次做了什么，坚持几周后，这些命令会变成肌肉记忆。到那时候，Git 就不再是拦路虎，而是你项目开发里最让人安心的那层保障。