all posts
AI技术 · ZH

Git 和 GitHub 完整入门教程——从零开始掌握版本控制

May 8, 2026·23 min read·by PandaTalk

Git 和 GitHub 完整入门教程——从零开始掌握版本控制

如果你曾经写过论文、做过方案、写过代码,大概率经历过这样的场景:

报告_v1.docx
报告_v2.docx
报告_v2_修改版.docx
报告_v2_修改版_最终版.docx
报告_v2_修改版_最终版_真的最终版.docx

你知道这种方式很蠢,但你不知道更好的方案。

Git 就是那个更好的方案。它是一套版本控制系统,帮你精确地记录每一次修改:谁改的、改了什么、为什么改。而 GitHub 是基于 Git 的在线协作平台,让你可以把代码存在云端,和全世界的人一起协作。

这篇文章从零开始,带你理解 Git 的核心概念,学会 GitHub 的基本操作,最终能够独立管理自己的项目。

第一部分:理解 Git

Git 是什么

Git 是一个分布式版本控制系统(Distributed Version Control System)。这个名字很长,我们拆开理解:

版本控制——自动帮你管理文件的每一个历史版本。你不再需要手动复制文件、手动命名"v1""v2",Git 会帮你记录每一次变更的完整快照。

分布式——每个人的电脑上都有项目的完整历史记录。即使服务器挂了,任何一个人的电脑上都有完整的备份。这和早期的集中式版本控制系统(如 SVN)不同,后者所有历史记录只存在中央服务器上。

Git 由 Linus Torvalds 在 2005 年创建,就是创建 Linux 操作系统的那个人。他当时需要一个工具来管理 Linux 内核的开发,市面上的工具都不满意,于是自己写了一个。如今 Git 已经成为软件开发领域的标准工具,几乎所有的开源项目和商业项目都在使用它。

为什么要学 Git

即使你不是程序员,Git 也值得学,理由有三:

  1. 不再丢失任何工作成果。 Git 记录了项目的完整历史,你随时可以回到任何一个历史版本。误删了一段代码?改错了一个文件?执行一条命令就能恢复。

  2. 多人协作不再混乱。 没有 Git 的时候,团队协作靠的是"我改完了发给你,你改完了再发给我"。Git 让每个人可以独立工作,最后把各自的成果智能合并。

  3. 它是进入技术世界的基础设施。 如果你想参与任何开源项目、想在技术公司工作、想和开发者协作,Git 是必备技能,就像文字工作者必须会用 Word 一样。

Git 的核心概念

Git 的设计有一套精密的概念体系,理解这些概念后,所有的命令都只是实现手段。

仓库(Repository)

一个 Git 仓库就是一个被 Git 管理的文件夹。当你在一个文件夹里执行 git init 命令后,这个文件夹就变成了一个 Git 仓库。Git 会在其中创建一个隐藏的 .git 目录,用来存储所有的版本历史。

提交(Commit)

提交是 Git 中最核心的概念。每一次提交就是一次快照——它记录了在那个时间点,所有被追踪文件的状态。你可以把它想象成游戏中的"存档":随时可以保存进度,也随时可以读取任何一个存档。

每个提交包含以下信息:

  • 文件的变更内容(改了哪些文件,具体改了什么)
  • 提交者(谁做的这次修改)
  • 时间戳(什么时候提交的)
  • 提交信息(一段说明文字,解释这次改动的目的)
  • 父提交的引用(这次提交是基于哪个版本做的修改)

这些提交按照时间顺序串联起来,形成一条完整的历史链。

暂存区(Staging Area)

Git 有一个独特的设计:修改文件后,这些修改不会自动被记录。你需要先把修改"暂存"起来,然后再统一提交。

为什么要多这一步?因为你一次可能修改了很多文件,但这些修改可能属于不同的逻辑。暂存区让你可以精确控制每次提交包含哪些修改,保持每个提交都有清晰的目的。

打个比方:你在搬家,暂存区就像一个打包区。你从各个房间收集物品放到打包区(git add),整理好后再封箱发走(git commit)。每个箱子(提交)里的东西应该是同一类的,而不是把厨房用品和书籍混在一起。

所以,Git 中的文件有三种状态:

  • 已修改(Modified)——文件被改了,但还没暂存
  • 已暂存(Staged)——文件的修改已被标记,等待下一次提交
  • 已提交(Committed)——文件的修改已被安全地记录到版本历史中

分支(Branch)

分支是 Git 最强大的功能之一。想象你正在写一篇文章,写到一半时突然有一个新的想法,但你不确定这个想法行不行。你可以创建一个分支,在分支上实验,如果成功了就合并回来,如果失败了就丢弃这个分支,原来的内容不受任何影响。

在团队协作中,分支的作用更加明显。每个人可以在自己的分支上独立开发不同的功能,互不干扰。开发完成后,再把各自的分支合并到主线上。

默认的主分支通常叫做 main(或 master),它代表项目的正式版本。

第二部分:安装和配置 Git

安装 Git

macOS

打开终端(Terminal),输入:

git --version

如果系统已经安装了 Git,会显示版本号。如果没有,macOS 会提示你安装 Xcode Command Line Tools,按提示操作即可。

你也可以通过 Homebrew 安装:

brew install git

Windows

访问 Git 官网(git-scm.com),下载 Windows 安装包。安装过程中,所有选项保持默认即可。安装完成后,你会得到一个叫"Git Bash"的程序,所有 Git 命令都在这里执行。

Linux

以 Ubuntu 为例:

sudo apt update
sudo apt install git

初始配置

安装完成后,你需要告诉 Git 你是谁。这些信息会出现在你的每一次提交中。

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

这里的邮箱建议使用你 GitHub 账号绑定的邮箱,这样提交记录才能正确关联到你的 GitHub 账号。

验证配置是否成功:

git config --list

第三部分:Git 基础操作

创建你的第一个仓库

打开终端,创建一个新文件夹并进入:

mkdir my-first-repo
cd my-first-repo

初始化 Git 仓库:

git init

终端会显示类似这样的信息:

Initialized empty Git repository in /path/to/my-first-repo/.git/

现在这个文件夹已经是一个 Git 仓库了。

第一次提交

创建一个文件:

echo "Hello, Git!" > hello.txt

查看仓库状态:

git status

Git 会告诉你有一个未追踪的新文件 hello.txt

将文件添加到暂存区:

git add hello.txt

提交:

git commit -m "添加 hello.txt 文件"

-m 后面的引号里是提交信息,用来说明这次提交做了什么。写清楚提交信息是一个好习惯——当你几个月后回来翻历史的时候,清晰的提交信息能帮你快速理解每次改动的目的。

常用命令速查

以下是日常使用中最高频的 Git 命令:

命令 作用
git status 查看当前仓库状态(哪些文件被修改、暂存等)
git add 文件名 将指定文件的修改添加到暂存区
git add . 将所有修改添加到暂存区
git commit -m "信息" 将暂存区的内容提交,附带说明信息
git log 查看提交历史
git log --oneline 查看简洁的提交历史(每个提交一行)
git diff 查看已修改但未暂存的变更内容
git checkout -- 文件名 撤销对某个文件的修改(恢复到上次提交的状态)

练习:完整的工作流程

我们来走一遍完整的日常工作流程。

  1. 修改文件:
echo "这是第二行内容" >> hello.txt
  1. 查看变更:
git diff

Git 会用绿色标记新增的内容,用红色标记删除的内容。

  1. 查看状态:
git status

显示 hello.txt 已被修改,但还没暂存。

  1. 暂存修改:
git add hello.txt
  1. 提交:
git commit -m "在 hello.txt 中添加第二行内容"
  1. 查看历史:
git log --oneline

你会看到两条提交记录,每条前面有一个简短的哈希值(类似 a1b2c3d),这是这个提交的唯一标识。

分支操作

创建并切换到新分支:

git checkout -b feature-new-idea

这条命令做了两件事:创建名为 feature-new-idea 的分支,并切换到这个分支上。

在新分支上做一些修改并提交:

echo "这是一个实验性的想法" > experiment.txt
git add experiment.txt
git commit -m "添加实验性内容"

切换回主分支:

git checkout main

你会发现 experiment.txt 不见了——因为它只存在于 feature-new-idea 分支。

如果你对实验结果满意,可以把分支合并回来:

git merge feature-new-idea

现在 experiment.txt 也出现在主分支上了。

第四部分:理解 GitHub

GitHub 是什么

Git 是一个本地工具,它在你自己的电脑上运行。GitHub 是一个基于 Git 的在线平台,提供了三个核心价值:

  1. 远程备份。 把代码存在云端,电脑坏了也不怕丢失。
  2. 协作。 多人可以在同一个项目上工作,GitHub 提供了一整套协作工具(Pull Request、Issue、Code Review 等)。
  3. 开源社区。 GitHub 是全球最大的开源项目托管平台,你可以在上面找到几乎所有重要的开源项目,也可以贡献自己的代码。

一个简单的类比:Git 好比笔和纸,GitHub 好比图书馆。你用 Git 写作和管理修改记录,用 GitHub 把作品发布出去、和他人协作。

市面上还有 GitLab、Bitbucket 等类似平台,但 GitHub 是使用最广泛的。

注册 GitHub 账号

访问 github.com,点击右上角的"Sign Up"注册。流程很简单:填写用户名、邮箱、密码,完成验证即可。

用户名建议选择一个简洁、专业的名字——它会出现在你所有项目的 URL 中,相当于你的技术身份标识。

GitHub 界面导览

登录后,你会看到几个关键区域:

个人主页(Profile)——展示你的个人信息、仓库列表、贡献活动。它相当于你的技术名片。

仓库(Repository)——你的每个项目对应一个仓库。仓库页面展示文件列表、提交历史、分支、Issue、Pull Request 等。

探索(Explore)——发现热门项目和开发者。

第五部分:GitHub 实战操作

创建远程仓库

在 GitHub 上创建一个新仓库:

  1. 点击页面右上角的"+"号,选择"New repository"
  2. 填写仓库名称(比如 my-first-repo
  3. 选择 Public(公开)或 Private(私有)
  4. 暂时不要勾选"Add a README file"等选项
  5. 点击"Create repository"

创建后,GitHub 会显示一组指引命令,告诉你如何把本地仓库连接到这个远程仓库。

将本地仓库推送到 GitHub

回到你的终端,在之前创建的 my-first-repo 目录中执行:

git remote add origin https://github.com/你的用户名/my-first-repo.git
git branch -M main
git push -u origin main

逐行解释:

  • git remote add origin ...——把 GitHub 上的仓库地址关联到本地,命名为 origin(这是远程仓库的默认名称)
  • git branch -M main——将当前分支重命名为 main
  • git push -u origin main——将本地的 main 分支推送到远程仓库。-u 表示建立追踪关系,之后只需要 git push 就够了

执行后,刷新 GitHub 仓库页面,你的文件就出现在上面了。

从 GitHub 克隆项目

如果你想在另一台电脑上获取这个项目,或者想参与别人的开源项目,使用 clone 命令:

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

这条命令会在当前目录下创建一个文件夹,里面包含仓库的所有文件和完整的版本历史。

克隆别人的公开仓库不需要任何权限。

日常的推送和拉取

当你在本地做了新的提交,推送到 GitHub:

git push

当你的协作者推送了新的提交,你需要拉取到本地:

git pull

git pull 会下载远程的最新提交,并自动合并到你本地的分支中。

一个好的工作习惯是:每天开始工作前先 git pull,确保你的本地代码是最新的。

SSH 密钥配置

每次 push 时输入用户名和密码很麻烦,配置 SSH 密钥可以解决这个问题。

生成 SSH 密钥:

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

一路按回车使用默认设置即可。

查看公钥:

cat ~/.ssh/id_ed25519.pub

复制输出的内容,然后:

  1. 打开 GitHub → Settings → SSH and GPG keys
  2. 点击 "New SSH key"
  3. 粘贴公钥,保存

之后添加远程仓库时,使用 SSH 格式的地址(以 [email protected]: 开头),就不再需要每次输入密码了:

git remote set-url origin [email protected]:你的用户名/仓库名.git

第六部分:GitHub 协作功能

Issue:任务与问题追踪

Issue 是 GitHub 提供的任务管理工具。你可以用它来:

  • 报告 Bug("某某功能在某某条件下出错了")
  • 提出功能建议("建议增加某某功能")
  • 记录待办事项

每个 Issue 可以被指派给特定的人、打上标签(如 bug、enhancement、help wanted)、关联到里程碑。

在项目的 Issues 标签页,点击"New Issue"就可以创建。

Pull Request:代码审查与合并

Pull Request(简称 PR)是 GitHub 上协作的核心流程。完整的流程如下:

  1. 创建分支——在自己的分支上开发新功能
  2. 推送分支到 GitHub——git push -u origin 分支名
  3. 创建 Pull Request——在 GitHub 上发起 PR,说明你做了什么改动
  4. 代码审查——团队成员审查你的代码,提出建议或批准
  5. 合并——审查通过后,将分支合并到主分支

PR 的价值在于提供了一个结构化的审查环节。它让代码在合并前经过讨论和检查,避免了"直接往主分支上提交"的风险。

Fork:参与别人的项目

如果你想给一个你没有写入权限的项目贡献代码,流程是这样的:

  1. Fork——在对方项目页面点击"Fork"按钮,这会在你自己的账号下创建一份项目的副本
  2. Clone 到本地——git clone 你fork后的仓库地址
  3. 创建分支并修改——在本地做你的修改
  4. 推送到你的 Fork——git push
  5. 发起 Pull Request——向原项目发起 PR,请求将你的修改合并进去

这套流程是开源社区的标准协作方式。全世界的开发者就是通过这种方式共同维护着无数的开源项目。

第七部分:.gitignore 和 README

.gitignore:告诉 Git 忽略哪些文件

并非项目中的所有文件都应该被 Git 追踪。比如:

  • 编译生成的文件(node_modules/__pycache__/.class 文件)
  • 系统文件(.DS_StoreThumbs.db
  • 敏感信息(.env 文件,包含密码、API 密钥等)
  • 编辑器的配置文件(.vscode/.idea/

在项目根目录创建一个名为 .gitignore 的文件,列出需要忽略的文件或文件夹:

node_modules/
.env
.DS_Store
*.log

GitHub 提供了针对不同编程语言的 .gitignore 模板,创建仓库时可以直接选择。

README.md:项目的说明书

README.md 是项目的门面。当别人访问你的 GitHub 仓库时,首先看到的就是这个文件的内容。一份好的 README 应该包含:

  • 项目名称和简介
  • 安装和使用方法
  • 主要功能列表
  • 如何参与贡献

它使用 Markdown 格式编写(就是你正在阅读的这篇文章的格式)。

第八部分:常见问题和实用技巧

提交信息怎么写

好的提交信息应该简洁且有意义。几个原则:

  • 用动词开头,说明做了什么("添加用户登录功能""修复首页加载异常""重构数据库连接逻辑")
  • 控制在一行以内,50 个字以内
  • 描述"做了什么"和"为什么",而非"怎么做的"

反面例子:updatefix bug修改了一下——这些信息三个月后你看到会一脸茫然。

撤销操作

Git 提供了多种撤销方式,覆盖不同的场景。

撤销工作区的修改(文件改了但还没暂存):

git checkout -- 文件名

撤销暂存(已 add 但还没 commit):

git reset HEAD 文件名

撤销最近一次提交(已 commit 但想修改):

git reset --soft HEAD~1

这会撤销最近一次提交,但保留修改内容在暂存区,你可以重新修改后再提交。

解决合并冲突

当两个人修改了同一个文件的同一个位置时,Git 无法自动决定保留哪个版本,这时就会产生合并冲突。

冲突的文件中会出现类似这样的标记:

<<<<<<< HEAD
你的修改内容
=======
对方的修改内容
>>>>>>> feature-branch

解决方法:

  1. 打开冲突文件
  2. 决定保留哪些内容(可以保留一方的,也可以手动合并双方的)
  3. 删除冲突标记(<<<<<<<=======>>>>>>>
  4. 保存文件,执行 git addgit commit

冲突是正常现象,不需要害怕。随着使用次数的增加,你会越来越熟练地处理它。

GitHub 上的实用功能

GitHub Pages——可以把仓库中的 HTML 文件发布为一个网站,适合个人博客、项目文档、作品展示。免费。

GitHub Actions——自动化工具。你可以设置规则,比如"每次有人提交代码时,自动运行测试"。这是持续集成(CI)的基础设施。

Star 和 Watch——Star 相当于收藏,Watch 相当于订阅。你可以给喜欢的项目加 Star,也可以 Watch 一个项目来接收它的更新通知。

第九部分:学习路径建议

学 Git 和学任何工具一样,关键在于用。以下是一个建议的学习路径:

第一周:建立基本操作的肌肉记忆

每天做一个小练习:创建仓库,写几个文件,提交几次,看看 log。目标是让 git addgit commitgit statusgit log 这些命令变成条件反射。

第二周:在 GitHub 上实践

创建一个真实的项目推送到 GitHub。可以是你的学习笔记、个人博客、或者一个小工具。让你的 GitHub 主页不再是空白的。

第三周:学习分支和协作

练习创建分支、合并分支。找一个朋友互相给对方的仓库提 PR,体验完整的协作流程。

持续:参与开源项目

在 GitHub 上找你感兴趣的项目,从修复文档中的错别字开始,逐步参与更深层次的贡献。这是最快速的成长路径。

附录:完整命令速查表

场景 命令
初始化仓库 git init
查看状态 git status
添加到暂存区 git add 文件名git add .
提交 git commit -m "提交信息"
查看历史 git loggit log --oneline
查看变更 git diff
创建并切换分支 git checkout -b 分支名
切换分支 git checkout 分支名
合并分支 git merge 分支名
克隆远程仓库 git clone 仓库地址
关联远程仓库 git remote add origin 仓库地址
推送到远程 git push
从远程拉取 git pull
撤销文件修改 git checkout -- 文件名
撤销暂存 git reset HEAD 文件名

Git 和 GitHub 的功能远不止于此,但掌握以上内容已经足以应对日常使用。工具的价值在于解决问题,当你在实际项目中遇到新的需求时,再查阅对应的高级功能,效果远好过一次性死记所有命令。

━━━ fin ━━━

If you read this far — thank you.
Come tell me what you thought on X.