零基础玩转 Git 与 GitHub：命令行、分支合并、冲突解决、自动化部署实操全攻略

快速摘要
这篇文章是一份面向零基础读者的 Git 与 GitHub 全流程实操指南。 你将在本文中掌握以下核心技能：Git 版本控制的底层原理与四个分区模型、命令行增删改查全流程、分支创建/合并/变基（Rebase）的三种策略对比、多场景冲突解决实操方案，以及 GitHub Actions 自动化 CI/CD 部署的完整配置方法。 无论你是刚入门的编程新手，还是想系统补齐知识盲区的开发者，读完这篇文章都能建立起完整的 Git 工作流认知。往下看有更详细的拆解，每一步都配有命令示例和原理图解。
——莫潇羽@源码七号站（www.fuyuan7.com）

写在前面：为什么 Git 和 GitHub 是开发者的必修课

如果你曾经在电脑上小心翼翼地保存过"论文_第一版""论文_最终版""论文_打死不改版"这样的文件，那么你其实已经在做一件事情了——版本控制。只不过这种纯人工的方式在面对成千上万个文件、数百人协同开发的工程项目时，完全无法胜任。想象一下，十个人同时修改同一份代码，每个人手里都有一份不同时间点的副本，如果没有一套规则来管理这些副本的合并与同步，项目很快就会陷入混乱。

Git 就是为了解决这个问题而诞生的。它是目前世界上使用人数最多的分布式版本控制系统，由 Linux 之父 Linus Torvalds 在 2005 年创建。关于 Git 诞生的背景，有一个广为流传的故事：当年 Linux 内核开发团队使用的版本控制工具 BitKeeper 因为授权纠纷停止了对开源社区的免费支持，Linus 一怒之下花了大约两周时间自己写了一个版本控制系统，这就是 Git。它从一开始就是为大规模分布式协作而设计的，速度快、数据完整性高、对非线性开发流程（即大量并行分支）有着天然的良好支持。

Git 的核心设计理念是"快照"而非"差异"。每一次代码的提交，Git 都会拍下整个项目的完整快照，把所有文件的状态记录下来。如果某个文件没有发生变化，Git 不会重新存储它，而是创建一个指向上一版本的链接——这种设计让 Git 在空间效率和速度之间取得了巧妙的平衡。随着提交的不断积累，这些快照串成一条历史链路，让整个项目的每一处改动都可追溯、可回退。

Git 是一个纯粹的本地工具，它可以在完全没有网络的情况下运行——你在飞机上也能提交代码、查看历史、创建分支。而 GitHub（github.com）则是在 Git 基础上搭建的全球最大的代码仓库托管与协作平台。你可以把本地用 Git 管理的项目上传到 GitHub 的服务器上，实现远端备份、团队协作和开源分享。截至目前，GitHub 上的注册用户已经超过了一亿，仓库数量突破了四亿。Linux 操作系统内核、CPython 解释器、Nginx、TensorFlow 等无数知名开源项目都托管在上面。除了 GitHub 之外，同类平台还有 GitLab、Bitbucket 以及国内的 Gitee（码云）等，它们的操作逻辑与 GitHub 非常相似，学会了 GitHub 就能快速上手其他平台。

GitHub 上绝大部分功能都是免费的，尤其是被微软收购之后，以前一些需要付费的功能（比如创建私有仓库、使用 GitHub Actions 等）也逐渐转为免费提供。这意味着无论你是独立开发者、学生还是小团队，都可以零成本享受到专业级的代码管理和自动化服务。

莫潇羽在运营源码七号站（www.fuyuan7.com）的过程中，几乎每天都在和 Git 打交道，从站点代码的版本管理到自动化部署流水线的搭建，Git 和 GitHub 已经深深嵌入了整个工作流。这篇文章就是我把多年实操经验做了一次系统化的梳理，力求让每一个零基础的朋友都能看得懂、跟得上。文章内容较长，建议先收藏，然后对照着实际操作来学习。

第一章 Git 的核心原理：四个分区与提交链路

在正式上手命令之前，理解 Git 的底层架构至关重要。很多人在操作中犯错，往往不是命令记不住，而是没有搞清楚 Git 内部到底在做什么。

1.1 仓库（Repository）是什么

当你在一个普通的文件夹里执行 git init 命令后，这个文件夹就变成了一个 Git 仓库。变化很微妙——文件夹下会多出一个名为 .git 的隐藏子目录，Git 所有的版本控制信息都存放在这里面，包括提交历史、分支指针、配置信息等。你不需要手动去操作 .git 目录里的内容，但了解它的存在能帮助你理解很多后续概念。

仓库分为两种类型：

• 本地仓库（Local Repository）：运行在你自己电脑上的仓库，所有版本控制操作都在本地完成，速度极快。
• 远端仓库（Remote Repository）：托管在服务器上的仓库，GitHub 就是最常用的远端仓库服务商。除此之外，GitLab、Gitee（码云）等也是常见的选择。

1.2 四个分区模型

Git 的工作流程围绕四个分区展开，弄清楚它们之间的关系，是掌握 Git 的关键：

工作区（Working Directory）
    ↓ git add
暂存区（Staging Area / Index）
    ↓ git commit
本地仓库（Local Repository）
    ↓ git push
远端仓库（Remote Repository）

工作区是你在电脑上实际看到的项目文件夹，你对文件的所有增删改操作都发生在这里。当你觉得某些改动已经准备好了，就用 git add 命令把它们放入暂存区。暂存区像是一个"待提交清单"，你可以精确控制哪些改动要进入下一次提交。执行 git commit 后，暂存区的内容就会被打包成一次提交（commit），永久记录到本地仓库中。最后，通过 git push 把本地仓库的提交同步到远端仓库，比如 GitHub 上的项目。

这四步流程构成了 Git 日常操作的主干脉络，后续所有的分支、合并、冲突解决都是在此基础上展开的。

1.3 提交（Commit）与历史链路

每次执行 git commit，Git 会做几件事情：对暂存区中的所有文件计算校验和，生成一个唯一的提交 ID（一串 40 位的哈希值），同时记录下提交者信息、时间戳和你填写的提交说明（commit message）。更关键的是，每个提交对象内部都包含一个指向上一次提交的指针，这样一来，所有的提交就像链表一样串联起来，形成了一条完整的历史链路。

你可以随时回到历史链路上的任何一个节点，查看当时的项目状态，也可以对比任意两个节点之间的差异——这就是版本控制的核心能力。

第二章 Git 环境搭建与基础配置

2.1 安装 Git

Git 支持 Windows、macOS 和 Linux 三大操作系统。以下是各平台的安装方式：

Windows 平台：访问 Git 官方网站 https://git-scm.com/downloads，下载安装包后一路默认安装即可。安装完成后，在桌面右键菜单中出现"Git Bash Here"选项，说明安装成功。

macOS 平台：打开终端，输入 git --version，如果系统没有预装 Git，会弹出提示引导你安装 Xcode Command Line Tools，按提示操作即可。也可以通过 Homebrew 安装：brew install git。

Linux 平台（以 Ubuntu 为例）：

sudo apt update
sudo apt install git

安装完成后，验证一下版本：

git --version
# 输出类似：git version 2.43.0

2.2 初始化配置

Git 安装好后，第一件事是告诉它你是谁。这些信息会出现在你的每一次提交记录中：

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

这里的 --global 表示全局配置，对你电脑上所有的 Git 仓库生效。如果某个项目需要使用不同的身份信息，可以在该项目目录下去掉 --global 单独配置。

查看当前的配置信息：

git config --list

2.3 注册 GitHub 账号与双重身份验证

访问 https://github.com，点击右上角的 Sign up，按步骤填写邮箱、密码和用户名即可完成注册。这里有一点需要特别注意——用户名（username）一定要认真起，因为你以后所有仓库的 URL 都会包含这个用户名，格式为 github.com/你的用户名/仓库名。

注册完成后，莫潇羽强烈建议你立即配置双重身份验证（2FA）。在 GitHub 的 Settings → Password and authentication 页面中开启此功能，然后使用 Microsoft Authenticator 或其他身份验证器 App 扫描二维码绑定。开启 2FA 后，登录时除了密码还需要输入动态验证码，能极大提升账号安全性。

配置过程中系统会提供一组恢复码（Recovery Codes），这些恢复码是你手机丢失后重新登录的唯一凭证，务必下载并妥善保管，建议多备份几份到网盘或U盘中。

2.4 GitHub 仓库页面详解

在 GitHub 上，代码仓库（Repository）是最核心的功能单元。理解仓库页面的布局和各个模块的用途，能让你更高效地使用 GitHub。

每个仓库的 URL 结构都遵循统一规则：github.com/用户名/仓库名。进入一个仓库后，你会看到以下几个关键区域：

代码区域（Code）：页面正中央展示的是项目的文件列表，你可以直接点击浏览任何文件的内容。每个文件后面会显示最后一次修改它的提交信息和时间——如果一个项目所有文件的最后更新时间都是好几年前，那很可能意味着这个项目已经停止维护了。

README 文件：代码区域的下方会自动渲染仓库根目录中的 README.md 文件。这是项目的"门面"，通常包含项目的功能介绍、使用说明、安装步骤等信息。一个好的 README 文件就像一份详细的产品说明书，它是其他人了解你项目的第一个入口。README 文件使用 Markdown 语法编写，这是一种非常简洁的标记语言，上手成本很低。

Issues（议题）：你可以在这里报告 bug、提出功能建议、或者参与讨论。Issues 分为 Open（待处理）和 Closed（已解决）两种状态。在使用或学习开源项目的时候，如果遇到问题不妨先在 Issues 中搜索一下，很多时候你遇到的问题别人也遇到过，而且已经有了解决方案。

Pull Requests（合并请求）：简称 PR，这是 GitHub 协作的核心机制。当你想把自己分支上的代码合并到另一个分支（或者另一个仓库）时，就需要创建一个 PR。项目维护者可以在 PR 中审查代码、留下评论、要求修改，直到代码质量满意后再执行合并操作。

Releases（发布版本）：这里展示项目的正式发布版本，每个 Release 通常对应一个 Git Tag，包含版本号、更新日志和预编译好的安装包。用户可以直接在这里下载到可以使用的软件。

Star 和 Fork：Star 类似于"点赞 + 收藏"，Star 数量是衡量一个开源项目热度的重要指标。Fork 是"复刻"，将别人的项目完整复制一份到你自己的名下，你可以在自己的副本上自由修改，然后通过 PR 将你的改动贡献回原项目。

第三章 Git 命令行操作全流程实战

图形化工具虽然直观，但命令行才是 Git 的灵魂。掌握了命令行，你就真正拥有了对版本控制的完全掌控力。这一章我们从创建仓库开始，一步步走完整个操作流程。

3.1 创建仓库

有两种方式创建 Git 仓库：

方式一：在本地初始化一个全新仓库

mkdir my-project
cd my-project
git init

执行 git init 后，当前目录就变成了一个 Git 仓库，会生成 .git 隐藏文件夹。

方式二：从 GitHub 克隆一个已有仓库

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

克隆操作会把远端仓库完整地下载到本地，包括所有历史记录和分支信息。

3.2 日常操作三板斧：add → commit → push

假设你在项目中新建了一个文件 index.html，下面是把它提交到远端的完整流程：

# 查看当前仓库状态（哪些文件被修改了、哪些在暂存区）
git status

# 将文件添加到暂存区
git add index.html
# 或者一次性添加所有改动
git add .

# 将暂存区的内容提交到本地仓库
git commit -m "添加首页文件"

# 将本地仓库的提交推送到远端
git push origin main

这里的 origin 是远端仓库的默认别名，main 是分支名称。如果你的默认分支叫 master，就把 main 替换成 master。

3.3 从远端拉取更新：fetch 与 pull

在团队协作中，别人可能已经往远端仓库推送了新的代码，你需要把这些更新同步到本地。

# 方式一：先获取再合并（更安全，推荐）
git fetch origin
git merge origin/main

# 方式二：一步到位（fetch + merge 的简写）
git pull origin main

git fetch 只是把远端的最新数据下载到本地，但不会自动修改你正在编辑的文件。而 git pull 则在获取更新后自动执行合并操作。如果远端和本地修改了同一个文件的同一行，合并时就会产生冲突——关于冲突解决，我们在后面会详细讲到。

3.4 查看提交历史

# 查看完整的提交历史
git log

# 简洁模式，每个提交只显示一行
git log --oneline

# 查看最近 5 次提交
git log -5

# 图形化显示分支合并情况
git log --oneline --graph --all

git log 是调试和回溯问题的利器。当你需要找到某个 bug 是什么时候引入的，或者想回到某个历史版本，提交历史就是你的线索。

3.5 比较差异

# 查看工作区与暂存区的差异
git diff

# 查看暂存区与最近一次提交的差异
git diff --cached

# 查看两个分支之间的差异
git diff main feature-branch

第四章 分支管理：从创建到合并的完整攻略

分支是 Git 最强大的功能之一。它允许你在不影响主干代码的情况下，开辟一个独立的开发空间。功能开发完毕后，再把分支合并回主干。

4.1 什么是分支

在 Git 的内部实现中，分支其实只是一个指向某个提交的可移动指针。创建一个新分支，Git 只需要新建一个指针，开销极小、速度极快。HEAD 是一个特殊的指针，它指向你当前所在的分支，告诉 Git 你的下一次提交应该附加在哪条线上。

4.2 分支操作命令

# 查看所有本地分支
git branch

# 查看所有分支（包括远端）
git branch -a

# 创建新分支
git branch feature-login

# 切换到指定分支
git switch feature-login
# 或者使用旧语法
git checkout feature-login

# 创建并切换（一步完成）
git switch -c feature-login
# 或者
git checkout -b feature-login

# 删除本地分支
git branch -d feature-login

# 强制删除（分支未合并时使用）
git branch -D feature-login

# 删除远端分支
git push origin --delete feature-login

4.3 三种合并策略深度对比

当功能分支开发完毕，需要把代码合并回主干分支时，Git 提供了三种不同的合并策略。选哪一种，直接影响你的提交历史长什么样。莫潇羽@源码七号站在实际项目中三种都用过，下面结合原理逐一分析。

策略一：普通合并（Merge）

这是最常用也最安全的合并方式。假设你要把 feature 分支合并到 main 分支：

git switch main
git merge feature

Git 会找到两个分支的最近共同祖先，然后把 feature 分支上的所有提交与 main 分支的最新提交做一次三方合并，并自动生成一个新的"合并提交"（merge commit）。这个合并提交有两个父节点，分别指向合并前两个分支的最新提交。

优点：所有的历史记录都完整保留，包括清晰的合并节点，方便回溯。

缺点：如果项目分支很多，合并提交会让提交历史看起来比较复杂。

适用场景：多人协作的集成分支，比如将功能分支合并到 main 或 develop 分支时，必须使用普通合并。

策略二：压缩合并（Squash Merge）

git switch main
git merge --squash feature
git commit -m "完成登录功能"

Squash 的英文含义是"挤压、压缩"。这个命令会把 feature 分支上的所有提交压缩成一个提交，然后合并进 main 分支。原来 feature 分支上可能有十几个零碎的提交，合并后在 main 上只会看到一条干净的记录。

优点：提交历史非常清爽，一个功能对应一个提交。

缺点：原始分支上的详细提交记录丢失了，不太好追溯每一步的开发过程。

适用场景：功能分支上的提交比较零散（比如"修了个 typo""调了下样式"这类），合并