
# Git 和 GitHub 完整入门教程——从零开始掌握版本控制
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),输入:
```bash
git --version
```
如果系统已经安装了 Git,会显示版本号。如果没有,macOS 会提示你安装 Xcode Command Line Tools,按提示操作即可。
你也可以通过 Homebrew 安装:
```bash
brew install git
```
Windows
访问 Git 官网(git-scm.com),下载 Windows 安装包。安装过程中,所有选项保持默认即可。安装完成后,你会得到一个叫"Git Bash"的程序,所有 Git 命令都在这里执行。
Linux
以 Ubuntu 为例:
```bash
sudo apt update
sudo apt install git
```
### 初始配置
安装完成后,你需要告诉 Git 你是谁。这些信息会出现在你的每一次提交中。
```bash
git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
```
这里的邮箱建议使用你 GitHub 账号绑定的邮箱,这样提交记录才能正确关联到你的 GitHub 账号。
验证配置是否成功:
```bash
git config --list
```
## 第三部分:Git 基础操作
### 创建你的第一个仓库
打开终端,创建一个新文件夹并进入:
```bash
mkdir my-first-repo
cd my-first-repo
```
初始化 Git 仓库:
```bash
git init
```
终端会显示类似这样的信息:
```
Initialized empty Git repository in /path/to/my-first-repo/.git/
```
现在这个文件夹已经是一个 Git 仓库了。
### 第一次提交
创建一个文件:
```bash
echo "Hello, Git!" > hello.txt
```
查看仓库状态:
```bash
git status
```
Git 会告诉你有一个未追踪的新文件 hello.txt。
将文件添加到暂存区:
```bash
git add hello.txt
```
提交:
```bash
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. 修改文件:
```bash
echo "这是第二行内容" >> hello.txt
```
2. 查看变更:
```bash
git diff
```
Git 会用绿色标记新增的内容,用红色标记删除的内容。
3. 查看状态:
```bash
git status
```
显示 hello.txt 已被修改,但还没暂存。
4. 暂存修改:
```bash
git add hello.txt
```
5. 提交:
```bash
git commit -m "在 hello.txt 中添加第二行内容"
```
6. 查看历史:
```bash
git log --oneline
```
你会看到两条提交记录,每条前面有一个简短的哈希值(类似 a1b2c3d),这是这个提交的唯一标识。
### 分支操作
创建并切换到新分支:
```bash
git checkout -b feature-new-idea
```
这条命令做了两件事:创建名为 feature-new-idea 的分支,并切换到这个分支上。
在新分支上做一些修改并提交:
```bash
echo "这是一个实验性的想法" > experiment.txt
git add experiment.txt
git commit -m "添加实验性内容"
```
切换回主分支:
```bash
git checkout main
```
你会发现 experiment.txt 不见了——因为它只存在于 feature-new-idea 分支。
如果你对实验结果满意,可以把分支合并回来:
```bash
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 目录中执行:
```bash
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 命令:
```bash
git clone https://github.com/用户名/仓库名.git
```
这条命令会在当前目录下创建一个文件夹,里面包含仓库的所有文件和完整的版本历史。
克隆别人的公开仓库不需要任何权限。
### 日常的推送和拉取
当你在本地做了新的提交,推送到 GitHub:
```bash
git push
```
当你的协作者推送了新的提交,你需要拉取到本地:
```bash
git pull
```
git pull 会下载远程的最新提交,并自动合并到你本地的分支中。
一个好的工作习惯是:每天开始工作前先 git pull,确保你的本地代码是最新的。
### SSH 密钥配置
每次 push 时输入用户名和密码很麻烦,配置 SSH 密钥可以解决这个问题。
生成 SSH 密钥:
```bash
ssh-keygen -t ed25519 -C "你的邮箱"
```
一路按回车使用默认设置即可。
查看公钥:
```bash
cat ~/.ssh/id_ed25519.pub
```
复制输出的内容,然后:
1. 打开 GitHub → Settings → SSH and GPG keys
2. 点击 "New SSH key"
3. 粘贴公钥,保存
之后添加远程仓库时,使用 SSH 格式的地址(以 [email protected]: 开头),就不再需要每次输入密码了:
```bash
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 提供了多种撤销方式,覆盖不同的场景。
撤销工作区的修改(文件改了但还没暂存):
```bash
git checkout -- 文件名
```
撤销暂存(已 add 但还没 commit):
```bash
git reset HEAD 文件名
```
撤销最近一次提交(已 commit 但想修改):
```bash
git reset --soft HEAD~1
```
这会撤销最近一次提交,但保留修改内容在暂存区,你可以重新修改后再提交。
### 解决合并冲突
当两个人修改了同一个文件的同一个位置时,Git 无法自动决定保留哪个版本,这时就会产生合并冲突。
冲突的文件中会出现类似这样的标记:
```
<<<<<<< HEAD
你的修改内容
=======
对方的修改内容
>>>>>>> feature-branch
```
解决方法:
1. 打开冲突文件
2. 决定保留哪些内容(可以保留一方的,也可以手动合并双方的)
3. 删除冲突标记<<<<<<<=======>>>>>>>)
4. 保存文件,执行 git add 和 git 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 log 或 git 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 的功能远不止于此,但掌握以上内容已经足以应对日常使用。工具的价值在于解决问题,当你在实际项目中遇到新的需求时,再查阅对应的高级功能,效果远好过一次性死记所有命令。
If you read this far — thank you.
Come tell me what you thought on X.