企业官网建设流程全解析

从一个小白到能正常把代码放到GitHub上，这个过程中的坑比想象中多。很多教程默认你熟悉命令行，直接甩给你一串 git 命令让你复制粘贴，结果页面刷新后什么都没有发生，既不知道错在哪，也不知道下一步该干嘛。这篇文章试图换一种方式，不堆砌命令列表，而是把GitHub最核心的逻辑拆开讲清楚，再一步步带你完成从安装、建仓库、提交代码到发起 Pull Request 的完整流程，顺带还会讲几个日常开发中必踩的坑。

1. 先搞清楚GitHub到底在解决什么问题

1.1 版本管理为什么不是"多存几个文件"

不少新手第一次接触GitHub时，最大的困惑是：我明明可以用项目_最终版_v3.zip这种命名方式来管理代码，为什么要用一个看起来这么复杂的工具？

你可以先做一个很简单的实验：分别在两个文件里保存同一段代码的不同版本，然后试图回忆起"为什么第二个版本删掉了一个函数""为什么第三个版本改了变量名"。这种回忆往往以失败告终，因为你没有记录改动的原因、改动的时间，以及每处改动的上下文。

GitHub的核心价值，是给整个项目的"变化过程"建立一个完整的、可追溯的记录。它不仅保存了每个文件的最新内容，还保存了历史中的每一次修改、谁改的、什么时候改的、改之前是什么样、为什么改（通过提交说明）。这套机制的专业名称是"版本控制"，但你可以把它理解成一个不会丢失任何历史痕迹的存档点系统。

1.2 本地Git和云端GitHub的分工

这里还有一对经常被混淆的概念：Git 和 GitHub 不是同一个东西。

Git 是一个运行在你电脑本地的版本管理工具，负责跟踪文件变化、创建提交记录、管理分支。它不依赖网络，也不依赖任何网站。你在本地做的一切操作，包括 commit、branch、merge，都是在自己电脑上完成的。

GitHub 则是建立在 Git 之上的一个云端协作平台。你本地的 Git 仓库需要推送到远程端，其他人才能看到、协作和同步。

以一个实际项目为例。你在本地用 Git 初始化一个仓库，每写一段稳定的代码就git commit一次，形成一个存档点。如果你想把这个项目和别人共享，或者希望自己在另一台电脑上继续写，就需要把仓库推送到 GitHub 上。远程仓库的存在，使多人协作成为可能——每个人在各自的本地仓库上工作，通过 push 和 pull 同步修改。

很多教程一上来就让新手安装 Git 然后立刻开始敲命令，但省略了对这套基本逻辑的铺垫。结果就是新手在操作时根本不知道自己在和本地组件交互还是在和云端组件交互，出错后更没法定位问题出在哪一层。

2. 新手上路第一步：创建仓库、克隆代码与第一次提交

2.1 前置准备：安装Git与配置用户信息

工欲善其事，必先利其器。不管你是哪个操作系统，第一步都是把 Git 装上。Windows 用户可以从官方渠道下载安装包，安装时建议保持默认选项，注意选择"能够在右键菜单中使用 Git Bash"这类选项，后面操作会更顺手。macOS 用户如果装有系统自带的 command line tools，通常自带 Git；不确定的话可以先在终端里输入git --version看一眼。

安装完成后，你需要做的第一件事不是创建仓库，而是配置身份信息：

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

这段配置的用途是给每一次提交记录打上标签，告诉无论你还是协作者，这次改动出自谁手。如果跳过这步，你第一次 commit 时大概率会看到一个提示信息，告诉你需要先设置 user.name 和 user.email。

这里有一个小技巧：既然是"全局"配置，建议你认真考虑用哪个邮箱。如果打算长期参与开源项目，可以专门用一个不含太多隐私信息的邮箱，或者使用平台提供的隐私邮箱功能，避免个人邮箱暴露在公开仓库的历史记录里。

2.2 创建仓库的两种路径

路径一：先在 GitHub 云端创建仓库，然后克隆到本地。

登录 GitHub 后点击右上角的"New repository"，会看到一个表单要你填仓库名、描述、可见性（public / private），以及是否要自动添加 README 文件。完成之后，你会进入一个空仓库页面，上面显示了几条推荐命令。最常见的方式是复制仓库的 HTTPS 地址，然后在终端里执行：

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

这条命令会把远程仓库完整复制到当前目录下，包含所有历史记录和分支。所谓"克隆"，本质上就是一次完整的下载。

路径二：在本地先用 Git 初始化，再把内容和云端做关联。

这在你有现成代码、但还没创建远程仓库时使用。操作顺序是先在 GitHub 上创建一个空仓库（不勾选任何初始化选项），然后回到项目目录：

cd 你的项目目录 git init git add . git commit -m "first commit" git remote add origin https://github.com/用户名/仓库名.git git push -u origin main

这两种路径没有本质优劣。如果是一个全新项目，我其实更推荐路径一，也就是先建仓库再克隆，因为它会自动帮你处理 README、分支名等基础设置，减少很多新手最容易踩的"分支名不一致"的问题。

2.3 第一次提交的完整操作

假设你已经通过克隆或初始化获得了一个本地 Git 仓库，接下来要做的就是把文件装进"存档点"。

整个流程由几个固定步骤组成：

1. 查看仓库状态。
2. 将改动加入暂存区。
3. 提交改动并附上说明。
4. 推送到远程仓库。

具体命令：

git status git add . git commit -m "添加了项目初始代码" git push

对新手来说，理解暂存区（staging area）是理解 Git 的一个关键点。你可以把暂存区想象成一个购物车。你从货架上拿下商品（修改文件）后，它们并不会自动进入购物车，而是需要先git add把它们放进去。git commit相当于结账，明确记录这一单买的是什么。而git push才是把这批商品从本地快递到云端仓库。

为什么设计这个中间环节？因为有时候你在一个下午改了很多文件，但这些文件不一定都属于同一个逻辑单元。比如一个文件修了登录框的 bug，另一个文件加了一个新页面，你可能希望它们分成两次提交，便于以后回查历史。如果所有改动混作一团直接提交，以后的排查成本会很大。

实际开发中，我几乎每次git change的文件都不止一个。合理的拆分逻辑是：一次提交只做一件事。修改了接口文档，就不要夹带私货改了一行跟接口无关的代码。这类习惯越是早期养成，后面对你审视项目和排查问题的帮助就越大。

3. 分支操作是协作的核心：从本地实验到Pull Request全流程

3.1 分支的本质：平行时空

新手一开始接触 Git 时，很容易认为所有的改动都在一条线上依次排队。但这个模型很快就会被团队协作打破——两个人同时修改同一个文件该怎么办？答案就是分支。

分支的本质是让一份代码同时存在多个"平行时空"。在每个时空中，代码可以从同一个起点开始，朝不同的方向演化，互不干扰。完成后再把不同时空中的改动合并回主线。

以最常见的工作流为例：

• main分支是项目的"正式版本"，要求时刻处于可运行状态。
• 当你开始开发一个新功能时，从main拉一个功能分支，在这个分支上做实验。
• 功能开发完毕后，通过合并操作把改动带回main。

这样做的好处很明显：主线永远稳定，你的实验和潜在 bug 不会污染正式版本，主线的维护者也有机会在合并前至少看一遍改动。

3.2 本地分支操作基础

从当前分支新建并切换到一个新分支，最常用的命令是：

git checkout -b feature/login-page

这条命令等价于两条命令的组合：git branch feature/login-page（创建分支）+git checkout feature/login-page（切换分支）。在新版 Git 中也可以使用git switch -c feature/login-page，效果一致。

完成开发后，把当前分支的改动提交并推送：

git add . git commit -m "完成登录页面布局" git push -u origin feature/login-page

这里的-u参数设置了一次性关联关系，告诉 Git"当前分支和远程分支建立了跟踪关系"。之后你再在这个分支上继续 push，就不用每次带上完整参数了。

3.3 Pull Request：不是直接合并，而是"发起请求"

分支合并之间有一个非常重要、也非常体现 GitHub 价值的概念：Pull Request（简称 PR，在有些平台上也叫 Merge Request）。

要理解 Pull Request，可以先区分"合并"和"请求合并"这两件事。在本地命令行里，你可以直接执行git merge把两个分支合并，不会经过任何审批流程。但如果是多人协作，尤其是团队规模较大时，没有人希望谁都可以一声不吭地把代码改到主分支上。这时 Pull Request 就登场了——它不是一个 Git 命令，而是 GitHub 提供的一种协作机制。

工作流程是：

1. 你在本地完成功能开发，推送分支到远程仓库。
2. 在 GitHub 网页上发起 Pull Request，申请把这个分支合并到另一个目标分支。
3. Pull Request 页面会清楚展示改动内容——哪些文件变了、每个文件对应哪几行代码被增删。团队成员可以在这个页面里逐行评论、讨论。
4. 仓库维护者审核完毕后，点击合并按钮，代码才真正进入目标分支。

相比直接合并，Pull Request 的意义不只是"审批流程"。更重要的是，它把代码审查这个动作沉淀成了一种可见的工作流，而不是靠团队口头沟通把关。对于开源项目来说，Pull Request 还是外部贡献进入项目的主要入口——陌生人不能直接改动你的仓库，但可以 fork 一份后在这个原仓库上发起合并请求。

有经验的开源维护者审阅一份 Pull Request，通常会看三件事：改动是否解决了问题描述、它会不会引入回归、是否有遗漏的测试场景。你要知道的是，写清楚 PR 描述是减少协作摩擦的极高性价比操作。好的描述里至少应该包含：改动目的、改动内容、测试方式、关联的 issue 编号。我见过无数人 PR 标题只写"fix bug"或"update"，这等于把应该由自己承担的上下文转嫁给每个看 PR 的人，大大降低协作效率。

4. 实际协作中的高频场景：冲突、回滚、忽略文件的处理

4.1 合并冲突：不是洪水猛兽，而是正常机制

如果你参与过团队项目，迟早会撞上合并冲突（merge conflict）。

冲突的本质是：两个分支修改了文件的同一行，并且都认为自己才是正确版本，Git 无法自行判断应该保留哪个，只能把决定权交给你。

触发冲突时，Git 会在冲突文件里插入特殊标记，告诉你在哪个位置出现了分歧。打开文件后，你会看到类似这样的内容：

<<<<<<< HEAD 这里是当前分支的改动 ======= 这里是对方分支的改动 >>>>>>> feature/branch-name

你需要做的就是手动决定保留哪一边的内容，或者融合两者，然后删掉这些标记行，保存文件，再执行一次提交。

解决冲突时我有一条几乎不会出错的建议：绝不只凭直觉乱改。看到冲突后，先确认这两处改动的意图分别是什么。很多情况下，冲突并不可怕，只需要把两边的改动都保留下来，放在不同的位置就行——它们只是恰好出现在了同一行上而已。

一个降低冲突频率的实用习惯是：频繁地同步远程改动。你 fork 一个功能分支出来前，应该先git pull一下main分支的最新内容。开发过程中，每次觉得到了一个小节点，也建议再 pull 一次。你的分支存活时间越长，冲突的概率就越高。越早暴露冲突，解决起来代价就越小。

4.2 没救回来的操作：撤销、回退与后悔药

开发中经常遇到的一种慌神场景是：提交了不该提交的东西，或者发现自己的代码写错了想回退。Git 提供了好几种"后悔药"，但每种药的适用场景完全不同。

如果你只是最近一次提交想改掉（比如提交信息写错了）：

git commit --amend

这条命令会把暂存区里新的改动加入上一次提交，同时允许你重新修改提交说明。前提是这次提交还没有被推送到远程，或者推送后还没有被别人拉走。如果改动已经推送到公共分支且被人引用了，用--amend就会造成历史不一致，带来更大的麻烦。

如果是想回退某次已经推送到远程的提交，用得最多的是git revert：

git revert <commit-id>

revert的逻辑不是"删除"那次提交，而是创建一个新的提交，把之前的改动反向翻转回来。这听起来有点绕，但它的好处是历史不会被改写，等于在时间线上加了一个"取消"记录。这对于协作分支来说更安全。

如果你还没有把改动推送到远程，只是想彻底抹掉最近的几次提交：

git reset --hard HEAD~2

这条命令会直接把 HEAD 指针退回到两个提交之前，被重置掉的那些改动会彻底消失。注意，--hard是很强的操作，执行后未提交的工作区改动也会一并丢弃。我第一次实践 reset 后就吃过一次亏：把一整天的工作内容全部冲掉了，当时心里非常崩溃。所以新手在自己不熟悉的命令前多留个心眼，先用--soft或者--mixed这些温和模式试试看，或者先做一次 branch backup，给自己留退路。

4.3 .gitignore：让仓库只保留该保留的东西

新建项目时，有一个文件几乎是必需品：.gitignore。

这个文件的作用是告诉 Git 忽略哪些文件或目录。在使用 Git 的过程中，一开始会觉得理所当然——所有文件都被跟踪不是挺好吗？但很快就会出现下面的情况：本地项目目录里多了node_modules（依赖包目录）、编译输出目录、IDE 自动生成的配置文件、日志文件、本地环境变量文件。如果这些都被提交到仓库，就会出现几个问题。

首先是大仓库膨胀。一个node_modules目录动辄几百兆，每次提交、拉取都会变得很慢。其次是噪音，每次增减依赖都会让仓库的 diff 变得不可读，卷进大量无关文件的改动。最后是安全风险，本地环境变量文件里往往存着密钥、口令等敏感信息。

因此一个好的.gitignore至少要覆盖下面几类内容：

• 依赖目录：如node_modules/
• 编译输出目录：如dist/、build/
• 系统文件与 IDE 配置
• 环境变量与密钥文件：如.env、*.pem
• 日志文件：如*.log

GitHub 官方对此维护了一套常用模板，你可以在项目初始化时选择对应语言的标准忽略文件。但模板是通用配置，实际项目应根据自身情况手动补充特殊情况。

有一点要特别注意：.gitignore只能对尚未被 Git 追踪的文件生效。如果你之前已经把某个文件提交过了，再在.gitignore里加一行忽略规则，Git 并不会停止追踪它的变化。这时候需要用git rm --cached 文件名先把文件从追踪列表中移除，再配合忽略规则才有效果。

5. HTTPS还是SSH：连接认证方式的选择

5.1 Token认证：现代GitHub推荐的方式

把代码推送到 GitHub 需要身份验证。早些年这个环节最简单的方式是输密码，但出于安全考虑，GitHub 很早就取消了账户密码直接用于 Git 操作的方式，取而代之的是个人访问令牌（Personal Access Token，简称 PAT）。这个令牌相当于一张限权门禁卡，可以设定权限范围和有效期限。

创建方式很直接：在 GitHub 设置页面中选择生成新令牌，勾选需要的权限范围（至少需要repo权限才能对代码仓库进行推送），生成后复制并保存好这段字符串。它只会在生成的那一刻完整显示一次，之后你无法再查看原值，只能重新生成。

拿到 Token 后，HTTPS 协议下的 push 操作会自动提示你输入用户名和密码。用户名填你的 GitHub 用户名，密码处不要填密码，粘贴 Token 进去即可。为了防止每次操作都输入一次，你还可以配置系统凭证管理器，让系统记住这部分凭据，后续自动携带。

使用 Token 的最大优势是权限精细可控。即使某个 Token 不幸泄露，你可以在设置页面直接吊销它，而不需要改动任何其他东西。

5.2 SSH Key：免密的长期选择

如果你需要在多台设备上频繁操作仓库，SSH 方式是体验更好的选择。

SSH 的认证思路是"我认钥匙，不认人"。你在本地生成一对密钥——一把私钥（自己留好）、一把公钥（放置到 GitHub 账号设置里）。之后本地 Git 向 GitHub 发起连接时，GitHub 通过密钥匹配完成身份确认，不再需要每次输入账号和 Token。

生成过程：

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

一路回车即可生成默认位置的一对密钥。然后查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的一大段字符串，粘贴到 GitHub 设置里的"SSH and GPG keys"页面即可。

之后把仓库的远程地址改成 SSH 形式即可。

对新手，我的建议是：如果只是偶尔使用，或使用场景在公共电脑上，选择 HTTPS + Token 更省心。如果是自己日常使用的固定设备，值得花几分钟配好 SSH，后面每次 push 都节省几秒操作。不要两种混着用，选择一个认定后保持专注，避免把远程地址反复改来改去造成多余的心理负担。

5.3 常用命令一览与查询技巧

很多新手遇到的实际问题是：命令一多就乱套。其实日常开发需要熟练敲入的命令不超过二十条。这里我做了一份高频命令清单，可以当成速查卡：

# 查看仓库状态（推荐频繁执行） git status # 查看提交历史 git log --oneline # 把改动放进暂存区 git add 文件名 # 提交改动 git commit -m "说明信息" # 推送本地提交到远程 git push # 拉取远程最新改动 git pull # 新建并切换分支 git checkout -b 分支名 # 切换分支 git checkout 分支名 # 合并分支到当前分支 git merge 分支名

比忘命令更让人沮丧的，是忘了一堆参数的含义。我的经验是：不需要把所有命令都背下来，Git 的帮助系统就是最好的记忆辅助，遇到想不起来的参数，用git help 命令名或者git 命令名 --help调出完整说明文档即可。

6. 新手起步阶段最容易忽略的操作习惯

6.1 提交信息要写得像一封短备忘录，而不是"一堆随机字符"

如果你去翻一些知名开源项目的提交历史，会发现一个普遍规律：几乎每条提交信息都在回答两个问题——"这次改了什么"和"为什么这么改"。

相比之下，新手常见的提交信息是这样的：update、add files、fix、coding、修改。假设三个月后你再也想不起来自己在做什么，拉到一条"fix"，你会获得多少线索？几乎没有。

这里分享一个简单好上手的提交信息模板：

<类型>(<范围>): <简短描述> 详细说明（可选）

类型通常有 fix（修 bug）、feat（新功能）、docs（文档改动）、refactor（重构）、style（格式调整）等。范围指这次改动影响到的模块。描述则用一句话说清楚核心内容，比如fix(auth): 修复登录后token未刷新导致接口401。

我不是说必需严格按某个规范书写。关键是让描述带有足够上下文，别人接手时不需要重新阅读全量 diff 也能大概理解这次的改动目标。这个习惯带来的长期收益远比看起来大得多——你最终读历史记录的时间和写代码的时间可能是等量齐观的。

6.2 什么时候该提交，什么时候不该提交

新手还有两个相邻的困惑：一是"改动多大才值得提交"，二是"代码没写完要不要提交"。

先说不值得提交的类型。几百个文件里有一半是系统自动生成的临时文件，不该进提交。代码里有调试用的临时打印、试运行后的废弃函数，也不建议提交。

再说说提交节奏。经验法则是：只要当前状态下代码可以正常结束、不会有编译错误，且你清楚这次提交的目标，就值得提交。提交得越频繁，历史里能表达的信息就越多，未来定位问题的切分点也越细。大量不成为提交没有价值，也没有意义。

有一种做法强烈不推荐：一口气写了几千行，然后一次性提交。这会让代码审查几乎不可行——没人能在一页几百个文件里注意到局部的小问题。正确姿势是每完成一个小功能点，即提交一次，尽量让每次提交足够原子化。

6.3 README与License：让仓库从代码片段变成完整项目

一个完整的 GitHub 仓库，代码以外通常还有两个标配文件。

README 是用来承载项目说明的入口文件。它的核心内容通常包括：这个项目解决了什么问题、环境要求、如何安装、如何调用、如何测试。对开源项目而言，优秀的 README 还能起到"说明书+营销页"的作用，让访问者一眼就知道这个仓库值得不值得点 star 或者提交 issue。

License 则决定了别人能不能合法地使用、修改、分发你的代码。很多人以为"只要我把代码公开在 GitHub 上，别人就默认可以用"，这是一个常见误解。从版权角度说，公开代码不代表放弃版权。如果仓库里没有 License，那么法律意义上其他人仍然不能随意使用你的代码来做商业项目等。GitHub 有标准化的选许可证流程，如果你不关心细节，MIT License是自由度较高且最常见的选择之一。

7. 从入门到日常使用：一些过来人的体会

写到这里，基础的 Git 操作和 GitHub 业务流程其实已经串起来了。最后再分享几条我踩过不少坑之后觉得比"学会命令"更重要的心得。

第一，先学会看报错信息。新手遇到 push 失败时经常会慌，把一大段红色报错粘贴到搜索引擎里，然后照着别人给的命令乱七八糟敲。但实际上多数报错信息本身已经把问题说得很清楚了。最典型的比如failed to push some refs，通常在报错提示上方就已经解释了原因——远端有本机没有提交的数据。这时候执行git pull同步一次，通常问题就解决了。

第二，养成git status和git log的好习惯。它们不单单能告诉你仓库当前状态，还能帮你观察"我当前到底在哪个分支""我的上一次提交到底是什么"。尤其在操作了几个仓库之后，大脑很容易记混不同项目的分支状态，而命令给出的信息是最可信的。

第三，不要畏惧冲突和你确认不了的操作。Git 设计得非常严密的一点在于，几乎每个危险操作都留了至少一条退路。只要你的代码推送到远端或者有了备份副本，本地即使全部撸掉也可以抢救回来。我本人的经历是，手滑执行过 reset、误删过分支，也在别人的主导下被迫解决过一次跨文件的冲突。遇到这类情况时最重要的反而是耐心——逐个文件、逐行信息确认，而不是靠直觉和运气。

如今打开任何成熟的软件项目主页，第一眼看到的都是 README、分支、贡献指南、Pull Request 流程等信息。这套基础设施相当深入人心。作为入门者，花几个小时搞懂背后的原理，远比你背下二十个命令更有长期价值。上手之后你会发现，GitHub 非但不复杂，反而是那种越用越顺手、一旦用惯了再也不想回到"文件命名管理法"的工具。

我很认真地希望你边读边打开电脑试试，而不是收藏完就放在那里。毕竟 Git 类的工具，读再多的经验文章也不如亲手推送一次来得直观。