企业官网建设流程全解析

很多刚开始接触 GitHub 的朋友，第一个真实需求往往不是搞懂什么分布式版本控制理论，而是朴素得像大白话一样的一句话：我本地写好的项目，怎么传上去？传上去之后改了代码，又怎么把改动同步回去？别看这个问题简单，我在技术社群里见过太多求助帖，十有七八都卡在这一步。原因不是手生，而是对 Git 和 GitHub 之间的关系缺少一个直观框架，每一步都像在背命令，一旦报错就完全懵掉，连问题描述都说不清楚。

这篇文章就围绕这个最基础、但也最重要的场景展开：从零准备环境，把本地项目文件上传到 GitHub，再到日常修改代码后的同步更新流程。适合刚注册 GitHub 不知道第一步干嘛的纯新手，也适合那些已经传过一两次项目、但每次修改文件时总是被各种状态提示绕晕的朋友。我会尽量把每一步背后的原因讲明白，不是只丢给你一串命令让你照抄。

1. 先搞懂 Git 和 GitHub 的关系，后面所有操作才有方向

很多新手最大的障碍，不是记不住命令，而是不知道自己在做什么。Git 和 GitHub 这两名字听起来像同一个东西，实际上分工完全不一样。

Git 是本地跑着的版本管理工具。它在你电脑上操作，记录你对文件做的每一次改动，能回到任意历史版本，能开分支做实验而不影响主代码。它不需要联网，不需要注册账号，装好了就能用。

GitHub 则是远程的代码托管平台。它把 Git 仓库放在云端服务器上，让你的代码有一个网上副本。这样做的好处有三层：第一是备份，电脑坏了、硬盘清了，代码还在；第二是协作，别人可以克隆你的仓库、提修改建议，你也能参与别人的项目；第三是公开记录，你的每一次提交都带着时间戳和作者信息，形成一份完整的技术履历。

很多新手第一次接触会下意识问：那我能不能像操作网盘一样，直接把文件夹拖到 GitHub 网页上？答案是不行。网页版确实提供了 Upload files 按钮，可以少量上传单个文件，但这不是常规工作方式，也不符合 Git 的协作模型。你真正要做的是让本地 Git 和远程 GitHub 建立关联，然后在本地完成提交，再推送到远程。

这里我习惯用一个快递的类比帮助理解：

• 工作区：你电脑上的实际文件，相当于你递出去之前的物品。
• 暂存区（Index）：你选中了一部分物品放进篮子，还没有打包寄出。
• 本地仓库（.git）：你的个人仓库，打包好但还没交给快递员。
• 远程仓库（GitHub）：快递发出到达的驿站，别人能从驿站看到你的包裹。

这个类比里埋了一个很重要的认知：Git 的每一次操作都有明确的 "阶段划分"。你修改文件只是改了工作区；必须用git add把改动放进篮子，用git commit打包成快照，再通过git push送到远程。很多新手出错，就是跳过了中间环节，或者不知道改完文件后还要经历这些步骤。

一句话总结：Git 管本地历史，GitHub 管远程托管；你需要做的，是在本地提交历史，再把历史推到远程。

2. 环境准备里最容易忽略的两个细节：Git 安装和 SSH 配置

上传项目之前，得先让自己的电脑具备操作 Git 的能力。这部分本身不复杂，但我发现新手经常在两个细节点上出问题，这里单独强调。

2.1 安装 Git：不同系统的不同路径

先确认电脑里有没有 Git。打开终端工具（Windows 可以用 PowerShell 或 CMD，macOS 用 Terminal），输入：

git --version

如果能看到一串版本号，说明已经装好了。如果提示找不到命令，就需要安装：

• Windows：去 Git 官网下载安装包，一路默认选项即可。有一点要注意，安装过程中会让你选择默认编辑器，新手建议直接用默认的 Vim 或者改成你熟悉的编辑器，避免之后提交时误入 Vim 界面退不出来。
• macOS：一般运行git命令时系统会提示安装 Command Line Tools，按提示点安装即可；如果你装了 Homebrew，也可以直接brew install git。
• Linux（Debian/Ubuntu）：sudo apt install git，Fedora 系是sudo dnf install git。

装完之后再跑一次git --version，确认能正常输出。

这块真正的坑不在安装本身，而在 Windows 用户双击桌面图标打不开 Git Bash、或者需要在 IDE 里调用 Git 时路径不对。保险做法是安装完重开一次终端，再测试一遍。

2.2 配置身份信息：提交记录里你是谁

Git 每次提交都会记录作者信息，要提前告诉它你的署名和邮箱，否则 commit 会报错。

git config --global user.name "你的名字或GitHub用户名" git config --global user.email "你注册GitHub用的邮箱"

这个配置是全局的，电脑上所有项目的提交都会默认使用。想针对某个项目单独设置时，去掉--global参数就行。

2.3 SSH Key：为什么我强烈建议你配置它

上传项目到 GitHub 有两种常见连接方式：HTTPS 和 SSH。用 HTTPS 也能推代码，但每次 push 都要输入用户名和密码（现在 GitHub 要求用个人访问令牌而非密码，更麻烦）。SSH 则只要配置一次密钥，以后推送拉取都不需要再输账号信息。所以我给新手的建议永远是一步到位，直接配 SSH。

生成密钥的命令：

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

一路回车到底，会在用户主目录的.ssh文件夹里生成两个文件：私钥id_ed25519和公钥id_ed25519.pub。私钥留在电脑上，公钥贴到 GitHub。

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

然后打开 GitHub 网页，点击右上角头像 -> Settings -> SSH and GPG keys -> New SSH key，把公钥整段粘贴进去，标题随意写（比如 "my laptop"）。

注意一点：私钥文件绝不能泄露，谁拿到它谁就能以你的身份操作你的仓库。如果怀疑私钥泄露，及时在 GitHub 上删除对应公钥并重新生成。

配置完成后测试连通性：

ssh -T git@github.com

成功会看到类似 "Hi 你的用户名! You've successfully authenticated" 的提示。这一步通过，后面的上传流程就会非常顺畅。

3. 第一次上传：从本地项目文件夹到 GitHub 空仓库的完整流程

环境准备好之后，就进入正题了：把本地已有的项目文件传到 GitHub。我不知道你手头项目是什么类型，可能是一堆 HTML/CSS 页面，可能是一个 Python 脚本，也可能是一整个前后端工程。放心，流程完全一样，目录里有什么文件它就传什么文件。

3.1 先在 GitHub 上创建一个空仓库

登录 GitHub，页面右上角的加号图标，点击 New repository。

Repository name 填仓库名，最好和项目名一致，比如my-blog或者todo-app。描述可填可不填，我建议填一句，仓库页上看起来更专业。

最关键的一步：不要勾选 "Add a README file"，也不要添加.gitignore或 license。这是为了让仓库初始状态完全为空，避免和本地已有的仓库历史产生冲突。很多新手第一次 push 失败，各种 "failed to push some refs" 的错误提示，十有八九就是因为网页创建仓库时自动生成了 README，本地仓库和远程仓库各自有了一次不相干的提交，历史对不上。

创建完成后的页面会给两个地址：HTTPS 链接和 SSH 链接。复制 SSH 链接，样子类似于git@github.com:用户名/仓库名.git。

3.2 在本地项目目录中初始化仓库

打开终端，进入项目根目录。Windows 用户可以在文件夹路径栏输入 cmd 或 powershell 回车，直接打开对应路径的终端。

cd 项目路径 git init

git init的意思是在当前目录创建一个隐藏的.git文件夹，这个文件夹就是 Git 用来记录历史的数据库。执行完这一步，当前目录就成了一个本地 Git 仓库。

接下来看看目录里有哪些文件，Git 的状态是什么：

git status

此时所有文件应该都会出现在 "Untracked files" 列表里，意思是 Git 发现了这些文件，但还没有纳入管理。

3.3 添加所有文件到暂存区

git add .

这个命令把当前目录下所有未被忽略的文件加入暂存区。注意有个点号，代表当前目录。执行后再用git status看，文件会移动到 "Changes to be committed" 列表里，说明已经进入篮子。

提示：不需要一下子全部 add，你也可以只添加某个文件，比如git add README.md。但对于第一次上传，用.一次性添加所有文件没毛病。

3.4 提交一次快照

git commit -m "first commit"

-m后面是提交说明，告诉未来的你（以及协作者）这次提交做了什么。规范一点的提交信息能让你三个月后回看历史时不至于一头雾水。第一次上传用一个简单的 "initial commit" 没问题。

看一下提交是否成功：

git log --oneline

应该会输出一行记录，类似abc1234 (HEAD -> master) initial commit。注意括号里显示的是master，这是 Git 的默认分支名。早期默认分支都叫 master，现在 GitHub 推荐用 main，后面我会把本地分支改名。

3.5 把本地提交和远程仓库关联并推送

先给本地添加远程地址：

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

origin是远程仓库的别名，纯粹是个习惯叫法，表示"我这个项目主要对应的远程仓库"。你可以用任意名字，但全世界都用 origin，你没必要特立独行。

然后把分支名从 master 改成 main，并推送过去：

git branch -M main git push -u origin main

-u参数很关键，它把本地 main 分支和远程 origin/main 分支关联起来。以后你在这个分支上直接敲git push和git pull，Git 就会自动知道要操作哪个远程仓库的哪个分支，不用再带完整参数。

推送过程中如果 SSH 配置正确，不会要求输密码。结束后登录 GitHub 仓库页面刷新，应该能看到你的所有文件已经出现在上面了。

整个上传流程走下来，核心就是这几步：后端建空仓库、本地init、add、commit、remote add、push。把这个链条刻在脑子里，比背一百条命令都有用。

4. 日常修改的正确打开方式：每次改动都要走完四个状态

项目传上去之后，真正高频的操作场景是：本地改代码，然后让 GitHub 上的远程仓库也跟着更新。这个流程比首次上传简单，但恰恰是新手最容易产生困惑的地方，因为首次上传只要记住一条新路径，而日常改动的循环需要理解"状态流转"。

4.1 每改动一次，都要重复 add、commit、push

假设你本地项目里有个README.md文件，现在你想补充一段项目说明。用编辑器改完之后，查看状态：

git status

输出会提示 "Changes not staged for commit"，README.md 出现在这个区域，说明文件已经变了，但改动还没进入暂存区。

接下来依次执行：

git add README.md git commit -m "update readme" git push

我见过很多新手只改文件，不 add、不 commit，直接执行 push，于是终端提示 "Everything up-to-date"。他们很费解：我明明改了啊，怎么没推送上去？原因就是改动还没打包成一次提交，Git 远程仓库里记录的还是上一次 commit 的状态。

所以要养成一个条件反射式的流程：

1. 改代码之前，先git pull拉取远程最新代码，确保本地不是旧版本。
2. 改完代码，用git status看哪些文件变了。
3. 确认无误后git add对应文件（或git add .全部添加）。
4. 用git diff --cached看看暂存区里的改动是否确实是自己想要的。
5. git commit -m "描述性信息"提交。
6. git push推送到远程。

这套流程每次操作可能要反复看状态提示，但这就是 Git 的正常工作方式。等熟练之后会快很多，但步骤一步都不能省。

4.2 新增文件、删除文件各是什么情况

修改旧文件用上面的流程没问题，但新手容易忽略"删除文件"和"新增文件"这两个特殊场景。

新增文件：新文件创建后默认是 untracked 状态，必须先用git add 新文件让它进入 Git 管理，然后再 commit、push。如果你在项目里新建了一个.env文件或者一张图片，只 commit 其他文件，新文件不会自动被纳入历史。

删除文件：如果你直接在文件管理器里删掉了某个文件，Git 会检测到这个删除（显示为 deleted），需要执行git add 被删文件或者git rm 被删文件来确认这次删除，然后 commit、push。如果你忘了这一步，删除只发生在工作区，远程仓库里那个文件还在。

这里有个细节值得注意：git add .会把当前目录下所有变化——修改、新增、删除——一起纳入暂存。对新手来说，在确认所有改动都是自己预期的情况下，用git add .比较方便。但如果项目里有多个不相关改动，建议分文件提交，让历史更干净。

4.3 用 git log 看历史，确认自己的每一次提交

推送完之后，可以用以下命令看提交历史：

git log --oneline

输出会按时间倒序列出所有 commit。每次提交都有一个唯一的哈希值、提交信息和作者。如果提交信息写得足够清楚，历史就是一份项目演变日志。

有一次我看到一个朋友的提交信息全是 "updata"、"233"、"test"，隔半年再回来看项目，完全想不起每个改动对应什么功能。所以我个人的习惯是写提交信息时遵循"动词+改动对象+原因"的结构，比如 "fix: 修复登录页在 Safari 下的样式错乱问题"，"feat: 新增文章评论功能"。不一定学丰富，但至少别写 "aaa" 这种没意义的内容。

4.4 push 之前为什么建议先 pull

如果你是项目唯一的开发者，理论上每次 push 前不需要 pull，因为远程不会有别人改动的记录。但当你开始参与开源项目，或者和同学、同事协作，远程仓库很可能会有更新的提交。

如果本地和远程在同一个文件、同一个位置都做了修改，直接 push 会被拒绝，Git 会提示 "Non-fast-forward" 或者 "rejected"。正确做法是先拉取远程改动，合并后再推送：

git pull git push

git pull实际上是两步的简写：先git fetch把远程新提交拉到本地，再git merge合并到当前分支。如果合并时没有冲突，它会自动完成；如果有冲突，Git 会在文件里标记冲突位置，需要手动处理后再提交。

对新手来说，养成改动前先 pull 的习惯，等于给自己减少了大半的冲突烦恼。哪怕你是唯一的开发者，从另外一台电脑上改过代码时，pull 同样能避免本地版本停留在过去。

5. 新手上路最常见的坑，以及我的处理建议

最后聊几个我在实际指导和平时逛社区时看到频率最高的新手翻车场景。这些坑不碰上最好，碰上了也别慌，按下面的思路处理基本都能解决。

5.1 push 被拒绝：远程有本地没有的提交

报错提示一般是这样的：

! [rejected] main -> main (fetch first) error: failed to push some refs to 'git@github.com:xxx/xxx.git'

新手看到这个第一反应是删了仓库重来，其实问题的原因是远程分支上有本地分支不存在的提交。可能是因为你网页上删除过文件，或者其他人推过代码，或者创建仓库时勾选了 README。

处理方案分两种：

• 如果远程那些提交你确定要保留，就执行git pull --rebase。--rebase的意思是先把本地提交"暂存起来"，把远程新提交放进来，再把你的提交放上去，历史看起来像一条直线。对新手来说，这种方式比直接git pull产生的合并记录更干净。
• 如果远程那些提交是你不需要的（比如误生成的 README），并且你确定本地才是正确的状态，可以执行git push -f强制覆盖。警告一下：强制推送会让远程历史被本地历史替换，在协作项目里这是危险行为，但在你自己单独维护的仓库、且确定没有其他协作者时，用它收拾残局没问题。

5.2 提交了不该提交的大文件，push 一直卡住

游戏资源包、数据集、模型文件、node_modules 这类体积巨大的内容，推送到 GitHub 会特别慢，甚至直接失败。GitHub 对单个文件大小有 100MB 的硬限制，一个超大文件会让整个 push 卡死。

这个问题应该在提交之前就想办法规避：在项目根目录创建.gitignore文件，把不需要纳入版本管理的目录和文件写进去，比如：

node_modules/ dist/ .env *.log .DS_Store __pycache__/

.gitignore写好后，git add .会自动跳过这些文件。如果你在第一次上传时没建.gitignore，现在补上也不迟，Git 会忽略新建的文件，但已经提交过的超大文件需要从 Git 历史里移除，操作起来麻烦得多。

如果真的不小心把大文件推上去了，GitHub 页面会收到邮件警告。移除它可以用git rm --cached 大文件，但这个命令只停止跟踪，不清除历史。要彻底从历史里抹掉，涉及git filter-branch或git filter-repo这类重写历史的操作，对新手来说有点复杂。我的建议是：如果你还在项目早期，最省事的方案是新建一个干净仓库重新传一次，损失最小。

5.3 提交信息写错了怎么办

刚写完 commit 就发现信息写错了，还没 push 的话，用：

git commit --amend -m "正确的提交信息"

它会修改最近一次提交的信息。注意--amend会生成一个新的提交哈希，所以只适用于还没推送的提交。如果已经 push 了，改起来就涉及历史重写，除非特别必要，否则建议重新提交一次覆盖纠正，而不是动历史。

5.4 误提交了敏感信息

这个坑我放到最后说，因为它可能是最严重的一个。有人喜欢把数据库密码、API 密钥、私钥写进配置文件，然后连同整个项目一起 push 到 GitHub。如果仓库是公开的，这些敏感信息等于直接暴露给了全世界。

严格来说，一旦敏感信息被推送到公开仓库，就应该默认它已经泄露了。此时需要做的不是只删除文件再提交，而是立即去对应的服务商处重置密钥、密码。我见过太多人只删了文件，以为自己安全了，实际历史记录里还保留着完整内容。

预防大于补救。配置文件里涉及密钥的部分，建议用环境变量或者单独的.env.local文件管理，并把该文件写进.gitignore。推代码之前，扫一眼git status，看看这次 add 的文件里有没有明显不该出现的配置文件。

5.5 关于 Windows 换行符引发的"全文件变动"

这个坑只影响 Windows 用户，怪得很，但很容易让新手慌掉。有时候你只是改了一行代码，commit 时发现 Git 提示整个文件几百行都变了。原因很可能是换行符差异：Windows 用 CRLF，Linux/macOS 用 LF，Git 在拉取或提交时自动做了行尾转换。

解决方法是设置 Git 的 autocrlf 规则：

# 推荐 Windows 用户使用 git config --global core.autocrlf true

这样 Git 在提交时会把 CRLF 转换成 LF，在检出时又转换回 CRLF。在项目团队中，这个配置最好通过仓库内的.gitattributes文件统一约定，否则每个人本地的换行规则不一样，容易互相刷屏。

如果已经出现了全文件变动，处理方法：先把改动全部git checkout .还原，设置完 autocrlf 后重新修改、提交即可。

再分享一个我自己的使用习惯：每天开始工作前先git pull，改完一部分就 commit 一次，提交信息用一句能概括改动内容的话；临结束前统一git push。不要攒几天的改动一次性提交，那样万一出问题，定位起来非常痛苦。

我见过太多新手在 GitHub 入门阶段，因为一次 push 失败就产生挫败感，觉得自己不适合搞技术。其实不是你的问题，是 Git 这个工具的学习曲线确实有点陡。它的底层逻辑很简洁，但平时常用的命令组合有几十种，每种报错信息都不一样。把这篇文章里从创建仓库到日常 push 的流程完整走两三遍，你就会发现，上传和更新项目这件事，慢慢就会变成一种肌肉记忆。