企业官网建设流程全解析

GIT和Github基本知识

• Git：安装在电脑上的版本管理工具，负责记录文件变化、创建分支、合并代码、恢复历史。
• GitHub：托管 Git 仓库的网站，负责远程备份、多人协作、代码评审、Issue、自动化测试等。

即使不用 GitHub，Git 也能独立工作；GitHub 则主要围绕 Git 提供协作服务。

1. 建立 Git 的核心概念

工作区 → 暂存区 → 本地仓库 → GitHub远程仓库 git add git commit git push

代码流经的4个区域：

1. 工作区 Working Tree：

   就是你正在编辑的项目文件。修改了app.py，但还没执行任何 Git 命令，此时变化只存在于工作区。

2. 暂存区 Staging Area：

   你准备放进下一次提交的文件。允许你精确选择这次提交包含哪些变化。

   git add app.py # 把 `app.py` 当前的修改放入下一次提交。

3. 本地仓库 Local Repository:

   git commit -m "添加用户登录功能"

   Git 会把暂存区中的内容保存为一个本地历史版本。此时提交只在你的电脑上，GitHub 还不知道。

4. 远程仓库 Remote Repository:

   git push

   把本地提交上传到 GitHub。

Git的重要对象：

• 仓库 Repository：一个被 Git 管理的项目目录，通常简称“repo”。

  git init # 初始化新仓库：

  目录中会生成隐藏的.git文件夹，里面保存版本历史、分支和配置信息。

  不要手动修改或删除.git。

• 提交 Commit：一次有明确意义的版本记录。

  git commit -m "修复订单金额计算错误"

  每次提交都有唯一编号，例如：a7f42c1

  可以把 commit 理解为“项目存档点”，但它不是简单复制整个文件夹，而是由 Git 高效管理文件状态和历史关系。

• 分支 Branch： 分支是一条独立的开发路线。

  main ├── feature/login └── fix/payment-error

  main：稳定主版本

  feature/login：开发登录功能

  fix/payment-error：修复支付错误

  git switch -c feature/login # 创建并切换分支

  git switch main # 切换已有分支

• 合并 Merge：把一个分支的修改整合进另一个分支。

  git switch main git merge feature/login

  先来到main，再把feature/login合并进来。

• 远程仓库 Remote：GitHub 上的仓库通常会被命名为origin。

  git remote -v # 查看远程仓库

  git remote add origin https://github.com/用户名/仓库名.git #添加远程仓库

  这里的origin只是一个默认别名，并不是特殊关键字。

2. 第一次使用 Git

1 安装完成后配置身份

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

git config --global --list # 查看配置

建议使用与 GitHub 账号关联的邮箱，这样 GitHub 更容易把提交识别为你的贡献。

2 设置默认分支名

git config --global init.defaultBranch main

3 初始化项目

cd 项目目录 git init

4 创建.gitignore

.gitignore用来告诉 Git 哪些文件不要管理，例如：

# 环境变量和密钥 .env # Python __pycache__/ .venv/ # Node.js node_modules/ dist/ # 编辑器配置 .vscode/ .idea/ # 日志 *.log

尤其不要提交：密码、API Key、数据库凭、.env`、私钥、大型依赖目录

已经提交过的文件，后来写进.gitignore并不会自动停止跟踪，需要执行：

git rm --cached 文件名

5 创建第一次提交

git status # 确认没有意外文件 git add . git commit -m "初始化项目"

git add . # 表示暂存当前目录下的所有变化

3. 最常用的 Git 命令

查看状态

git status # 查看状态

它会显示：当前分支、哪些文件被修改、哪些文件已暂存、哪些文件未被 Git 跟踪、本地分支是否领先或落后于远程分支。不确定该做什么时，先运行git status。

查看修改内容

git diff # 查看尚未暂存的变化 git diff --staged # 查看已经暂存的变化

暂存文件

git add app.py # 暂存指定文件

git add app.py README.md # 暂存多个文件

git add . # 暂存所有变化

git add -p # 交互式选择部分变化

提交

git commit -m "添加商品搜索功能"

好的提交信息通常说明“做了什么”：（如：添加邮箱验证码登录、修复空购物车结算错误、更新本地开发说明、重构订单查询逻辑）

尽量避免：修改、update、完成、再改一下

查看历史

git log --oneline # 简洁查看

git log --oneline --graph --decorate --all # 查看分支关系图

git show 提交编号 # 查看某次提交

查看分支

git branch

git branch -a # 查看本地和远程分支

git switch -c feature/login # 创建并切换新分支

git branch -d feature/login # 删除已经合并的本地分支

克隆仓库

从 GitHub 下载完整仓库：

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

它会下载：项目文件、Git 历史、分支信息、远程仓库配置

4. push、pull 和 fetch 的区别

git push

git push # 把本地提交上传到 GitHub

git push -u origin feature/login # 第一次推送新分支

-u会建立本地分支与远程分支的追踪关系。以后可以直接执行：git push

git fetch

git fetch origin #从 GitHub获取最新信息，但不修改当前工作分支

这是相对安全的“看看远程有什么变化”。

git pull

git pull # 获取远程更新，并整合进当前分支

它大致相当于：

git fetch git merge

团队开发中，常见做法是：

git switch main git pull

然后再从最新main创建功能分支。

5. GitHub 的主要功能

Repository

存放代码、Git 历史和项目文档。

Pull Request

用于提出代码合并请求和进行代码评审。

Issue

用于记录：

• Bug
• 功能需求
• 开发任务
• 技术讨论
• 待办事项

提交信息或 PR 中可以写：

Fixes #123

PR 合并后，GitHub 可以自动关闭编号为123的 Issue。

Actions

GitHub 的自动化平台，常用于：

• 自动运行测试
• 检查代码格式
• 构建项目
• 发布软件
• 部署网站

这一类流程通常称为 CI/CD。

Releases

基于 Git 标签发布正式版本，可以附加：

• 更新说明
• 安装包
• 可执行文件
• 压缩包

Fork

把别人的 GitHub 仓库复制到自己的账号下。

常用于参与自己没有写入权限的开源项目：

原项目 → Fork 到自己的账号 → 修改 → PR 回原项目

GitHub Pages

可以把仓库内容部署为静态网站，适合：

• 个人主页
• 项目文档
• 博客
• 前端演示页面

使用场景

个人开发场景

个人开发虽然没有队友，Git 仍然非常有价值：

• 保存版本历史
• 错误后恢复
• 同时开发多个功能
• 在多台电脑间同步
• 给项目做远程备份
• 自动部署个人网站
• 展示作品和贡献记录

创建本地项目并上传到 GitHub

先在 GitHub 创建一个空仓库，然后在本地执行：

cd my-project git init git add . git commit -m "初始化项目" git branch -M main git remote add origin https://github.com/用户名/my-project.git git push -u origin main

之后的日常流程：

git status git add . git commit -m "添加用户设置页面" git push

场景二：从 GitHub 下载已有项目

git clone https://github.com/用户名/my-project.git cd my-project

修改后：

git status git add . git commit -m "更新项目说明" git push

场景三：开发实验性功能

不要直接破坏稳定版本，可以创建分支：

git switch -c feature/new-editor

完成开发并提交：

git add . git commit -m "添加新版编辑器"

确认没问题后合并：

git switch main git merge feature/new-editor git push git branch -d feature/new-editor

场景四：给项目打版本标签

例如发布v1.0.0：

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

查看标签：

git tag

标签适合标记正式版本，而普通 commit 更像日常开发记录。

场景五：Fork别人的仓库并修改

1.克隆的是「你自己的 Fork 仓库」

在 GitHub 上点击 “Fork” 后，记得要克隆你自己账号下的那个仓库地址，而不是原作者的地址

# 错误示范：克隆了原作者的（你没有权限直接 push） # git clone https://github.com/原作者/项目名.git # 正确示范：克隆你自己的 Fork git clone https://github.com/你的用户名/项目名.git

关联原仓库（Upstream）

原作者后续可能会继续更新代码。为了让你的本地代码能随时拉取原作者的最新改动，强烈建议在本地建立与原仓库的关联（习惯上称原仓库为upstream）：

# 进入项目目录 cd 项目名 # 添加原仓库作为远程源，命名为 upstream git remote add upstream https://github.com/原作者/项目名.git

提示：你可以运行git remote -v查看，现在应该能看到origin（你自己的）和upstream（原作者的）两个网址。

不要直接在main/master分支上修改

如果你打算把改动合并回原仓库，请务必创建一个新的分支（Feature Branch）进行修改。

• 原因：如果你直接在main分支改，当你想提交第二个不同的功能时，你的main分支就变脏了，很难保持独立。

• 正确做法：

  # 创建并切换到一个新分支，比如叫 fix-bug git checkout -b fix-bug # 在这个分支上做修改、commit，然后推送到你自己的 GitHub git push origin fix-bug

定期保持与原仓库同步（Sync）

在修改代码前，或者准备提交修改前，先确保你的代码是最新的，否则容易产生代码冲突（Conflict）。

• 最简单的方法（通过 GitHub 网页）：去你自己的 GitHub Fork 仓库页面，点击“Sync fork”按钮，然后点击“Update branch”。之后在本地运行git pull即可。

• 命令行方法：

  git checkout main git fetch upstream git merge upstream/main

如果想把改动贡献给原作者（提交 Pull Request）

如果你觉得你修改的内容很好，想合并到原作者的官方项目中，这就需要提交Pull Request (PR)：

• 代码规范：尽量遵循原项目的代码风格（缩进、命名规范等）。
• Commit 信息：简明扼要地写清楚你改了什么，为什么这么改。
• 单一职责：一个 PR 只解决一个问题。不要在一个 PR 里既修了 Bug，又重构了界面，还增加了新功能，这样原作者很难审核，大概率会被拒绝。
• 提交 PR：在你的 GitHub 仓库页面，点击“Contribute” -> “Open pull request”，检查一下改动无误后提交，等待原作者审核（Review）。

如果只是想自己魔改（不打算贡献回去）

如果你 Fork 只是为了把这个项目改造成适合自己用的工具，完全不打算提 PR：

• 遵守原项目的开源许可证（License）。有些许可证（如 GPL）要求你修改后的项目如果公开也必须开源。
• 你可以随意在main分支修改，甚至可以把仓库重命名，完全当作自己的独立项目来维护。

团队开发场景

团队开发通常不鼓励所有人直接修改main。更常见的是：

同步 main ↓ 创建个人功能分支 ↓ 开发并提交 ↓ 推送到 GitHub ↓ 创建 Pull Request ↓ 代码评审和自动测试 ↓ 合并到 main

典型团队流程：

1. 克隆团队仓库

git clone https://github.com/company/project.git cd project

2. 同步主分支

git switch main git pull

3. 创建任务分支

git switch -c feature/user-avatar

推荐使用有意义的分支名：

feature/user-login fix/payment-timeout docs/api-guide refactor/order-service test/login-validation

4. 开发并分批提交

git add src/avatar.js git commit -m "添加头像上传接口" git add tests/avatar.test.js git commit -m "添加头像上传测试"

一次提交最好只处理一个相对完整的问题。这样更容易评审和回退。

5. 推送功能分支

git push -u origin feature/user-avatar

6. 创建 Pull Request

在 GitHub 上把：

feature/user-avatar → main

创建为 Pull Request，简称 PR。

PR 的作用包括：

• 描述这次修改
• 关联 Issue
• 让队友评审代码
• 讨论具体代码行
• 自动运行测试
• 获得批准后合并

Pull Request 不是 Git 原生命令，而是 GitHub 提供的协作功能。

7. 根据评审意见继续修改

不需要重新创建 PR。在同一个分支继续提交并推送：

git add . git commit -m "根据评审意见补充文件类型校验" git push

PR 会自动更新。

8. PR 合并后清理分支

git switch main git pull git branch -d feature/user-avatar

远程功能分支通常可以在 GitHub 合并 PR 时删除。

合并冲突是什么

当两个人修改了同一个文件的同一个位置，Git 无法判断保留哪一份，就会产生冲突。

文件可能变成：

<<<<<<< HEAD 本地分支的内容 ======= 另一个分支的内容 >>>>>>> feature/login

处理方法：

1. 阅读双方代码。
2. 手动改成最终需要的内容。
3. 删除冲突标记。
4. 暂存并提交。

git add 冲突文件 git commit

合并冲突不是 Git 出故障，而是 Git 在要求开发者做业务判断。

团队中降低冲突的方法：

• 开发前同步最新main
• 功能分支不要存活太久
• PR 尽量小
• 不要多人同时大规模格式化同一个文件
• 及时交流公共模块的修改

个人开发和团队开发的区别

撤销操作

需要谨慎！！！

撤销尚未暂存的修改

git restore app.py

这会丢弃app.py尚未提交的修改，应谨慎使用。

取消暂存，但保留文件修改

git restore --staged app.py

相当于把文件从暂存区拿回工作区，代码不会消失。

修改最近一次提交

例如忘记添加文件：

git add forgotten-file.py git commit --amend

修改最近一次提交信息：

git commit --amend -m "新的提交信息"

如果提交已经推送给团队，谨慎使用--amend，因为它会改变提交历史。

安全撤销已经共享的提交

git revert 提交编号

revert会创建一个新的反向提交，不会删除历史，因此适合团队共享分支。

临时保存未完成的工作

git stash

恢复：

git stash pop

查看临时记录：

git stash list

stash适合临时切换任务，不应长期代替正常提交。

关于git reset

git reset可以移动分支和修改暂存状态，其中：

git reset --hard

可能直接丢失未提交内容。新手在不清楚后果时不要执行，也不要随意复制网上的“修复命令”。