企业官网建设流程全解析

1. 先建立正确的认知：上传不是"传文件"，而是"同步提交记录"

1.1 GitHub 到底在帮你做什么

很多人第一次接触 GitHub 是从"上传代码"开始的。你用 GitHub 下载过别人项目的源码，觉得很简单，等到自己要传代码上去，却发现 git push 一执行就报错，上网一搜全是零散的答案，越看越乱。我在带新人时发现，问题几乎都出在一个点上：没有搞清楚 GitHub 的上传机制和"传文件"是两回事。

GitHub 的核心不是网盘，而是一个以 Git 为底层的代码托管平台。它管理的是"提交记录"而不是文件本身。也就是说，你本地每做一次 git commit，就是在项目历史里留下一个快照（包括当时改了什么、谁改的、为什么改）；而 git push 是把这一串快照推送到远端仓库，让 GitHub 上也拥有完整的历史。理解了这一点，你就能明白为什么不能像往网盘里拖文件一样把代码扔上去，也就能理解后面所有命令的顺序和意义。

1.2 什么人最需要把这套流程彻底跑通

这篇内容适合三类人：完全没接触过 Git 的零基础新手；已经会用 git clone 下载项目、但一上传就卡壳的人；以及工作中需要把代码交给团队或开源项目、却总在认证和报错上浪费时间的人。我会按真实操作的顺序，把从安装 Git 到日常更新代码的完整链路走一遍，并把我踩过的坑和带新人时常遇到的问题一并写出来。

上传代码这件事，说穿了就是三句话：在本地把项目初始化成一个 Git 仓库；在 GitHub 上建一个空仓库；把本地提交推上去。后面所有的报错、认证、分支问题，都是这三句话的延伸。下面我不讲虚的，直接按我自己的实操习惯来。

2. 环境准备：安装 Git 与全局配置的正确姿势

2.1 各平台安装 Git 的差异

在开始之前，先确认你电脑上有 Git。检查方式很简单，打开终端（Windows 是命令提示符或 PowerShell，macOS 是 Terminal），输入：

bash git --version

如果能显示类似 git version 2.39.2 这样的输出，说明已经装好了。如果提示找不到命令，分平台处理：

• Windows：从 Git 官网（git-scm.com）下载 Windows 版本，一路默认安装即可。装到"Adjusting your PATH environment"这一步时，保持默认选项，用"Git from the command line and also from 3rd-party software"。这个选项会直接把 Git 加入系统 PATH，之后在 PowerShell 和 cmd 里都能直接用 git 命令。如果你之前装过但命令提示符里还是找不到，关掉终端重新打开一次，因为 PATH 环境变量要重启终端才生效。
• macOS：最简单的是先试一下命令，新版 macOS 会在你第一次输入 git 时自动引导安装 Xcode Command Line Tools。也可以用 Homebrew 装：brew install git。装完同样用 git --version 验证。
• Linux（Debian/Ubuntu）：sudo apt update && sudo apt install git；CentOS/RHEL 系列用 sudo yum install git。

这里有个常见的坑：Windows 用户装完 Git 之后，习惯性地去双击打开"Git GUI"或者右键点"Git Bash Here"，这个操作没问题，但我建议新手统一用终端操作，因为网上所有教程的命令都是给你复制到终端运行的，你在图形界面里对不上号，反而更乱。老老实实用一个终端窗口，把命令敲熟，比什么都强。

2.2 配置 user.name 和 user.email：这一步影响你所有提交的署名

Git 安装完还不能直接用，它不知道自己是谁。每次提交代码时，Git 都要往提交记录里写入作者信息，所以要先把全局身份配置好：

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

配置里的 user.email 建议和你注册 GitHub 时用的邮箱保持一致。这不是形式主义——GitHub 会把提交记录里的邮箱和账号进行关联，邮箱不一致的话，你的提交虽然也显示在仓库里，但不会关联到你的 GitHub 头像和主页，看起来就像个陌生人的提交。想确认当前配置，用：

bash git config --list

看到 user.name 和 user.email 都正确，第一步就算完成了。

2.3 本地仓库的两种初始化方式

上传代码之前，本地必须有一个"仓库"。你可以简单理解为一个被 Git 管理的项目目录。初始化方式有两种，对应不同的场景：

• 全新项目：在一个空目录里执行 git init，目录里会出现一个隐藏的 .git 文件夹，这就是仓库的"大脑"，所有提交记录、版本信息都存这里。注意：把 .git 删掉，项目就失去了版本历史，变回普通文件夹。
• 已有项目：大多数人是先把代码写好了才想上传，这种情况不需要重新建目录，直接到项目根目录执行 git init 即可，效果一样。后面我会专门演示这种"已有代码目录"的上传流程，这也是最贴近实际需求的操作。

3. 在 GitHub 上创建远端仓库：那几个勾选项怎么选

3.1 仓库名、可见性、初始化文件怎么填

本地仓库准备好了，远端也得有个"接收方"。登录 GitHub 后，右上角点加号，选 New repository（新版界面里可能是 Create repository）。这一步有几个选项，新手经常纠结，我按我的习惯解释一下：

• Repository name：仓库名。建议用 kebab-case 风格，也就是全小写、单词之间用短横线连接，比如 my-first-project。不要用中文，也不要用空格，Git 命令行工具对中文路径和空格的兼容性虽然比早年好很多，但没必要给自己找麻烦。
• Description：仓库描述，可填可不填。填了会显示在仓库主页上，开源项目最好填，说明这个项目是干什么的。
• Public / Private：公开还是私有。传代码练习、开源项目选 Public；不想被外人看到或者公司项目选 Private。新手容易忽略的是：改成 Private 只是"别人搜不到、看不到"，你自己和被你授权的协作者还是能正常访问的。

先不要勾选 Add a README file、Add .gitignore、Choose a license：这三个是创建时自动生成的文件。如果你勾选了，GitHub 上的仓库就有了初始提交；而本地仓库还没有任何提交，两边的历史对不上，第一次 push 很容易触发冲突报错。最省心的做法是：三个全不勾，创建一个干净的空仓库。README 和 .gitignore 完全可以由自己在本地创建完再一起上传，后面我会讲具体写法。

3.2 绑定远端地址：origin 到底是什么

创建完成后，页面会显示一个仓库地址，通常有两种格式：

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

前者是 HTTPS 地址，后者是 SSH 地址。新手建议先复制 HTTPS 地址，等后面弄懂了认证机制再切换 SSH。

把远端地址和本地仓库绑定的命令是：

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

这里的 origin 是远端仓库的默认别名，"远端叫 origin"是这个领域的通用惯例。之后你写 git push origin main，意思是"推送到那个叫 origin 的远端仓库的 main 分支"。绑定完成后，用 git remote -v 查看，会列出当前仓库关联的所有远端地址，确认一下别绑错了。

我把绑错远端的坑多说一句：我见过有人复制了别人的仓库地址（比如刚从网上复制了一个开源项目的地址），一 push 就提示权限不足。排查方式就是先运行 git remote -v，如果显示的地址不是你自己的 GitHub 仓库，用下面命令改回来：

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

4. 首次上传的完整命令链路：add、commit、push 一个都不能乱

4.1 初始化与添加文件：git add 的粒度控制

现在本地仓库有了，远端仓库也有了，中间只差一条推送通道。我用一个"已写好的项目要上传"的场景来演示，你跟着敲一遍就能把整套流程跑通。

假设我在 D:\work\my-project 目录里已经写好了一个 HTML 页面。操作如下：

bash cd D:\work\my-project # 进入项目目录 git init # 初始化本地仓库 git remote add origin https://github.com/用户名/my-project.git # 绑定远端

然后把所有文件加入暂存区。Git 里有个概念叫"暂存区"，你可以把它想成"打包台"：git add 是把选中的文件放上打包台，git commit 是把打包台上的东西封装成一个有编号、有时间、有作者的包裹（提交）。这样设计的好处是，你可以灵活决定一次提交包含哪些文件，而不是把目录里所有变动一股脑打包。

bash git add . # 把当前目录下所有变动加入暂存区 git add index.html # 只暂存指定文件，需要精确控制时用这个 git add src/ # 只暂存 src 目录下的变动

git add . 是最常用的，但有个注意点：它会把你临时生成的、不该上传的文件也加进去，比如本地的 .env 配置文件、IDE 的 .idea 目录、node_modules 之类。正确做法是先创建好 .gitignore 文件，把不该上传的路径写进去，再用 git add .。一个基础的 .gitignore 长这样：

gitignore node_modules/ .env .idea/ .DS_Store /dist/

git add 之后，用 git status 检查一下当前状态，它会列出"已经暂存的改动"和"尚未暂存的改动"。养成 add 后必看 status 的习惯，能避免把不该传的东西推上去，这个习惯价值很大。

4.2 提交记录：commit message 怎么写才不被人骂

确认无误后提交：

bash git commit -m "初始化项目：添加首页"

-m 后面的内容是提交说明。不要随手写"update"或"111"这种没信息量的说明。规范的提交说明应该让三个月后的你自己（以及你的同事）一眼看懂这次改动做了什么。一般格式是：动词 + 对象 + 补充，比如"修复登录页在移动端的样式错乱"、"添加商品列表的接口封装"。如果提交说明写错了，可以用 git commit --amend -m "新的说明" 修正最近一次提交，但这条命令改的是提交历史，只在你还没 push 到远端时用比较安全。

4.3 推送远端：首次 push 的 -u 参数

提交完成，最后一步就是推送到远端：

bash git push -u origin main

如果你的本地默认分支还叫 master，先改成 main，和 GitHub 保持一致，省得以后在两个名字之间来回切换：

bash git branch -M main git push -u origin main

push 成功后会显示一串输出，大概长这样：

text Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (3/3), 271 bytes | 271.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/用户名/my-project.git

• [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.

看到 * [new branch] main -> main 这行，说明代码已经成功推到 GitHub。刷新仓库页面，文件就都在了。这里的 -u 参数意思是把本地 main 分支和远端 main 分支建立跟踪关系，以后只需要写 git push 或 git pull 就能自动对应到正确的远端分支，不用每次带全参数。首次 push 建议带上，后面日常更新就不用了。

5. 认证方式：为什么密码不行了，以及 PAT 和 SSH 怎么选

5.1 HTTPS + PAT：适合临时环境，配置最快

你可能会想：push 的时候怎么没让我输密码？这是因为不同环境行为不同——如果你用的是 HTTPS 地址，push 时通常会弹出输入账号密码的窗口；但你用 GitHub 账号的登录密码去填，会提示认证失败。原因很简单：GitHub 在 2021 年 8 月起就停止支持账号密码直接 push 了，安全策略上强制使用更可靠的认证方式。目前主流的两种方式是 Personal Access Token（个人访问令牌，简称 PAT）和 SSH Key。

生成 PAT 的路径是：GitHub 右上角头像 -> Settings -> 左侧最下面 Developer settings -> Personal access tokens -> Tokens (classic) -> Generate new token。生成时勾选 repo 相关的权限范围（如果只是上传代码，勾选 repo 这个大类即可），然后设置过期时间。GitHub 会给你一串以 ghp_ 开头的字符串，这个值只在当前页面完整显示一次，复制保存好，关闭后就看不到了，丢了只能重新生成。

push 时提示输密码，就输入这串 PAT，而不是你的登录密码。如果不想每次都输，可以配置 Git 的 credential helper，在 Windows 上一般会自动保存。另外要提醒一句：PAT 的权限就是一把钥匙，勾选范围时给最小够用的权限就够了；一旦代码传到公开仓库再发现令牌泄露，第一时间去 GitHub 撤销并重新生成。

5.2 SSH Key：配置一次长期免密，适合固定电脑

如果你用的是自己的电脑，我建议多用 SSH 的方式。先生成密钥对：

bash ssh-keygen -t ed25519 -C "你的邮箱@example.com"

一路回车即可，默认会在 ~/.ssh 目录下生成 id_ed25519（私钥）和 id_ed25519.pub（公钥）。私钥留在本地千万别外传，公钥则是要交给 GitHub 的。查看公钥内容：

bash cat ~/.ssh/id_ed25519.pub

把输出的整段内容复制，到 GitHub 的 Settings -> SSH and GPG keys -> New SSH key 里粘贴保存。然后测试连通性：

bash ssh -T git@github.com

第一次连接会提示确认主机指纹，输入 yes 回车即可。看到类似 Hi 用户名! You've successfully authenticated... 的输出，说明配置成功。之后只要使用 git@github.com 开头的 SSH 地址，push 和 pull 都不需要再输账号密码。

5.3 两种方式的取舍

我在实际带新人的过程中是这么建议的：第一次操作、或者在公用电脑上，用 HTTPS + PAT，省事；自己长期用的电脑，配好 SSH，后面顺畅很多。两种方式可以同时存在，不同仓库各自用不同地址就行。

6. 高频报错排查：从权限拒绝到推送失败

上传代码这关，报错是常态。我把自己被问得最多的几类错误整理出来，按"先定位问题类型，再对症处理"的思路写。遇到报错不要慌，先读最后一行的英文提示，很多时候答案就在里面。

6.1 首次 push 被拒绝：failed to push some refs

这是首次上传时最经典的报错之一，提示类似：

text ! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/用户名/仓库名.git'

原因就一句话：远端仓库有本地没有的提交记录。最常见的触发场景是你在 GitHub 创建仓库时勾选了 README 或 .gitignore，导致远端比本地多了一次提交。解决办法是先拉取合并再推送：

bash git pull --rebase origin main git push -u origin main

--rebase 参数的作用是把本地提交"接到"远端提交之后，让提交历史保持一条直线，相比默认的 merge 合并更干净，也不容易产生多余的"Merge branch"提交。新手只要记住：提示 fetch first 就打这一套组合拳。

6.2 权限与认证报错

如果提示 remote: Permission to 用户名/仓库名.git denied，或者是 fatal: Authentication failed，分两种原因排查：一是你 push 的仓库确实不属于你，检查 git remote -v 看是不是绑错地址；二是认证信息没配好，HTTPS 方式下检查 PAT 是否过期、权限是否勾选齐全，SSH 方式下检查公钥是否真的粘贴进了 GitHub。定位思路是：先跑 ssh -T git@github.com 验证 SSH 是否通，再跑 git remote -v 验证地址，基本就能锁定问题。

6.3 网络连接报错与大文件限制

提示 fatal: unable to access 'https://github.com/...' 或者 Failed to connect to github.com port 443，说明本地根本没能和 GitHub 建立网络连接。常见原因包括：公司网络策略限制、DNS 解析问题、系统代理设置残留。这类问题排查顺序是：先试试浏览器能不能正常打开 GitHub，如果浏览器都打不开，那就是网络环境层面的问题；如果能打开但命令行不通，检查是否有代理环境变量影响了 git。

GitHub 对单文件大小有限制，超过 100MB 的文件会直接拒绝推送，提示文件过大。而且 Git 的历史特性是"一次提交，永久存留"，哪怕你在下一个提交里删掉了大文件，仓库里依然留有它的历史对象，问题的清理会比较麻烦。所以上传前先检查项目里有没有超过几十 MB 的二进制文件（如模型文件、打包产物、视频素材），把它们排除在 Git 仓库之外。正经做法是用 Git LFS（Large File Storage）管理大文件，GitHub 对 LFS 也有免费额度；如果只是临时需要，也可以把大文件放到 Release 附件里，不进入代码仓库。

我在这里补一个排查时的通用习惯：遇到报错先复制末行提示去搜索，然后在本地按 git remote -v -> git status -> git log --oneline 的顺序检查三件套——远端地址对不对、工作区干不干净、本地提交有没有。80% 的上传问题在这三步里就能定位。

7. 日常更新与协作：不止上传一次就结束

7.1 更新代码的正确顺序

代码传上去只是开始。项目要持续迭代，你后面离不开三个操作：更新本地、推送改动、处理分支。我按日常节奏讲。

每次改动前和改动后，都建议先同步远端最新代码：

bash git pull origin main

等你改完代码、add、commit 之后，直接：

bash git push

因为首次 push 时带过 -u，本地和远端分支已经建立了跟踪关系，所以不需要再写 origin main。

这里有一个特别重要的习惯：每次 push 之前，先运行 git diff --stat 看一下本次改动了哪些文件、改动量大致多少，再看一下 git status 确认没有把不该传的文件混进去。我见过不少事故，都是 push 时才发现把数据库连接配置或者密钥文件传到了公开仓库。这个检查过程不到十秒钟，但能省掉后面删提交历史的很多麻烦。

7.2 分支操作：先会用三条命令

分支在 Git 里其实很轻量，就是几个指针。日常协作中你只需要先会用三条命令：

bash git branch # 查看当前所有分支，当前分支前面会有 * 号 git checkout -b dev # 新建并切换到 dev 分支 git push origin dev # 把本地 dev 分支推送到远端

在 dev 分支上改完并提交，再把 dev 推到远端，然后在 GitHub 网页上发起 Pull Request（简称 PR），请求把 dev 合并到 main。这是开源项目和大多数团队的协作方式：不直接在 main 上改，而是开分支、提交 PR、经人 review 后合并。新手不用急着把所有概念都学全，先把这三条命令用熟练，工程的协作流程基本就顺畅了。

7.3 冲突处理：别怕，看清三行标记就行

当你和同事同时改了同一个文件的同一段代码，后面 push 的人就会遇到冲突。Git 会把冲突标记写进文件，长这样：

text <<<<<<< HEAD 你这次改的内容

别人改的内容

分支名

处理方式很直接：打开文件，把 <<<<<<< 、=======、>>>>>>> 这三行标记连同不要的内容一起删掉，保留你想要的最终结果，然后重新 git add 和 git commit。注意在推送之前养成先 pull 的习惯，可以显著减少冲突发生的次数。

8. 网络连不上 GitHub 时的现实方案：换一个仓库平台，而不是硬扛

这个问题比较现实，也确实有不少人遇到：代码写好了，但 push 一直失败，或者 GitHub 页面打不开。这里先把话说清楚：如果你的网络环境访问 GitHub 长期不稳定，我的态度很明确——不要在一个不通畅的平台上消耗大量精力，换一个通路顺畅的代码托管平台才是性价比最高的选择。

在国内最常见的替代平台是码云（Gitee），服务器在国内，网络连接通常很稳定，功能上覆盖了仓库管理、分支、PR、Issue 这些核心场景。迁移成本其实很低，因为 Git 的机制是跨平台的：同一个本地仓库可以同时拥有多个"远端"。我给个具体操作流程：

1. 在 Gitee 上创建仓库，获得一个地址，比如 https://gitee.com/用户名/项目名.git。
2. 在本地仓库里把 Gitee 加为另一个远端，命名随意但要能区分，我习惯用 gitee：

bash git remote add gitee https://gitee.com/用户名/项目名.git

3. 推送时指定 gitee 这个远端：

bash git push -u gitee main

4. 之后日常更新只需把 origin 换成 gitee 即可，add 和 commit 那些步骤完全不用改。

如果你的公司或团队用的是 GitLab，思路一样：git remote add gitlab <你的GitLab仓库地址>，再 git push -u gitlab main。掌握了"一个本地仓库可以绑定多个远端"这个概念，你就能在任何 Git 平台上自如切换，不被单一平台绑架。

另外想提醒一句：不要为了访问 GitHub 去使用来源不明的第三方工具或脚本，这类工具往往需要读取你的 GitHub 账号数据，存在账号被盗和代码泄露的风险。如果确实需要继续使用 GitHub，更稳妥的办法是检查并修正本地的网络配置，再从官方渠道获取帮助；如果问题依旧，就按上面的方案走 Gitee 或 GitLab，同样能把项目完整跑起来。

就我个人经验而言，上传代码这件事，80% 的精力其实花在前面 20% 的原理理解上。第一次把 add、commit、push 这套链路跑通之后，后面每一天的"推送代码"就是三个命令的事。最后再把一个我一直强调的小习惯送给你：每次 push 前看一眼 git status 和 git diff --stat，确认自己在传什么，这个习惯比任何命令都重要。