企业官网建设流程全解析

easy-vibe Git 版本控制实战指南：从零掌握本地提交、分支管理与 GitHub 协作

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

本文是 easy-vibe 课程体系"附录：系统化知识全景"中开发工具篇的核心章节，面向从未接触过 Git 的初学者。我们不急着让你背命令，而是先讲清楚"Git 到底帮你解决了什么问题"，再把命令与概念逐步挂钩。学完本文，你将能独立完成：本地提交（commit）、创建分支（branch）并推送到 GitHub（push），具备加入任何团队项目的版本控制基本功。

0. 先问一个问题：这些噩梦你经历过吗

场景一：版本地狱

写论文或写代码到一半，发现写错了，想回到三天前的版本——但那个版本已经找不到了。

Projekt_v1.zip Projekt_v2_bearbeitet.zip Projekt_v3_final.zip Projekt_v3_final_wirklich_final.zip Projekt_v3_final_echt_letztmalig.zip

每存一个新副本，硬盘就变得更乱，而且你根本记不清哪个版本改了什么东西。

场景二：协作噩梦

你和同事同时改同一个文件：

• 你改了第 10 行，加了一个登录功能；
• 同事也改了第 10 行，修了一个 Bug；
• 你们通过邮件互相传代码，合并时一方的改动覆盖了另一方；
• 最后没人知道哪个版本是对的。

场景三：没有"后悔药"

你把新代码部署到了生产环境，结果出现 Bug。你想立刻回滚到上一个稳定版本——却不知道怎么回滚，只能手忙脚乱地找备份。

Git 正是为了解决这三个问题而生的。

Git 是一种版本控制系统（Version Control System）。它的本质是：把你每一次"保存"操作都记录下来，形成一条完整的历史时间线，让你随时可以回到任意一个历史节点。

毫不夸张地说，Git 是现代软件开发中最重要的工具之一。几乎所有公司和所有开源项目都在使用它。

1. 先分清概念：Git 与 GitHub 不是一回事

很多初学者会把这两个概念混为一谈，先来理清：

一句话总结：Git 是工具，GitHub 是托管服务。就像 Word 是工具、OneDrive 是云端一样——两者配合使用，但不是同一个东西。

除了 GitHub，类似的托管服务还有 GitLab、Gitee（国内）等。

2. 核心概念：三大区域

这是 Git 全身上下最重要的设计。理解这三个区域，你就理解了 Git 的灵魂。

Git 把文件状态分成三个层次：

工作目录（Working Directory）

这就是你的普通文件夹。你现在看到、正在编辑的所有文件都在这里。你可以随意修改——Git 能感知到你的改动，但不会做任何记录。

暂存区（Staging Area / Index）

这是一个**"提交前的临时中转站"**。你可以把工作目录里想保存的文件"放进"暂存区——就像把包裹放进寄件箱：还没寄出去，但已经挑好了要寄什么。

仓库（Repository）

这是永久保存的历史档案库，藏在.git文件夹里。每当你执行git commit，暂存区的内容就会被封存进仓库，形成一条不可变的历史记录。

在原文档页面中，这一节配有<GitCommitFlow />交互组件：依次点击命令按钮，就能直观地看到文件如何在三个区域之间流转。该组件是 easy-vibe 文档体系中内置的 VitePress 交互演示（见 AGENTS.md 中关于附录页内交互 Vue 组件的说明），本地运行npm run dev后即可在对应页面实际操作体验。

为什么是"两步走"（add + commit）

很多初学者会问：为什么不一键保存，非要先add再commit？

因为在真实开发中，你往往并不想一次提交所有改动。

举例：你今天改了 5 个文件——

• login.js：登录功能写完了（想提交）
• style.css：登录页样式调好了（想提交）
• debug.log：临时调试输出（不想提交）
• experiment.js：新功能还在试，没写完（不想提交）
• todo.txt：你的个人笔记（不想提交）

没有暂存区的话，你要么把 5 个文件全部提交（历史一团乱），要么一个都不提交。

有了暂存区，你可以精确控制：git add login.js style.css只把这两个文件放进寄件箱，然后commit，这条提交就清晰地记录了"登录功能完成"。

3. 第一次使用 Git：初始化与基础工作流

3.1 安装与初始化

macOS 通常自带 Git；Windows 需要从 git-scm.com 下载安装包。如果你需要更系统的安装指引，easy-vibe 的Git 实战篇提供了 Windows（官方安装包 + Git Bash）、macOS（Homebrew 的brew install git或 Xcode 自带）、Linux（Ubuntu/Debian 的sudo apt install git、CentOS/RHEL 的sudo yum install git）三种方式的完整说明，安装完成后用git --version验证。

装好后打开终端，进入你的项目文件夹：

# 在当前目录初始化一个 Git 仓库 git init # Git 会创建一个隐藏的 .git 文件夹，所有历史都存放在里面 # 输出：Initialized empty Git repository in .../your-project/.git/

首次使用，还要告诉 Git 你是谁（这条信息会附加到每一次提交上）：

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

--global表示全局生效，一次配置，本机所有仓库通用。Git 会把这些信息作为"作者信息"嵌入每条提交记录中——当你用git log查看历史时，能清楚地看到哪行代码是谁改的，这在协作项目中尤其重要。可用git config --list查看当前全部配置，确认设置成功。

3.2 日常工作流：三步保存法

初始化之后，日常开发 90% 的工作就是重复这三步：

第 1 步：查看状态

git status

这是使用频率最高的命令。它会告诉你：

• 当前在哪个分支上；
• 哪些文件被修改了（红色 = 尚未暂存）；
• 哪些文件在暂存区里（绿色 = 已暂存，等待提交）。

第 2 步：把文件放入暂存区

# 添加单个文件 git add login.js # 添加多个文件 git add login.js style.css # 添加当前目录下所有改动的文件（. 表示"全部"） git add .

⚠️ 常见新手坑：git add .很方便，但会把所有改动都加进来，包括你并不想提交的临时文件。请养成精确 add 的习惯，或用.gitignore排除不想跟踪的文件（后面会讲）。

第 3 步：提交并写描述

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

-m后面引号里的文字叫Commit Message（提交说明）。这是写给未来的自己和同事看的——请务必写清楚。

3.3 如何写专业的 Commit Message

# ❌ 无意义写法——看不出做了什么 git commit -m "update" git commit -m "fix" git commit -m "改了一些东西" # ✅ 好的写法：类型 + 冒号 + 一句话描述 git commit -m "feat: 添加用户登录功能" git commit -m "fix: 修复 iOS Safari 首页白屏问题" git commit -m "docs: 更新 README 中的部署说明" git commit -m "refactor: 将 UserService 拆分为独立模块" git commit -m "style: 统一代码缩进为 2 个空格"

常见前缀含义：

养成这个习惯，几个月后回看历史，一眼就能看出每条提交做了什么——这在团队协作中尤其重要。

这一规范在 easy-vibe 仓库中有直接的实践佐证：仓库根目录的 AGENTS.md（Commit & Pull Request Guidelines 一节）明确约定"提交遵循历史中可见的 Conventional Commits 风格：feat: ...、fix: ...、docs: ...（可选带 scope，如feat(docs): ...）"，并要求 PR 附带简短描述、UI/组件变更的截图/GIF 以及涉及的路径。也就是说，本文讲的这套规范正是该仓库自身实际使用的提交风格。

3.4 查看历史

# 详细格式（每条提交的完整信息） git log # 紧凑格式（每条提交一行，日常使用推荐） git log --oneline # 示例输出： # a1b2c3d (HEAD -> main) feat: 添加用户登录功能 # 9f3e1b2 init: 初始化项目

--oneline输出的每一行，前半段是提交哈希（如a1b2c3d），括号里是当前分支位置标记（HEAD），后半段就是提交说明。

4. 并行宇宙：分支（Branch）

分支是 Git 最强大、也最容易让初学者困惑的功能。一旦理解，你会发现这个设计非常优雅。

4.1 用"存档拷贝"理解分支

想象你在玩一个角色扮演游戏，面临关键抉择：

• 选择 A：去挑战大 Boss（开发新功能）
• 选择 B：维持现状、稳步发育（主线保持不变）

如果你直接在主存档里选 A 并且失败了，整个游戏进度就毁了。

但如果你复制一份存档，在副本里去挑战 Boss：

• 赢了？把副本的成果合并回主存档；
• 输了？主存档毫发无损——删掉副本重来。

Git 分支就是这套"存档拷贝"机制。

在 Git 中，main（或master）分支就是你的"主存档"，必须始终稳定可用。要开发新功能时，从 main 拉出一个新分支，在分支上开发、测试，完成后合并回 main。

原文档页面中的<GitBranchVisual />交互组件可以让你点击命令按钮，观察分支图如何分叉、生长、最终合并——请特别留意 HEAD 标签的位置，它始终指向"你现在所在的位置"。

4.2 分支操作详解

创建并切换新分支：

# 方法一：先创建，再切换（两步） git branch feature-login # 创建分支 git checkout feature-login # 切换过去 # 方法二：一步到位（推荐） git checkout -b feature-login # 输出：Switched to a new branch 'feature-login'

创建分支后，命令提示符会显示当前分支名，例如：

user@mac ~/project (feature-login) $

查看所有分支：

git branch # 输出（* 标记当前所在分支）： # * feature-login # main

在分支上正常开发：

# 在 feature-login 分支上：改代码、add、commit，和平时一模一样 git add login.js git commit -m "feat: 添加登录表单的 HTML 结构" git add login.js api.js git commit -m "feat: 完成登录 API 对接"

这些提交只存在于feature-login分支上——main分支对此一无所知。

切回主分支并合并：

# 切回 main git checkout main # 把 feature-login 的所有改动合并进来 git merge feature-login # 合并完成后可以删除该分支（可选） git branch -d feature-login

4.3 什么时候该建分支

4.4 团队常见的分支策略

在真实项目中，团队通常会约定分支的命名与用途：

5. 与同事协作：远程仓库

到目前为止你学的都是本地Git 操作——所有历史只存在你自己的电脑上。要跟同事共享代码，你需要一个远程仓库（Remote Repository），也就是 GitHub、GitLab 这类云端存储。

5.1 远程仓库的工作原理

把远程仓库理解为团队的**"共享存档"**：

• 每个人在本地写代码、提交；
• 完成后用push（上传）更新远程仓库；
• 同事用pull（下载）把最新内容拉到自己本地；
• 大家的代码就这样保持同步。

原文档页面中的<GitSyncDemo />交互组件可以带你体验从关联远程仓库、push，到 pull 同事更新的完整过程。

5.2 首次把项目推送到 GitHub

第 1 步：在 GitHub 上新建一个仓库（右上角 + → New repository），不要勾选任何初始化选项（README、.gitignore、license 都先不勾）。

第 2 步：回到本地终端，关联远程仓库：

# 将本地仓库与 GitHub 仓库关联 # "origin" 是远程仓库的别名，是约定俗成的名字（可以改，但没必要） git remote add origin https://github.com/用户名/仓库名.git # 确认关联成功 git remote -v # 输出： # origin https://github.com/用户名/仓库名.git (fetch) # origin https://github.com/用户名/仓库名.git (push)

第 3 步：把本地内容推送到远程：

# 首次推送；-u 表示"以后 git push 默认推到 origin 的 main 分支" git push -u origin main # 之后每次推送只需： git push

5.3 日常协作命令

推送（你改了东西，想让同事看到）：

git push

拉取（同事改了东西，你需要同步）：

git pull

git pull实际上是两条命令的组合：

1. git fetch：从远程仓库下载最新的提交记录；
2. git merge：把下载的内容合并到当前分支。

首次从 GitHub 获取别人的项目：

# 把整个远程仓库完整拷贝到本地（只需做一次） git clone https://github.com/某人/某个项目.git # clone 会自动建立远程关联，之后直接 push/pull 即可

5.4 push 和 pull 的方向

你的电脑（本地仓库） ←→ GitHub（远程仓库） git push: 本地 → 远程 （你改了东西，上传给同事） git pull: 远程 → 本地 （同事改了东西，下载到你这里） git clone: 远程 → 本地 （首次完整拷贝整个仓库）

最佳实践：每天开工前先git pull拿到最新代码；下班前或完成一个功能后git push，及时备份并让同事看到你的进度。

5.5 免密认证：SSH 密钥

用 HTTPS 地址推送时每次都要输用户名密码（或 Personal Access Token），比较繁琐。easy-vibe 的SSH 认证详解和Git 实战篇给出了完整的免密方案，核心流程是：

# 1. 生成密钥对（-t 指定算法 ed25519，-C 填注册邮箱） ssh-keygen -t ed25519 -C "your@email.com" # 一路回车接受默认路径 ~/.ssh/id_ed25519；私钥永不外传，公钥 id_ed25519.pub 上传到 GitHub # 2. 把公钥内容添加到 GitHub：Settings → SSH and GPG keys → New SSH key # 3. 验证是否绑定成功 ssh -T git@github.com # 成功会看到：Hi 用户名! You've successfully authenticated... # 4. 之后改用 SSH 格式地址操作仓库 git remote set-url origin git@github.com:用户名/仓库名.git

原理上，SSH 认证基于非对称加密的密钥对：本地用私钥签名"操作请求"，GitHub 用你绑定的公钥验证——私钥从不传输，因此比密码更安全也更省事。需要注意：每台设备都要生成独立的密钥对并分别绑定；私钥一旦泄露，应立即在 GitHub 删除对应公钥并重新生成。

6. 进阶：解决冲突

冲突在协作中不可避免，但并不可怕。

6.1 冲突是怎么产生的

当你和同事同时修改了同一文件的同一行时，Git 在合并时不知道该用谁的版本，于是产生冲突。

举例：

• 你在login.js第 5 行写了：const timeout = 3000
• 同事同时在同一行写了：const timeout = 5000
• 当你执行git pull或git merge时，Git 发现这个矛盾，于是"暂停"下来告诉你：我无法决定——需要你来选择。

6.2 冲突文件长什么样

Git 会在冲突位置插入特殊标记：

function login() { const url = '/api/login' <<<<<<< HEAD const timeout = 3000 // 你的版本 ======= const timeout = 5000 // 同事的版本 >>>>>>> feature/update-timeout return fetch(url, { timeout }) }

• <<<<<<< HEAD与=======之间：你当前分支的内容；
• =======与>>>>>>> xxx之间：要被合并进来的内容。

6.3 如何解决冲突

第 1 步：打开冲突文件，找到所有<<<<<<<标记（VS Code 等编辑器通常会自动高亮这些标记）。

第 2 步：决定保留哪段代码，手动编辑文件，删掉所有标记符号（<<<<<<<、=======、>>>>>>>）。

例如，决定采用 5000（同事的版本）：

function login() { const url = '/api/login' const timeout = 5000 // 采纳同事的改动 return fetch(url, { timeout }) }

第 3 步：重新提交

# 将冲突标记为已解决 git add login.js # 完成合并提交（Git 会自动生成合并提交信息） git commit

6.4 减少冲突的好习惯

• 勤拉取：开工前先同步最新代码，避免"落后太多"；
• 小步提交：不要攒一周的代码一次提交，频繁的小提交更容易定位和解决冲突；
• 分支隔离：不同功能用不同分支，减少同一行代码的竞争；
• 及时沟通：改动共享文件（如config.js）之前，先跟同事打声招呼。

7. 命令速查表

原文档页面的<GitCommandCheatsheet />交互组件以分类速查卡片的形式呈现下列命令，这里整理成可随时查阅的表格：

8. 实战：加入团队项目的完整流程

这是你加入一个新团队或新项目时的标准流程——可以直接照抄：

# ① 第一天：把项目克隆到本地（仅一次） git clone https://github.com/team/project.git cd project # ② 每天开工：先拉取最新代码 git pull origin main # ③ 创建自己的功能分支（不要直接在 main 上改！） git checkout -b feature/user-profile # ④ 正常开发...写代码... # ⑤ 完成一个小功能点后立刻提交（不要攒着） git add src/UserProfile.vue git commit -m "feat: 完成用户头像上传功能" git add src/UserProfile.vue src/api/user.js git commit -m "feat: 完成用户资料编辑 API 对接" # ⑥ 把自己的分支推送到远程，让同事能看到 git push origin feature/user-profile # ⑦ 在 GitHub 上创建 Pull Request（PR），申请合并进 main # （这一步在 GitHub 网页上操作） # ⑧ 等待同事 Code Review，按反馈修改后继续 commit + push # ⑨ PR 合并后，切回 main、本地更新、删除功能分支 git checkout main git pull git branch -d feature/user-profile

关于第 ⑦ 步的 PR 规范，easy-vibe 仓库本身就是很好的范本：AGENTS.md 约定 PR 应包含：简短描述、UI 或组件变更的截图/GIF、以及涉及的路径（如docs/zh-cn/appendix/...、docs/.vitepress/theme/...）。这套流程（提交规范 + 分支隔离 + 代码评审）正是现代团队协作的标准形态。

9. .gitignore：哪些文件不该被跟踪

有些文件不应该提交进 Git 仓库：

• node_modules/：依赖包，体积巨大，npm install即可重新生成；
• .env：环境变量文件，可能包含数据库密码、API Key——绝不能上传到公开仓库；
• *.log：日志文件；
• .DS_Store：macOS 自动生成的隐藏文件；
• dist/、build/：构建产物，可以重新生成。

在项目根目录创建.gitignore文件，把不想跟踪的规则写进去：

# 依赖 node_modules/ # 环境变量（重要！密码绝不能提交） .env .env.local # 构建产物 dist/ build/ # 系统文件 .DS_Store Thumbs.db # 日志 *.log

GitHub 官方提供覆盖各语言与框架的 .gitignore 模板库，创建仓库时可直接选用对应模板（在 New repository 页面勾选 Add .gitignore 并从下拉列表中选择），也可以在对应模板项目中检索适合自己技术栈的规则。

10. 术语表

11. 在 easy-vibe 中继续深入

本文定位是"原理 + 核心命令"；当你准备真正动手，建议接着阅读以下仓库内文档：

• Git 实战篇：Git 与 GitHub 使用入门——多平台安装、GitHub 账号注册、首次创建远程仓库、SSH 绑定、以及在 AI IDE（Trae）中用自然语言完成 clone / pull / commit / push 的实操全流程，是本文的实战延续；
• SSH 认证：安全通信——密钥对原理、ssh-keygen参数、SSH Config 别名与常见问题排查；
• 命令行与 Shell：基础——Git 全部操作都发生在终端里，掌握ls、cd、mkdir等基础命令是前提；
• 附录首页——easy-vibe 的完整知识库索引，可以按需查阅网络、数据库、部署等其他主题。

版本控制能力是 AI 原生开发者（vibe coding）的基本功：无论你用 AI 生成了多少代码，最终都要靠 Git 来管理版本、隔离实验、回归历史与团队协作。把本文的命令练熟，再结合实战篇完成一次完整的"克隆 → 建分支 → 提交 → 推送 → PR"流程，你就正式具备了现代开发者的协作基础设施。

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe