Git 版本控制教程
从零开始,掌握 Git 的核心概念与实战技能
目录
- 什么是版本控制?
- Git 安装与配置
- Git 核心概念
- 创建与初始化仓库
- 基本操作:暂存、提交、查看
- 分支管理
- 合并与冲突解决
- 远程仓库操作
- GitHub 协作实战
- 常用工作流
- 实用技巧与别名
- 常见问题 FAQ
1. 什么是版本控制?
想象你在写论文,每天保存一个新版本:
论文_初稿.docx
论文_修改版1.docx
论文_修改版2_导师意见.docx
论文_最终版.docx
论文_最终版_真的最终.docx
论文_打死不改了.docx
这种方式既混乱又低效。版本控制系统(VCS) 就是为了解决这个问题而生的——它能自动记录每次修改的内容、时间和作者,让你随时回退到任何历史版本。
Git 是目前世界上最流行的分布式版本控制系统,由 Linux 之父 Linus Torvalds 于 2005 年开发。它的核心优势:
- 分布式:每个人的电脑上都有完整的仓库副本,不依赖中央服务器
- 速度快:几乎所有操作都在本地完成
- 分支轻量:创建和切换分支几乎瞬间完成
- 数据安全:使用 SHA-1 哈希校验,保证数据完整性
2. Git 安装与配置
2.1 安装 Git
Windows:
前往 https://git-scm.com/download/win 下载安装包,双击运行,一路"下一步"即可。安装完成后,在命令行输入:
git --version
输出类似:
git version 2.43.0.windows.1
macOS:
# 方法1:使用 Homebrew(推荐)
brew install git
# 方法2:安装 Xcode Command Line Tools
xcode-select --install
Linux(Ubuntu/Debian):
sudo apt update
sudo apt install git
Linux(CentOS/RHEL):
sudo yum install git
2.2 初始配置
安装完成后,必须设置用户信息,这会记录在你的每次提交中:
# 设置用户名(请替换为你自己的名字)
git config --global user.name "你的名字"
# 设置邮箱(请替换为你自己的邮箱)
git config --global user.email "your-email@example.com"
验证配置:
git config --global --list
输出:
user.name=你的名字
user.email=your-email@example.com
2.3 配置层级说明
Git 有三个配置层级,优先级从高到低:
| 层级 | 命令 | 配置文件位置 | 作用范围 |
|---|---|---|---|
| 系统级 | git config --system |
/etc/gitconfig |
所有用户 |
| 全局级 | git config --global |
~/.gitconfig |
当前用户所有仓库 |
| 仓库级 | git config --local |
.git/config |
当前仓库 |
--global 是最常用的,设置一次后所有仓库都会使用这个身份。
3. Git 核心概念
理解以下概念是学好 Git 的关键:
3.1 工作区域
Git 管理代码时涉及三个区域:
┌──────────────┐ git add ┌──────────────┐ git commit ┌──────────────┐
│ 工作区 │ ──────────────→ │ 暂存区 │ ──────────────→ │ 本地仓库 │
│ (Working Dir) │ │ (Staging Area)│ │ (Repository) │
└──────────────┘ └──────────────┘ └──────────────┘
- 工作区(Working Directory):你电脑上能看到的项目文件目录
- 暂存区(Staging Area / Index):一个临时存储区域,记录下次提交要包含的文件变更
- 本地仓库(Repository):Git 存储项目历史记录的地方(
.git目录)
3.2 文件状态
文件在 Git 中有四种状态:
未跟踪 (Untracked)
│
│ git add
▼
已暂存 (Staged)
│
│ git commit
▼
已提交 (Unmodified/Committed)
│
│ 修改文件
▼
已修改 (Modified)
│
│ git add
▼
已暂存 (Staged) → 循环
- 未跟踪(Untracked):新创建的文件,Git 还不知道它的存在
- 已暂存(Staged):文件的变更已被添加到暂存区,等待提交
- 已提交(Committed):文件的当前版本已被安全存储到仓库
- 已修改(Modified):已跟踪的文件被修改了,但还没有暂存
3.3 提交(Commit)
每次提交就像给项目拍一张快照。每个提交都有:
- 唯一的 SHA-1 哈希值(如
a1b2c3d) - 提交信息(描述这次改了什么)
- 作者和时间
- 指向前一次提交的指针
4. 创建与初始化仓库
4.1 创建新仓库
# 创建项目目录
mkdir my-project
cd my-project
# 初始化 Git 仓库
git init
输出:
Initialized empty Git repository in /home/user/my-project/.git/
此时目录下会生成一个隐藏的 .git 文件夹,它就是 Git 仓库的核心。
4.2 克隆已有仓库
# 从远程仓库克隆(以 GitHub 为例)
git clone https://github.com/user/repo.git
# 克隆到指定目录名
git clone https://github.com/user/repo.git my-local-name
# 克隆特定分支
git clone -b develop https://github.com/user/repo.git
克隆输出示例:
Cloning into 'repo'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (60/60), done.
Receiving objects: 100% (100/100), 50.00 KiB | 1.00 MiB/s, done.
Resolving deltas: 100% (30/30), done.
5. 基本操作:暂存、提交、查看
5.1 查看状态
git status
场景1:新文件未跟踪
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
hello.txt
nothing added to commit but untracked files present
场景2:文件已暂存
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: hello.txt
场景3:文件被修改但未暂存
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: hello.txt
5.2 暂存文件
# 暂存单个文件
git add hello.txt
# 暂存多个文件
git add file1.txt file2.txt
# 暂存所有变更(新文件 + 修改 + 删除)
git add .
# 暂存所有同类型文件
git add *.py
5.3 提交
# 提交暂存区的内容,并附带提交信息
git commit -m "添加hello.txt文件"
输出:
[main (root-commit) a1b2c3d] 添加hello.txt文件
1 file changed, 1 insertion(+)
create mode 100644 hello.txt
5.4 提交信息规范
好的提交信息能让团队协作更顺畅。推荐格式:
<类型>: <简短描述>
<详细说明(可选)>
常用类型:
| 类型 | 用途 |
|---|---|
feat |
新功能 |
fix |
修复 bug |
docs |
文档变更 |
style |
代码格式调整(不影响逻辑) |
refactor |
重构代码 |
test |
添加测试 |
chore |
构建/工具变更 |
示例:
git commit -m "feat: 添加用户登录功能"
git commit -m "fix: 修复密码验证逻辑错误"
git commit -m "docs: 更新 README 安装说明"
5.5 查看提交历史
# 基本查看
git log
输出:
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
Author: 你的名字 <your-email@example.com>
Date: Wed May 28 10:00:00 2026 +0800
添加hello.txt文件
# 单行简洁模式(最常用)
git log --oneline
输出:
a1b2c3d 添加hello.txt文件
# 带图形的分支历史
git log --oneline --graph --all
输出:
* d4e5f6a (HEAD -> main) 合并feature分支
|\
| * b2c3d4e (feature) 添加新功能
|/
* a1b2c3d 初始提交
# 查看最近N次提交
git log -5
# 查看某个文件的提交历史
git log -- hello.txt
# 查看每次提交的文件变更统计
git log --stat
5.6 查看差异
# 工作区 vs 暂存区(未暂存的修改)
git diff
# 暂存区 vs 最新提交(已暂存但未提交的变更)
git diff --staged
# 两个提交之间的差异
git diff a1b2c3d b2c3d4e
# 查看某个文件的差异
git diff -- hello.txt
输出示例:
diff --git a/hello.txt b/hello.txt
index 8d0e412..3f4a5b6 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1,2 @@
Hello, World!
+This is a new line.
5.7 撤销操作
# 撤销工作区的修改(恢复到上次暂存或提交的状态)
git restore hello.txt
# 取消暂存(从暂存区移除,但保留工作区修改)
git restore --staged hello.txt
# 修改最近一次提交的信息
git commit --amend -m "新的提交信息"
# 修改最近一次提交,追加文件到上次提交
git add forgotten-file.txt
git commit --amend --no-edit
5.8 .gitignore 文件
有些文件不需要被 Git 跟踪(如编译产物、日志、密码文件等)。在项目根目录创建 .gitignore 文件:
# 创建 .gitignore
cat > .gitignore << 'EOF'
# 操作系统文件
.DS_Store
Thumbs.db
# 编辑器文件
*.swp
*.swo
.vscode/
.idea/
# 编译产物
*.o
*.pyc
__pycache__/
build/
dist/
# 依赖目录
node_modules/
vendor/
# 环境变量(包含敏感信息!)
.env
.env.local
# 日志文件
*.log
EOF
.gitignore 的匹配规则:
| 模式 | 含义 |
|---|---|
*.log |
忽略所有 .log 结尾的文件 |
build/ |
忽略 build 目录下所有文件 |
/TODO |
仅忽略根目录的 TODO 文件 |
doc/**/*.pdf |
忽略 doc 目录下所有子目录中的 .pdf 文件 |
!important.log |
不忽略 important.log(取反) |
6. 分支管理
分支是 Git 最强大的功能之一。它允许你在不影响主线的情况下进行开发。
6.1 分支的基本概念
main: A --- B --- C --- D
\
feature: E --- F
main是主分支(默认分支名)feature是从C点创建的新分支- 在
feature上的提交(E、F)不会影响main
6.2 分支操作
# 查看所有本地分支(* 表示当前分支)
git branch
输出:
* main
# 创建新分支
git branch feature
# 切换分支
git switch feature
# 或者使用旧语法:git checkout feature
# 创建并切换到新分支(一步到位,最常用)
git switch -c feature
# 或者:git checkout -b feature
# 切换回主分支
git switch main
# 查看所有分支(包括远程分支)
git branch -a
输出:
* main
feature
remotes/origin/main
remotes/origin/feature
# 查看每个分支的最后一次提交
git branch -v
输出:
feature b2c3d4e 添加新功能
* main a1b2c3d 初始提交
6.3 删除分支
# 删除已合并的分支
git branch -d feature
# 强制删除未合并的分支(谨慎使用!)
git branch -D feature
# 删除远程分支
git push origin --delete feature
6.4 重命名分支
# 重命名当前分支
git branch -m new-name
# 重命名指定分支
git branch -m old-name new-name
7. 合并与冲突解决
7.1 合并分支
# 切换到目标分支(要把 feature 合并到 main,就切到 main)
git switch main
# 合并 feature 分支
git merge feature
快进合并(Fast-Forward):当目标分支没有新提交时,Git 只需移动指针:
合并前:
main: A --- B
\
feature: C --- D
合并后(快进):
main: A --- B --- C --- D
输出:
Updating a1b2c3d..d4e5f6a
Fast-forward
file.txt | 2 ++
1 file changed, 2 insertions(+)
三方合并(Three-Way Merge):当两个分支都有新提交时,Git 会创建一个新的合并提交:
合并前:
main: A --- B --- E
\
feature: C --- D
合并后:
main: A --- B --- E --- M (合并提交)
\ /
feature: C --- D
输出:
Merge made by the 'ort' strategy.
file.txt | 2 ++
1 file changed, 2 insertions(+)
7.2 处理合并冲突
当两个分支修改了同一文件的同一区域时,会产生冲突。这是开发中非常常见的情况。
冲突示例:
假设 hello.txt 在两个分支中被不同地修改:
main 分支的内容:
Hello from main!
feature 分支的内容:
Hello from feature!
执行合并时:
git switch main
git merge feature
输出:
Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt
Automatic merge failed; fix conflicts and then commit the result.
查看冲突文件内容:
cat hello.txt
输出:
<<<<<<< HEAD
Hello from main!
=======
Hello from feature!
>>>>>>> feature
Git 用特殊标记标识冲突区域:
<<<<<<< HEAD到=======:当前分支(main)的内容=======到>>>>>>> feature:被合并分支(feature)的内容
解决冲突的步骤:
- 编辑文件:手动选择保留哪个版本,或合并两者
- 删除冲突标记:去掉
<<<<<<<、=======、>>>>>>> - 暂存文件:
git add - 完成合并:
git commit
# 第1步:编辑文件,解决冲突
# 假设我们决定保留两者
echo -e "Hello from main!\nHello from feature!" > hello.txt
# 第2步:暂存解决后的文件
git add hello.txt
# 第3步:提交合并结果(Git 会自动生成合并提交信息)
git commit
此时会打开编辑器,显示默认的合并提交信息:
Merge branch 'feature' into main
# Conflicts:
# hello.txt
保存并关闭编辑器即可完成合并。
放弃合并(如果冲突太多想重来):
git merge --abort
7.3 Rebase(变基)
Rebase 是另一种整合分支的方式,它能产生更线性的提交历史:
# 在 feature 分支上,将提交"移植"到 main 的最新提交之后
git switch feature
git rebase main
Rebase 前:
main: A --- B --- E
\
feature: C --- D
Rebase 后:
main: A --- B --- E
\
feature': C' --- D'
注意: Rebase 会改写提交历史。永远不要对已推送到远程的公共分支执行 rebase!
# 如果 rebase 出现冲突,解决后继续
git add resolved-file.txt
git rebase --continue
# 放弃 rebase
git rebase --abort
8. 远程仓库操作
8.1 远程仓库概念
远程仓库是托管在服务器(如 GitHub、GitLab)上的项目副本。最常用的远程仓库名是 origin。
# 查看远程仓库信息
git remote -v
输出:
origin https://github.com/user/repo.git (fetch)
origin https://github.com/user/repo.git (push)
8.2 添加远程仓库
# 添加远程仓库
git remote add origin https://github.com/user/repo.git
# 修改远程仓库地址
git remote set-url origin https://github.com/user/new-repo.git
# 添加多个远程仓库
git remote add upstream https://github.com/original/repo.git
8.3 推送(Push)
# 首次推送并设置上游分支
git push -u origin main
# 后续推送(已有上游追踪关系)
git push
# 推送指定分支
git push origin feature
# 强制推送(危险!会覆盖远程历史)
git push --force-with-lease origin feature
首次推送输出:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 300 bytes | 300.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/user/repo.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.
8.4 拉取(Pull)
# 拉取远程更新并合并到当前分支(= fetch + merge)
git pull
# 拉取并使用 rebase 代替 merge(保持线性历史)
git pull --rebase
# 拉取指定远程分支
git pull origin feature
8.5 获取(Fetch)
# 获取远程更新但不合并(更安全)
git fetch origin
# 查看远程有哪些新提交
git log HEAD..origin/main --oneline
# 获取后手动合并
git merge origin/main
fetch vs pull 的区别:
| 操作 | 行为 | 安全性 |
|---|---|---|
git fetch |
只下载远程数据,不修改工作区 | 安全,可以先检查再决定是否合并 |
git pull |
下载并立即合并到当前分支 | 可能产生意外冲突 |
9. GitHub 协作实战
9.1 注册与创建仓库
- 访问 github.com 注册账号
- 点击右上角 "+" → "New repository"
- 填写仓库名称(如
my-project) - 选择公开(Public)或私有(Private)
- 勾选 "Initialize this repository with a README"
- 点击 "Create repository"
9.2 配置 SSH 密钥(推荐)
使用 SSH 可以免去每次输入密码的麻烦:
# 生成 SSH 密钥
ssh-keygen -t ed25519 -C "your-email@example.com"
输出:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
# 查看公钥内容
cat ~/.ssh/id_ed25519.pub
复制输出的公钥内容,然后:
- 打开 GitHub → Settings → SSH and GPG keys
- 点击 "New SSH key"
- 粘贴公钥并保存
# 测试 SSH 连接
ssh -T git@github.com
输出:
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
之后就可以使用 SSH 地址克隆和推送:
git clone git@github.com:username/my-project.git
9.3 Fork 与 Pull Request 工作流
这是 GitHub 上最核心的协作方式,适用于开源项目和团队协作。
场景:你想为别人的项目贡献代码
# 第1步:在 GitHub 上 Fork 仓库(网页操作)
# 点击仓库页面右上角的 "Fork" 按钮
# 第2步:克隆你 Fork 的仓库到本地
git clone git@github.com:你的用户名/项目名.git
cd 项目名
# 第3步:添加原始仓库为 upstream 远程
git remote add upstream git@github.com:原始作者/项目名.git
# 第4步:创建功能分支
git switch -c fix-typo
# 第5步:进行修改、暂存、提交
# (编辑文件...)
git add .
git commit -m "fix: 修复README中的拼写错误"
# 第6步:推送到你的 Fork
git push origin fix-typo
# 第7步:在 GitHub 上创建 Pull Request
# 打开你 Fork 的仓库页面,点击 "Compare & pull request"
# 填写标题和描述,说明你做了什么修改
# 点击 "Create pull request"
保持 Fork 与原始仓库同步:
# 获取原始仓库的最新代码
git fetch upstream
# 切换到 main 分支
git switch main
# 合并上游的更新
git merge upstream/main
# 推送到你的 Fork
git push origin main
9.4 Issues 与项目管理
GitHub Issues 是追踪 bug、功能请求和任务的好工具:
- 创建 Issue:描述问题或功能需求,添加标签(bug、enhancement 等)
- 关联提交:在提交信息中引用 Issue:
git commit -m "fix: 修复登录bug (closes #42)" - 关联 PR:在 PR 描述中引用 Issue:
Fixes #42
当 PR 被合并后,关联的 Issue 会自动关闭。
9.5 GitHub Actions 简介
GitHub Actions 可以自动化 CI/CD 流程。在仓库中创建 .github/workflows/ci.yml:
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: |
echo "运行测试..."
# 这里放你的测试命令
每次推送到 main 或创建 PR 时,GitHub 会自动运行这个工作流。
10. 常用工作流
10.1 集中式工作流
最简单的模式,适合小团队:
所有人直接在 main 分支上协作:
git pull → 修改 → git add → git commit → git push
优点:简单直接 缺点:容易冲突,不适合并行开发
10.2 Feature Branch 工作流
每个功能一个分支,完成后合并到 main:
# 1. 从 main 创建功能分支
git switch main
git pull
git switch -c feature/user-login
# 2. 在功能分支上开发
# ... 编写代码 ...
git add .
git commit -m "feat: 实现用户登录功能"
# 3. 推送功能分支
git push -u origin feature/user-login
# 4. 在 GitHub 上创建 Pull Request
# 5. 代码审查通过后合并
# 6. 删除功能分支
git switch main
git pull
git branch -d feature/user-login
git push origin --delete feature/user-login
10.3 Git Flow 工作流
适合有明确发布周期的项目:
main ─────────────────────────────────── 生产环境
│
└── develop ──────────────────────── 开发主线
│ │ │
└── feature/login └── feature/payment ← 功能分支
│
└── release/1.0 ────────────── 发布准备
│
└── hotfix/critical-bug ─ 紧急修复
| 分支 | 用途 | 命名示例 |
|---|---|---|
main |
生产环境代码 | - |
develop |
开发主线 | - |
feature/* |
新功能开发 | feature/user-login |
release/* |
发布准备 | release/1.0.0 |
hotfix/* |
生产环境紧急修复 | hotfix/login-crash |
# 创建功能分支
git switch -c feature/user-login develop
# 功能完成后合并到 develop
git switch develop
git merge --no-ff feature/user-login
# 准备发布
git switch -c release/1.0.0 develop
# 发布完成后合并到 main 并打标签
git switch main
git merge --no-ff release/1.0.0
git tag -a v1.0.0 -m "版本 1.0.0 发布"
# 同时合并回 develop
git switch develop
git merge --no-ff release/1.0.0
10.4 Trunk-Based Development(主干开发)
适合持续部署的团队,所有人都频繁地向 main 提交小的变更:
# 频繁地从 main 拉取最新代码
git pull
# 短命分支(通常不超过一天)
git switch -c quick-fix
# ... 快速修改 ...
git push -u origin quick-fix
# 创建 PR、合并、删除分支
# 关键:保持 main 始终可部署
11. 实用技巧与别名
11.1 常用别名配置
# 设置常用别名
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"
git config --global alias.amend "commit --amend --no-edit"
设置后:
git st # 等同于 git status
git co main # 等同于 git checkout main
git lg # 等同于 git log --oneline --graph --all --decorate
git last # 查看最后一次提交
11.2 暂存工作现场(Stash)
当你正在开发一个功能,突然需要切换分支处理紧急 bug:
# 保存当前工作现场
git stash
输出:
Saved working directory and index state WIP on main: a1b2c3d 最新提交
# 查看所有保存的现场
git stash list
输出:
stash@{0}: WIP on main: a1b2c3d 最新提交
stash@{1}: WIP on feature: b2c3d4e 功能开发中
# 恢复最近的现场
git stash pop
# 恢复但不删除 stash 记录
git stash apply stash@{0}
# 删除指定的 stash
git stash drop stash@{0}
# 清空所有 stash
git stash clear
# 带描述的 stash
git stash push -m "登录功能开发到一半"
11.3 标签(Tag)
用于标记版本发布:
# 创建轻量标签
git tag v1.0.0
# 创建带注释的标签(推荐)
git tag -a v1.0.0 -m "第一个正式版本"
# 给历史提交打标签
git tag -a v0.9.0 a1b2c3d -m "初始测试版"
# 查看所有标签
git tag
输出:
v0.9.0
v1.0.0
# 查看标签详情
git show v1.0.0
# 推送标签到远程
git push origin v1.0.0
# 推送所有标签
git push origin --tags
# 删除本地标签
git tag -d v1.0.0
# 删除远程标签
git push origin --delete v1.0.0
11.4 回退与重置
# 查看操作历史(找到要回退的版本)
git reflog
输出:
a1b2c3d HEAD@{0}: commit: 最新提交
b2c3d4e HEAD@{1}: commit: 之前的提交
c3d4e5f HEAD@{2}: commit: 更早的提交
# 软回退:保留工作区和暂存区的变更(最安全)
git reset --soft HEAD~1
# 混合回退:保留工作区变更,取消暂存(默认模式)
git reset HEAD~1
# 硬回退:丢弃所有变更,彻底回到某个版本(危险!)
git reset --hard HEAD~1
# 生成一个新的提交来撤销某个提交(安全,不改历史)
git revert a1b2c3d
reset vs revert 对比:
| 操作 | 是否改写历史 | 是否安全(已推送时) |
|---|---|---|
git reset |
是 | 不安全,不要对已推送的提交使用 |
git revert |
否(创建新提交) | 安全,适合公共分支 |
12. 常见问题 FAQ
Q1:误删了文件怎么办?
# 如果还没提交,从暂存区恢复
git restore filename.txt
# 如果已经提交了删除,从历史中恢复
git checkout HEAD -- filename.txt
Q2:提交了敏感信息(密码、密钥)怎么办?
# 1. 立即修改密码/密钥(最重要!)
# 2. 从历史中移除文件
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch sensitive-file.txt' \
--prune-empty --tag-name-filter cat -- --all
# 或使用更现代的工具
# git filter-repo --path sensitive-file.txt --invert-paths
Q3:如何查看某个文件是谁在什么时候修改的?
git blame filename.txt
输出:
a1b2c3d4 (张三 2026-05-20 10:00:00 +0800 1) 第一行内容
b2c3d4e5 (李四 2026-05-21 14:30:00 +0800 2) 第二行内容
Q4:如何合并多个提交为一个(Squash)?
# 合并最近3个提交
git reset --soft HEAD~3
git commit -m "合并后的提交信息"
或者使用交互式 rebase:
git rebase -i HEAD~3
编辑器会打开,将后两个 pick 改为 squash(或 s):
pick a1b2c3d 第一个提交
squash b2c3d4e 第二个提交
squash c3d4e5f 第三个提交
Q5:push 被拒绝怎么办?
# 原因:远程有本地没有的更新
# 解决:先拉取再推送
git pull --rebase origin main
git push
# 注意:除非你明确知道自己在做什么,否则不要使用 --force
Q6:如何查看 Git 配置?
# 查看所有配置
git config --list
# 查看某个具体配置
git config user.name
git config user.email
快速参考卡
| 操作 | 命令 |
|---|---|
| 初始化仓库 | git init |
| 克隆仓库 | git clone <url> |
| 查看状态 | git status |
| 暂存文件 | git add <file> / git add . |
| 提交变更 | git commit -m "信息" |
| 查看历史 | git log --oneline |
| 创建分支 | git branch <name> |
| 切换分支 | git switch <name> |
| 创建并切换 | git switch -c <name> |
| 合并分支 | git merge <branch> |
| 推送到远程 | git push |
| 拉取远程更新 | git pull |
| 暂存工作现场 | git stash |
| 查看差异 | git diff |
| 查看标签 | git tag |
最后的话: Git 的学习曲线可能在初期看起来有些陡峭,但核心操作其实就那么几个。建议你创建一个测试仓库,把本文的每个命令都亲手敲一遍。实践是最好的老师——当你遇到问题时,
git status和git log永远是你最好的朋友。
祝你版本控制愉快!🎉