Git 实战分享

最新推荐文章于 2026-01-08 11:17:11 发布

原创最新推荐文章于 2026-01-08 11:17:11 发布 · 553 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#git #嵌入式

底层软件开发同时被 3 个专栏收录

176 篇文章

订阅专栏

嵌入式软件开发

156 篇文章

订阅专栏

Linux

13 篇文章

订阅专栏

引言：为什么需要 “场景化” 学习 Git？

在软件开发、项目协作、技术文档管理等工作场景中，Git 早已成为不可或缺的版本控制工具。但多数开发者学习 Git 时，往往陷入 “孤立记指令” 的误区 —— 能背诵 git add「git commit`，却在实际工作中遇到 “如何创建分支不影响主代码”“代码冲突怎么解决”“紧急修复 bug 时未完成的代码怎么办” 等问题时手足无措。

核心原因在于：Git 的指令不是孤立存在的，而是围绕 “版本管理流程” 形成的有机整体。本文将以 6 个核心工作场景 为线索，把 Git 高频指令串联成可直接落地的操作流程，从 “原理拆解→步骤详解→指令用法→常见问题” 四个维度，帮你彻底掌握 Git 在实际工作中的应用，让你从 “会用指令” 升级为 “能解决问题”。

本文适合：开发工程师、测试工程师、技术文档撰写者、学生等所有需要使用 Git 进行版本管理的人群。阅读后你将能够：

独立完成 “本地项目推远程”“日常协作开发”“多分支并行开发” 等核心场景操作；
快速解决代码冲突、版本回退、临时切换分支等高频问题；
理解每个指令背后的 “版本管理逻辑”，而非死记硬背；
形成符合企业协作规范的 Git 操作习惯。

前置知识：Git 核心概念快速梳理（避免踩坑的基础）

在进入场景前，先明确 3 个核心概念，这是理解所有操作流程的关键：

工作区：你本地电脑上能看到的项目文件夹（日常编写代码的地方）；
暂存区：介于工作区和本地仓库之间的 “临时存储区”，用于存放待提交的修改（通过 git add 指令将工作区文件移入）；
本地仓库：项目根目录下隐藏的 .git 文件夹（通过 git init 初始化生成），存储所有提交记录和版本信息；
远程仓库：服务器上的仓库（如 GitHub、Gitee、企业 GitLab），用于团队共享代码（通过 git push「git pull` 与本地仓库同步）。

核心逻辑：工作区修改 → 暂存区（git add） → 本地仓库（git commit） → 远程仓库（git push），这是 Git 最基础的 “代码提交链路”，所有场景都是基于这条链路的延伸。

场景一：本地新建项目 → 推送到远程仓库（从零到一搭建版本管理）

场景背景

你在本地新建了一个项目（如前端 Vue 项目、后端 Java 项目、技术博客仓库），需要将项目上传到远程仓库（如 GitHub），方便后续备份、共享或团队协作。这是 Git 最基础的 “初始化场景”，仅需执行一次，但步骤缺一不可。

操作流程全解析（含指令原理 + 细节）

步骤 1：创建本地项目文件夹并进入

首先在本地电脑上新建一个文件夹（如 my-project），作为项目根目录，然后通过终端（Windows 命令提示符 / Powershell、Mac/Linux 终端）进入该文件夹：

bash

# Windows/Mac/Linux 通用命令
mkdir my-project  # 新建文件夹（若已手动新建，可跳过此步）
cd my-project     # 进入项目根目录

关键说明：后续所有 Git 指令必须在「项目根目录」下执行，否则会提示 “不是 Git 仓库”（fatal: not a git repository）。

步骤 2：初始化 Git 仓库（让 Git 接管项目）

进入项目根目录后，执行 git init 指令，初始化本地仓库：

bash

git init

指令原理：该指令会在项目根目录下生成一个隐藏的 .git 文件夹，这个文件夹是 Git 仓库的核心，包含了版本管理所需的所有配置文件、提交记录、分支信息等（切勿手动删除或修改 .git 文件夹内的内容，否则会导致仓库损坏）。

执行结果：终端会输出 Initialized empty Git repository in /Users/xxx/my-project/.git/，表示初始化成功。此时，你的项目已经被 Git 接管，可以开始进行版本管理了。

步骤 3：创建项目初始文件（模拟项目内容）

初始化仓库后，需要创建一些项目文件（如 README.md、代码文件等），模拟实际开发中的项目内容：

bash

# 新建 README.md 文件（项目说明文档，必建）
echo "# 我的项目" > README.md
# 新建代码文件（以 Python 为例，可根据实际项目类型修改）
touch main.py

关键说明：此时这些文件处于「工作区」，Git 尚未跟踪它们（即 Git 不知道这些文件的存在），需要通过后续指令让 Git 识别。

步骤 4：查看文件状态（确认变更范围）

执行 git status 指令，查看当前工作区和暂存区的文件状态：

bash

# 完整输出（适合新手，显示详细说明）
git status
# 简写输出（推荐，仅显示文件状态标识，更高效）
git status -s

指令原理：git status 是 Git 最常用的 “状态查询工具”，能清晰告知你：哪些文件是未跟踪的（新创建的文件）、哪些是已修改的、哪些是已暂存的。

执行结果解读：

若执行 git status，会输出：Untracked files:（未跟踪文件），下方列出 README.md 和 main.py，表示这两个文件是新创建的，Git 尚未跟踪；
若执行 git status -s，会输出：?? README.md 和 ?? main.py，其中 ?? 是未跟踪文件的标识（常用标识：?? 未跟踪、M 已修改、A 已暂存）。

为什么要做这一步：在执行 git add 前，通过 git status 确认需要提交的文件，避免误将无关文件（如日志文件、缓存文件）暂存。

步骤 5：暂存所有修改（工作区 → 暂存区）

执行 git add . 指令，将工作区的所有文件（未跟踪 / 已修改）暂存到暂存区：

bash

git add .

指令原理：git add 的核心作用是 “将工作区的变更存入暂存区”，暂存区相当于一个 “待提交清单”，只有进入清单的文件，才能被后续的 git commit 指令提交到本地仓库。

常用变体（按需选择）：

git add README.md：仅暂存指定文件（适合精准提交单个文件）；
git add src/：暂存指定文件夹下的所有变更（适合多文件按目录分类提交）；
git add -A：暂存所有变更（包括删除的文件，与 git add . 功能类似，推荐日常使用）。

执行后验证：再次执行 git status -s，会发现文件标识从 ?? 变为 A（A = Added，已暂存），表示文件已成功进入暂存区。

步骤 6：提交到本地仓库（暂存区 → 本地仓库）

执行 git commit 指令，将暂存区的文件永久提交到本地仓库，并生成一条提交记录：

bash

git commit -m "init: 项目初始化，创建 README.md 和 main.py"

指令原理：git commit 是 Git 版本管理的核心指令，每一次 commit 都会生成一个唯一的 “提交 ID”（如 a1b2c3d），包含提交者信息、提交时间、提交说明等，方便后续追溯版本、回退代码。

关键细节：

-m 参数后面必须跟 “提交说明”，且说明要清晰明了，遵循 “类型：描述” 的规范（如 feat: 新增用户登录功能、fix: 修复登录按钮点击无响应、docs: 更新 README 文档），方便自己和团队成员理解该次提交的目的；
若忘记加 -m 参数，会自动打开系统默认编辑器（如 Vim），强制你填写提交说明（Vim 操作：按 i 进入编辑模式，输入说明后按 Esc，输入 :wq 保存退出）；
若提交后发现漏加文件或提交说明写错，可执行 git commit --amend -m "新的提交说明"，追加提交并覆盖上一次的提交记录（仅适用于未推送到远程的本地提交）。

执行结果：终端会输出提交信息，包含提交 ID、提交者、提交时间、修改文件数、新增 / 删除代码行数等，例如：

plaintext

[main (root-commit) a1b2c3d] init: 项目初始化，创建 README.md 和 main.py
 2 files changed, 1 insertion(+)
 create mode 100644 README.md
 create mode 100644 main.py

表示成功创建了一条提交记录，修改了 2 个文件，新增了 1 行代码（README.md 中的 # 我的项目）。

步骤 7：关联远程仓库（本地仓库 ↔ 远程仓库）

要将本地仓库的代码推送到远程，首先需要关联远程仓库的地址。远程仓库地址需提前在 GitHub/Gitee/GitLab 上新建仓库获取（以 GitHub 为例）：

登录 GitHub，点击右上角 “+” 号，选择 “New repository”；
填写仓库名称（需与本地项目名称一致，如 my-project），选择公开 / 私有，点击 “Create repository”；
仓库创建成功后，复制远程仓库地址（支持 HTTPS 和 SSH 两种协议，推荐 SSH 协议，无需每次推送输入账号密码）。

关联远程仓库的指令：

bash

git remote add origin 你的远程仓库地址

指令解析：

git remote：用于管理本地仓库与远程仓库的关联关系；
add：表示 “新增关联”；
origin：是远程仓库的 “别名”（默认别名，可自定义，如 git remote add github 地址），后续推送 / 拉取时可直接用别名代替完整地址；
远程仓库地址示例（GitHub）：
- HTTPS：https://github.com/your-username/my-project.git
- SSH：git@github.com:your-username/my-project.git（需提前配置 SSH 密钥，下文有配置教程）。

验证关联是否成功：执行 git remote -v 指令，查看当前关联的远程仓库地址：

bash

git remote -v

若输出以下内容，表示关联成功（origin 对应的就是远程仓库地址）：

plaintext

origin  git@github.com:your-username/my-project.git (fetch)
origin  git@github.com:your-username/my-project.git (push)

拓展：配置 SSH 密钥（免密推送）若使用 SSH 协议的远程地址，需要配置 SSH 密钥，避免每次推送都输入账号密码：

本地生成 SSH 密钥（终端执行，一路回车即可）：
bash
```
ssh-keygen -t rsa -C "你的邮箱地址"
```
查找 SSH 公钥文件（默认路径）：
- Windows：C:\Users\你的用户名\.ssh\id_rsa.pub
- Mac/Linux：~/.ssh/id_rsa.pub
复制公钥内容（打开 id_rsa.pub 文件，全选复制）；
登录 GitHub，点击右上角头像→“Settings”→“SSH and GPG keys”→“New SSH key”，粘贴公钥内容，点击 “Add SSH key”。

步骤 8：首次推送本地分支到远程

关联远程仓库后，执行 git push 指令，将本地仓库的代码推送到远程：

bash

git push -u origin main

指令解析：

git push：核心作用是 “将本地仓库的提交记录推送到远程仓库”；
-u：全称 --set-upstream，表示 “绑定本地分支与远程分支的关联关系”，首次推送新分支时必须添加该参数，后续推送可直接执行 git push（无需再写 origin main）；
origin：远程仓库别名（步骤 7 配置的）；
main：本地分支名称（Git 2.28+ 版本默认分支名为 main，旧版本为 master，可通过 git branch 查看当前分支名）。

执行结果：终端会显示推送进度，若输出 100% 和 done，表示推送成功。此时登录 GitHub 查看新建的仓库，会发现 README.md 和 main.py 已同步到远程。

步骤 9：后续日常推送（简化操作）

首次推送绑定分支关联后，后续本地提交代码后，无需再写完整指令，直接执行：

bash

git push

Git 会自动将当前分支的提交推送到关联的远程分支（如本地 main 分支 → 远程 main 分支）。

该场景常见问题与解决方案

问题 1：执行 `git push -u origin main` 时提示 “fatal: remote origin already exists”

原因：本地仓库已关联过其他远程仓库，origin 别名已被占用。解决方案：

查看已关联的远程仓库：git remote -v；
删除旧的关联：git remote remove origin；
重新关联新的远程仓库：git remote add origin 新地址。

问题 2：推送失败，提示 “Permission denied (publickey)”

原因：SSH 密钥配置错误或未配置，导致远程仓库拒绝访问。解决方案：

检查 SSH 密钥是否生成：ls ~/.ssh/（Mac/Linux）或 dir C:\Users\用户名\.ssh\（Windows），若没有 id_rsa 和 id_rsa.pub 文件，重新生成密钥；
检查公钥是否正确添加到 GitHub：重新复制 id_rsa.pub 内容，确认在 GitHub 的 SSH 密钥列表中；
测试 SSH 连接：ssh -T git@github.com，若输出 Hi your-username! You've successfully authenticated，表示配置成功。

问题 3：推送失败，提示 “error: failed to push some refs to 'xxx'”

原因：远程仓库有本地没有的提交记录（如多人协作时，他人已推送过代码），Git 为避免覆盖远程代码，拒绝推送。解决方案：

先拉取远程最新代码：git pull origin main（若有冲突，先解决冲突）；
再推送本地代码：git push -u origin main。

该场景核心指令总结（可直接复制执行）

bash

# 1. 新建项目文件夹并进入
mkdir my-project && cd my-project
# 2. 初始化 Git 仓库
git init
# 3. 创建初始文件（示例）
echo "# 我的项目" > README.md && touch main.py
# 4. 暂存所有文件
git add .
# 5. 提交到本地仓库
git commit -m "init: 项目初始化"
# 6. 关联远程仓库（替换为你的地址）
git remote add origin git@github.com:your-username/my-project.git
# 7. 首次推送（绑定分支）
git push -u origin main
# 后续推送简化
git push

场景二：日常协作开发（拉取远程→开发→提交→推送）

场景背景

你加入了一个团队项目，需要每天与团队成员协作开发：拉取他人提交的最新代码，避免冲突；自己开发完成后，将代码推送到远程仓库，供他人共享。这是最高频的工作场景（每天至少执行 1-2 次），核心原则是 “先拉后推”。

操作流程全解析（含冲突处理细节）

步骤 1：每日开发前拉取远程最新代码

每天开始开发前，必须先执行 git pull 指令，拉取远程仓库的最新代码，合并到本地当前分支，避免因本地代码过时导致冲突：

bash

# 最简写法（拉取当前分支对应的远程分支）
git pull
# 完整写法（指定远程仓库和分支，适合多远程关联场景）
git pull origin main

指令原理：git pull 是 git fetch + git merge 的组合指令：

git fetch：从远程仓库拉取最新代码到本地，但不自动合并；
git merge：将拉取的远程代码与本地当前分支的代码合并。因此，git pull 直接完成 “拉取 + 合并”，简化操作。

为什么必须先拉取：团队协作中，其他成员会不断推送代码到远程仓库。如果你的本地代码是几天前的版本，直接推送会导致 “代码覆盖” 或 “冲突无法解决”，这是团队协作的大忌。

步骤 2：判断是否存在代码冲突

执行 git pull 后，会出现两种情况：

情况 1：无冲突：终端输出 Already up to date（已同步最新版本）或 Merge made by the 'recursive' strategy（合并成功），表示远程代码与本地代码无冲突，可直接开始开发。
情况 2：有冲突：终端输出 Automatic merge failed; fix conflicts and then commit the result，表示 Git 无法自动合并代码，需要手动解决冲突。

冲突产生的原因：多人修改了同一文件的同一行代码，Git 无法判断保留哪一方的修改，因此需要人工干预。

步骤 3：解决代码冲突（关键步骤）

若出现冲突，按以下步骤解决：

查看冲突文件：执行 git status -s，终端会列出冲突的文件，标识为 UU（UU = Unmerged，未合并），例如：UU src/user.js；

打开冲突文件：用代码编辑器（如 VS Code、WebStorm）打开冲突文件，会看到类似以下的冲突标记：

javascript

// 冲突标记说明：
// <<<<<<< HEAD 下方是你本地的代码
// ======= 是冲突分隔线
// >>>>>>> 远程分支名（如 origin/main）下方是远程仓库的代码
<<<<<<< HEAD
const username = "本地修改的用户名";
=======
const username = "远程修改的用户名";
>>>>>>> origin/main

手动修改冲突：根据实际需求，删除冲突标记（<<<<<<< HEAD、=======、>>>>>>> origin/main），保留正确的代码。例如：
javascript
```
// 保留本地和远程的合理修改（或根据业务需求选择其一）
const username = "最终确定的用户名";
```
注意：必须删除所有冲突标记，否则提交时会报错。
暂存冲突文件：冲突解决后，执行 git add 指令，将修改后的文件重新暂存：
bash
```
git add 冲突文件名  # 如：git add src/user.js
```
提交冲突解决：执行 git commit 指令，提交冲突解决结果（无需手动写提交说明，Git 会自动生成冲突解决的备注）：
bash
```
git commit
```
若自动打开编辑器，直接保存退出即可（或执行 git commit -m "fix: 解决与远程分支的代码冲突" 手动添加说明）。

冲突解决原则：

谁修改，谁解决：冲突通常由修改同一文件的开发者协商解决，避免擅自删除他人代码；
优先保留业务逻辑正确的代码：若冲突是因为业务逻辑差异，需与团队成员沟通后再确定保留方案；
避免批量删除冲突标记：逐行检查冲突内容，确保不遗漏重要代码。

步骤 4：开始日常开发（编写 / 修改代码）

冲突解决后（或无冲突时），即可开始日常开发工作：编写新功能、修复 bug、优化代码等。开发过程中，建议遵循 “小步提交” 原则 —— 每完成一个小功能点（如一个按钮的点击事件、一个接口的封装），就进行一次提交，避免一次性提交大量代码（不利于后续版本回退和问题排查）。

步骤 5：开发中随时查看文件状态

开发过程中，可随时执行 git status -s，查看当前工作区的文件变更状态，避免遗漏提交或误提交无关文件（如日志文件、缓存文件、IDE 生成的配置文件）。

示例：若新建了 src/login.js 文件，修改了 src/user.js 文件，执行 git status -s 会输出：

plaintext

 M src/user.js  # M = 已修改（Modified）
?? src/login.js # ?? = 未跟踪（Untracked）

步骤 6：暂存所有修改

开发完成一个功能点后，执行 git add . 指令，将工作区的所有变更（已修改、未跟踪的文件）暂存到暂存区：

bash

git add .

注意：若有不需要提交的文件（如 node_modules/、dist/、日志文件），可在项目根目录创建 .gitignore 文件，添加需要忽略的文件 / 文件夹，Git 会自动忽略这些文件，不会显示在 git status 中。

.gitignore 文件示例（前端项目）：

plaintext

# 依赖包文件夹
node_modules/
# 构建产物文件夹
dist/
# 日志文件
*.log
# IDE 配置文件
.idea/
.vscode/
# 操作系统生成的文件
.DS_Store
Thumbs.db

步骤 7：提交到本地仓库

执行 git commit 指令，将暂存区的文件提交到本地仓库，提交说明需规范、清晰：

bash

git commit -m "feat: 新增用户登录功能，实现账号密码登录"

提交说明规范（推荐 Conventional Commits 规范）：

类型	说明	示例
feat	新增功能	feat: 新增购物车结算功能
fix	修复 bug	fix: 修复登录按钮点击无响应
docs	文档修改	docs: 更新 API 文档
style	代码格式调整（不影响逻辑）	style: 格式化代码，删除多余空格
refactor	代码重构（不新增功能 / 修复 bug）	refactor: 重构用户模块代码
test	新增 / 修改测试用例	test: 新增登录功能单元测试
chore	构建 / 依赖 / 工具配置修改	chore: 升级 axios 依赖到 1.6.0

规范的提交说明能让你和团队成员快速理解每次提交的目的，后续查看提交历史（git log）时也能提高效率。

步骤 8：推送本地提交到远程仓库

提交完成后，执行 git push 指令，将本地仓库的提交记录推送到远程仓库：

bash

git push

执行结果：终端显示推送进度，若输出 100% 和 done，表示推送成功。此时，团队其他成员执行 git pull 即可拉取到你的代码。

推送失败的常见处理：

推送时提示 “远程有更新未拉取”：先执行 git pull 拉取远程最新代码（解决可能的冲突），再执行 git push；
提示 “权限不足”：检查远程仓库的访问权限（是否为团队成员、是否有推送权限），联系仓库管理员添加权限。

该场景实战演练（模拟 “新增功能” 完整流程）

假设你需要为团队项目新增 “用户注册功能”，完整操作流程如下：

bash

# 1. 开发前拉取远程最新代码
git pull
# 2. 无冲突，开始开发：新建注册相关文件，编写代码
touch src/register.js
# 3. 开发完成，查看文件状态
git status -s
# 4. 暂存所有修改
git add .
# 5. 提交到本地仓库（规范备注）
git commit -m "feat: 新增用户注册功能，支持手机号验证码注册"
# 6. 推送代码到远程
git push

执行完成后，登录远程仓库（如 GitHub），可在 “Commits” 列表中看到你提交的记录，团队成员执行 git pull 即可同步你的代码。

该场景核心技巧（提高开发效率）

配置 Git 提交模板：创建 .gitmessage 文件，定义提交说明的模板，每次执行 git commit 时自动弹出，强制遵循规范：

bash

# 新建提交模板文件
echo "feat: 
详细说明：
关联需求：" > ~/.gitmessage
# 配置 Git 使用该模板
git config --global commit.template ~/.gitmessage

使用 git commit -am 简化 “修改文件” 的提交流程：若修改的是已跟踪的文件（非新创建的文件），可跳过 git add .，直接执行：
base
```
git commit -am "fix: 修复注册按钮样式错乱"
```
该指令等价于 git add 所有已跟踪的修改文件 + git commit -m "备注"，适合快速提交修改。

定期查看提交历史：执行 git log --oneline，查看近期的提交记录，了解团队代码变更情况：

bash

git log --oneline
# 输出示例（提交 ID 前7位 + 提交说明）
a1b2c3d (HEAD -> main, origin/main) feat: 新增用户注册功能
d4e5f6g fix: 修复登录按钮点击无响应
g7h8i9j init: 项目初始化

场景三：多分支开发（功能分支→开发→合并到主分支）

场景背景

在实际项目中，为了避免开发中的代码影响主分支（main，通常用于存放稳定的生产环境代码），团队会采用 “多分支开发” 模式：

主分支（main）：仅保留稳定的、已发布的代码，不允许直接在上面开发；
功能分支（feature-xxx）：用于开发新功能（如 feature-login、feature-shopping-cart）；
修复分支（bugfix-xxx）：用于修复生产环境的 bug（如 bugfix-login-error）；
测试分支（test）：用于测试功能，通过后合并到主分支。

该场景的核心是 “分支创建→分支开发→分支合并→分支删除”，确保代码的隔离性和稳定性。

操作流程全解析（以 “开发新功能” 为例）

步骤 1：基于主分支创建功能分支

首先确保当前处于主分支（main），并拉取最新代码，然后创建功能分支：

bash

# 1. 切换到主分支（若已在主分支，可跳过）
git switch main  # Git 2.23+ 版本推荐，语义清晰
# 或旧版命令：git checkout main
# 2. 拉取主分支最新代码
git pull
# 3. 创建功能分支并立即切换到该分支（核心指令）
git switch -c feature-login  # -c = create，创建并切换
# 或旧版命令：git checkout -b feature-login

指令解析：

git switch：用于切换分支（Git 2.23+ 新增，替代 git checkout 的分支切换功能，语义更清晰）；
-c 参数：表示 “创建新分支”，等价于 git branch 分支名 + git switch 分支名；
分支命名规范：推荐 feature-功能名（功能分支）、bugfix-bug描述（修复分支），便于团队识别分支用途。

验证分支创建成功：执行 git branch 指令，查看本地所有分支，当前分支前会带 * 标识：

bash

git branch
# 输出示例（* 表示当前分支）
* feature-login
  main

步骤 2：在功能分支进行开发

切换到功能分支后，即可开始开发新功能（如用户登录功能），开发流程与 “日常协作开发” 一致：

bash

# 1. 编写代码（新建/修改文件）
touch src/login.js
# 2. 暂存修改
git add .
# 3. 提交到本地仓库（规范备注）
git commit -m "feat: 实现账号密码登录逻辑"
# 4. 继续开发，多次提交（小步提交原则）
# ... 开发登录页面样式 ...
git add .
git commit -m "feat: 完成登录页面 UI 开发"
# ... 开发登录接口请求 ...
git add .
git commit -m "feat: 封装登录接口，处理成功/失败逻辑"

关键说明：功能分支的所有提交都仅保存在该分支，不会影响主分支的代码，确保主分支的稳定性。

步骤 3：推送功能分支到远程仓库

开发过程中，建议定期将功能分支推送到远程仓库（避免本地代码丢失，同时方便团队成员 review 代码）：

bash

# 首次推送功能分支（需绑定远程分支）
git push -u origin feature-login
# 后续推送（已绑定，简化指令）
git push

执行结果：远程仓库会新增一个 feature-login 分支，团队成员可通过 git pull origin feature-login 拉取该分支的代码进行 review。

步骤 4：功能开发完成，准备合并到主分支

当功能开发完成、测试通过后，需要将功能分支的代码合并到主分支（main），使其成为项目的一部分：

切换回主分支：
bash
```
git switch main
```
拉取主分支最新代码（避免合并时因主分支有更新导致冲突）：
bash
```
git pull
```

步骤 5：将功能分支合并到主分支

执行 git merge 指令，将功能分支（feature-login）的代码合并到当前分支（主分支 main）：

git merge feature-login

指令原理：git merge 的核心作用是 “将指定分支的所有提交记录合并到当前分支”，合并后，主分支会包含功能分支的所有代码变更。

合并后的两种情况：

情况 1：无冲突：终端输出 Merge made by the 'recursive' strategy，表示合并成功，主分支已包含功能分支的代码；
情况 2：有冲突：终端提示冲突，处理方式与 “日常协作开发” 中的冲突解决一致（查看冲突文件→手动修改→git add→git commit）。

步骤 6：推送合并后的主分支到远程

合并成功后，执行 git push 指令，将合并后的主分支推送到远程仓库，完成功能上线：

bash

git push origin main

此时，远程仓库的主分支（main）已包含新开发的登录功能，其他团队成员拉取主分支代码即可使用。

步骤 7：删除本地和远程的功能分支（可选）

功能分支合并到主分支后，该分支已完成使命，可删除以保持分支整洁：

删除本地功能分支：

bash

# 安全删除（仅删除已合并到主分支的分支）
git branch -d feature-login
# 强制删除（若分支未合并，需用 -D）
# git branch -D feature-login

删除远程功能分支：
bash
```
git push origin --delete feature-login
```

验证删除成功：

本地：git branch 查看，已无 feature-login 分支；
远程：登录 GitHub/Gitee，查看分支列表，已无 feature-login 分支。

该场景拓展：Git Flow 工作流（企业级协作规范）

在大型团队中，通常会采用更规范的 Git Flow 工作流，分支划分更细致：

主分支：main（生产环境代码）、develop（开发环境代码）；
功能分支：feature-xxx（基于 develop 分支创建，开发完成后合并回 develop）；
修复分支：hotfix-xxx（基于 main 分支创建，修复生产环境 bug 后，同时合并到 main 和 develop）；
发布分支：release-xxx（基于 develop 分支创建，用于版本发布前的测试，通过后合并到 main 和 develop）。

Git Flow 工作流的核心流程：

从 develop 分支创建 feature-xxx 分支开发功能；
功能完成后合并回 develop 分支；
从 develop 分支创建 release-xxx 分支进行发布测试；
测试通过后，将 release-xxx 分支合并到 main 和 develop 分支；
生产环境出现 bug 时，从 main 分支创建 hotfix-xxx 分支修复，修复后合并到 main 和 develop 分支。

该工作流适合迭代周期长、团队规模大的项目，能有效保证代码质量和版本管理的规范性。

该场景常见问题与解决方案

问题 1：合并分支时提示 “fatal: refusing to merge unrelated histories”

原因：两个分支的提交历史没有关联（如本地新建的分支与远程分支无共同祖先）。解决方案：合并时添加 --allow-unrelated-histories 参数，允许合并无关联历史的分支：

bash

git merge feature-login --allow-unrelated-histories

问题 2：合并后发现功能有问题，想撤销合并

原因：合并后测试发现功能存在严重 bug，需要撤销合并操作。解决方案：

查看合并提交的 ID：git log --oneline，找到合并记录（通常备注为 Merge branch 'feature-login'）；
执行 git reset 回退到合并前的版本：
bash
```
git reset --hard 合并前的提交ID
```
若已将合并后的代码推送到远程，需要强制推送回退：
bash
```
git push -f origin main
```
注意：强制推送（-f）会覆盖远程分支的历史，仅在团队内部确认无问题时使用，避免影响他人代码。

问题 3：需要在功能分支中同步主分支的最新代码

原因：功能分支开发周期较长，主分支已有其他成员提交的重要代码（如修复了一个影响所有功能的 bug），需要将主分支的代码同步到功能分支。解决方案：在功能分支中执行 git merge main，将主分支的代码合并到当前功能分支：

bash

# 1. 切换到功能分支
git switch feature-login
# 2. 拉取主分支最新代码
git pull origin main
# 3. 将主分支代码合并到功能分支
git merge main
# 4. 解决可能的冲突，然后推送功能分支
git add . && git commit -m "merge: 同步主分支最新代码" && git push

场景四：临时切换分支（未完成开发，需处理紧急任务）

场景背景

你正在功能分支（feature-login）开发登录功能，代码还未完成（未提交），突然接到紧急任务：生产环境的主分支（main）出现一个严重 bug，需要立即修复。此时，你不能直接提交未完成的代码，也不能带着未完成的代码切换分支（会导致代码混乱），需要用 git stash 指令临时暂存工作区的修改。

操作流程全解析（核心：暂存→切换→处理→恢复）

步骤 1：临时暂存工作区的未完成修改

在功能分支（feature-login）中，执行 git stash 指令，将工作区所有未提交的修改（包括已修改但未 add、已 add 但未 commit、未跟踪的文件）暂存到 “暂存栈” 中：

bash

# 暂存当前工作区的所有未提交修改
git stash
# 可选：添加暂存备注，方便后续识别（多暂存时推荐）
git stash save "feat-login: 未完成登录接口封装"

指令原理：git stash 会创建一个临时的 “存储快照”，将工作区和暂存区的未提交修改保存起来，然后将工作区恢复到当前分支的最后一次提交状态（干净的工作区），这样就可以放心切换分支了。

执行结果：终端输出 Saved working directory and index state WIP on feature-login: a1b2c3d feat: 实现账号密码登录逻辑，表示暂存成功（WIP = Work In Progress，正在进行中的工作）。

验证暂存成功：执行 git status -s，终端无任何输出，表示工作区干净，所有未提交的修改已被暂存。

步骤 2：查看暂存列表（确认暂存成功）

执行 git stash list 指令，查看暂存栈中的所有暂存记录：

bash

运行

git stash list

执行结果：输出暂存记录列表，格式为 stash@{n}: WIP on 分支名: 提交ID 提交说明，例如：

plaintext

stash@{0}: On feature-login: feat-login: 未完成登录接口封装

stash@{0}：暂存记录的序号（0 表示最近一次暂存，1 表示上一次，以此类推）；
若有多次暂存，会列出多条记录，便于后续选择恢复哪一次的暂存。

步骤 3：切换到紧急任务分支（如主分支）

工作区干净后，执行 git switch 指令，切换到需要处理紧急任务的分支（如主分支 main）：

bash

运行

git switch main

关键说明：此时切换分支不会携带任何未完成的代码，主分支的工作区是干净的，可放心处理紧急任务。

步骤 4：处理紧急任务（修复生产环境 bug）

在主分支（main）中，处理紧急 bug（如修复用户支付失败的问题），处理流程与 “日常协作开发” 一致：

bash

运行

# 1. 拉取主分支最新代码（确保基于最新版本修复）
git pull origin main
# 2. 修复 bug（修改相关文件）
# ... 编写修复代码 ...
# 3. 暂存+提交+推送
git add .
git commit -m "hotfix: 修复生产环境支付接口超时 bug"
git push origin main

关键说明：紧急修复完成后，主分支的 bug 已解决，可通知测试团队验证。

步骤 5：切换回原功能分支

紧急任务处理完成后，执行 git switch 指令，切换回之前开发的功能分支（feature-login）：

bash

运行

git switch feature-login

步骤 6：恢复之前暂存的未完成代码

执行 git stash pop 指令，将暂存栈中最近一次的暂存记录（stash@{0}）恢复到工作区，并删除该暂存记录：

bash

运行

# 恢复最近一次暂存（最常用）
git stash pop
# 恢复指定序号的暂存（如有多次暂存，例如恢复第 1 次暂存）
# git stash pop stash@{1}

指令原理：git stash pop = git stash apply（恢复暂存） + git stash drop（删除暂存记录），是 “恢复 + 清理” 的组合指令，适合仅需恢复最近一次暂存的场景。

执行结果：终端输出 On branch feature-login 和 Your branch is up to date with 'origin/feature-login'，表示暂存恢复成功。此时，你之前未完成的代码会回到工作区，可继续开发。

验证恢复成功：执行 git status -s，会看到之前暂存的文件状态（如 M src/login.js），表示代码已恢复。

步骤 7：继续开发未完成的功能

恢复代码后，继续开发登录功能，完成后按正常流程提交并推送：

bash

运行

# 继续开发...
git add .
git commit -m "feat: 完成登录接口封装，处理超时逻辑"
git push

该场景拓展：`git stash` 的其他实用指令

除了 git stash「git stash pop，git stash` 还有以下常用变体，应对不同场景：

仅暂存已修改但未 add 的文件：

bash

运行

git stash -k  # -k = --keep-index，保留暂存区的文件（已 add 的文件不暂存）

暂存时包含未跟踪的文件：

bash

运行

git stash -u  # -u = --include-untracked，默认不暂存未跟踪文件，加 -u 可包含

查看暂存的具体修改内容：

bash

运行

git stash show  # 查看最近一次暂存的文件变更统计
git stash show -p  # 查看最近一次暂存的具体代码修改（-p = --patch）
git stash show stash@{1} -p  # 查看指定暂存的具体修改

仅恢复暂存，不删除暂存记录：

bash

运行

git stash apply  # 恢复最近一次暂存，暂存记录保留在栈中
git stash apply stash@{1}  # 恢复指定暂存

删除暂存记录：

bash

运行

git stash drop  # 删除最近一次暂存记录
git stash drop stash@{1}  # 删除指定暂存记录
git stash clear  # 清空所有暂存记录（谨慎使用）

该场景常见问题与解决方案

问题 1：恢复暂存后，出现代码冲突

原因：切换分支处理紧急任务时，修改了与功能分支相同的文件，恢复暂存时导致冲突。解决方案：

终端会提示冲突文件，执行 git status -s 查看冲突文件；
打开冲突文件，手动解决冲突（参考场景二的冲突解决步骤）；
解决后执行 git add 冲突文件，继续开发。

问题 2：忘记暂存修改，直接切换分支，导致代码被带到新分支

原因：未执行 git stash，直接切换分支，若工作区有未提交的修改，且这些修改在新分支中不存在，Git 会将这些修改带到新分支（不会自动提交）。解决方案：

在新分支中执行 git status -s，查看被带过来的修改；
若不需要这些修改，执行 git checkout -- 文件名，放弃工作区的修改；
若需要保留这些修改，执行 git stash 暂存，然后切换回原分支恢复。

场景五：版本回退（提交错误 / 代码异常，需恢复历史版本）

场景背景

在开发过程中，可能会遇到以下情况：

提交了错误的代码（如误提交了测试文件、提交了未修复的 bug）；
代码修改后出现异常，想恢复到之前能正常运行的版本；
合并分支后发现功能异常，想撤销合并操作。

此时需要使用 Git 的 “版本回退” 功能，将代码恢复到指定的历史版本。Git 提供了 git reset 和 git revert 两种核心指令，适用场景不同，需重点区分。

核心概念：`git reset` vs `git revert`（关键区别）

指令	核心作用	历史记录影响	适用场景	风险程度
`git reset`	直接将分支指针回退到指定版本	覆盖历史记录（不可逆）	本地未推送的错误提交、合并操作	高（慎用）
`git revert`	新增一条反向提交，抵消指定版本的修改	保留历史记录（可逆）	已推送远程的错误提交、公共分支回退	低（推荐）

核心原则：

若错误提交仅在本地（未推送到远程），用 git reset（高效快捷）；
若错误提交已推送到远程（公共分支），用 git revert（不破坏历史，不影响他人）。

操作流程一：本地未推送的错误提交（用 `git reset`）

步骤 1：查看提交历史，找到目标回退版本的 ID

执行 git log --oneline 指令，查看本地仓库的提交历史，找到需要回退到的 “目标版本 ID”（提交 ID 前 7 位）：

bash

运行

git log --oneline
# 输出示例（按时间倒序，最新提交在前）
a1b2c3d (HEAD -> feature-login) feat: 新增登录错误提示（错误提交）
d4e5f6g feat: 实现账号密码验证逻辑（正确版本）
g7h8i9j feat: 完成登录页面 UI 开发

假设最新的提交 a1b2c3d 是错误提交（如误提交了未测试的代码），需要回退到上一个正确版本 d4e5f6g。

步骤 2：选择回退模式，执行 `git reset`

git reset 有三种模式（--soft、--mixed、--hard），需根据需求选择：

模式 1：`git reset --mixed`（默认模式，推荐）

核心作用：回退版本，保留工作区的修改，清空暂存区；
适用场景：想保留错误提交的代码（可能有可复用部分），仅撤销 commit 和 add 操作。

bash

运行

# 回退到指定版本（d4e5f6g 是目标版本 ID）
git reset --mixed d4e5f6g
# 简写（默认就是 --mixed，可省略）
git reset d4e5f6g

执行结果：

分支指针回退到 d4e5f6g 版本；
工作区保留错误提交的代码（feat: 新增登录错误提示）；
暂存区被清空（错误提交的代码回到 “未暂存” 状态）。

后续操作：

查看工作区代码，保留需要的部分，删除错误部分；
重新执行 git add . + git commit -m "feat: 优化登录错误提示"，提交正确的代码。

模式 2：`git reset --soft`

核心作用：回退版本，保留工作区和暂存区的修改；
适用场景：仅想撤销 commit 操作，暂存区的文件无需重新 add。

bash

运行

git reset --soft d4e5f6g

执行结果：

分支指针回退到 d4e5f6g 版本；
工作区和暂存区都保留错误提交的代码；
可直接执行 git commit -m "新的提交说明"，重新提交。

模式 3：`git reset --hard`（慎用！不可逆）

核心作用：强制回退版本，清空工作区和暂存区的所有修改；
适用场景：错误提交的代码完全无用，想彻底删除，恢复到目标版本的干净状态。

bash

运行

git reset --hard d4e5f6g

执行结果：

分支指针回退到 d4e5f6g 版本；
工作区和暂存区的所有修改（包括错误提交的代码）被彻底删除，无法恢复；
终端会输出 HEAD is now at d4e5f6g feat: 实现账号密码验证逻辑。

警告：git reset --hard 会永久删除未提交的修改和错误提交的代码，仅在确认无需保留任何代码时使用！

步骤 3：验证回退结果

执行 git log --oneline，查看提交历史，确认分支指针已回退到目标版本：

bash

运行

git log --oneline
# 输出示例（错误提交 a1b2c3d 已消失）
d4e5f6g (HEAD -> feature-login) feat: 实现账号密码验证逻辑
g7h8i9j feat: 完成登录页面 UI 开发

操作流程二：已推送远程的错误提交（用 `git revert`）

步骤 1：查看远程提交历史，找到错误提交的 ID

执行 git log --oneline，查看包含远程提交的历史记录（确保已拉取最新远程代码）：

bash

运行

git pull origin main
git log --oneline
# 输出示例（错误提交已推送到远程）
a1b2c3d (HEAD -> main, origin/main) feat: 新增错误功能（已推送远程）
d4e5f6g feat: 实现正确功能

错误提交 a1b2c3d 已推送到远程，不能用 git reset（会覆盖远程历史，导致团队协作冲突），需用 git revert。

步骤 2：执行 `git revert`，撤销错误提交

执行 git revert 指令，指定错误提交的 ID，生成一条反向提交记录：

bash

运行

git revert a1b2c3d

指令原理：git revert 不会删除错误提交的历史记录，而是新增一条 “反向修改” 的提交，抵消错误提交的所有代码变更。例如，错误提交新增了一行代码，git revert 会新增一条提交删除该行代码；错误提交修改了一行代码，git revert 会新增一条提交将其恢复原状。

步骤 3：编辑撤销提交的说明（可选）

执行 git revert 后，会自动打开系统默认编辑器（如 Vim），让你填写撤销提交的说明（默认说明为 Revert "feat: 新增错误功能"），按以下步骤操作：

按 i 进入编辑模式；
输入提交说明（如 revert: 撤销新增错误功能，修复生产环境异常）；
按 Esc，输入 :wq 保存退出。

若不需要修改说明，直接保存退出即可。

步骤 4：解决可能的冲突

如果错误提交的代码与后续提交的代码有冲突，git revert 会提示冲突，处理方式与之前的冲突解决一致：

查看冲突文件：git status -s；
打开冲突文件，手动删除冲突标记，保留正确代码；
暂存冲突文件：git add 冲突文件名；
完成撤销提交：git revert --continue（若想放弃撤销，执行 git revert --abort）。

步骤 5：推送撤销提交到远程

撤销提交完成后，执行 git push，将新增的撤销提交推送到远程仓库：

bash

运行

git push origin main

执行结果：远程仓库的提交历史中，会新增一条 revert: 撤销新增错误功能 的提交记录，错误提交的代码被抵消，且历史记录完整保留。

验证结果：登录远程仓库（如 GitHub），查看提交历史，会看到错误提交和撤销提交的两条记录，主分支的代码已恢复到错误提交前的状态。

该场景常见问题与解决方案

问题 1：回退版本后，想恢复之前的错误提交

原因：执行 git reset --hard 后，发现错误提交的代码还有用，想恢复。解决方案：

执行 git reflog 指令，查看所有操作记录（包括已被 reset 覆盖的提交）：
bash

运行
```
git reflog
```
找到错误提交的 ID（如 a1b2c3d）；
执行 git reset --hard a1b2c3d，恢复到错误提交的版本。

关键说明：git reflog 会记录本地仓库的所有操作（提交、reset、revert、stash 等），默认保留 90 天，是恢复误操作的 “救命指令”。

问题 2：`git revert` 撤销多个连续的错误提交

原因：多个连续的提交都是错误的（如提交 ID 为 a1b2c3d、d4e5f6g、g7h8i9j），需要一次性撤销。解决方案：使用 git revert 的范围撤销功能，指定起始提交和结束提交（左开右闭区间）：

bash

运行

# 撤销从 a1b2c3d（不包含）到 g7h8i9j（包含）的所有提交
git revert a1b2c3d..g7h8i9j
# 若要包含起始提交 a1b2c3d，用 ^ 标记
git revert a1b2c3d^..g7h8i9j

执行后，会为每个错误提交生成一条撤销提交记录，按提示填写说明即可。

场景六：项目发布（打标签→推送标签→发布版本）

场景背景

当主分支（main）的代码经过测试，确认稳定可发布时，需要为该版本打标签（tag），标记为正式发布版本（如 v1.0.0、v1.1.0）。标签是 Git 中的 “版本快照”，便于后续追溯发布版本、回滚到发布版本，是项目迭代和维护的重要工具。

操作流程全解析（规范发布流程）

步骤 1：切换到主分支，拉取最新代码

确保当前处于主分支，且代码是最新的（已合并所有已完成的功能和修复）：

bash

运行

# 切换到主分支
git switch main
# 拉取远程最新代码
git pull origin main

步骤 2：为当前版本打标签（创建标签）

执行 git tag 指令，为当前最新提交打标签，标签名遵循 “语义化版本” 规范：

bash

运行

# 打轻量标签（仅包含提交 ID，无额外信息）
git tag v1.0.0
# 打附注标签（包含标签说明、作者、时间，推荐）
git tag -a v1.0.0 -m "Release: v1.0.0 正式版，包含登录、注册、支付功能"

语义化版本规范（Semantic Versioning）：标签名格式为 v主版本号.次版本号.修订号（如 v1.0.0）：

主版本号（Major）：不兼容的 API 变更（如 v2.0.0）；
次版本号（Minor）：向后兼容的功能新增（如 v1.1.0）；
修订号（Patch）：向后兼容的问题修复（如 v1.0.1）。

指令解析：

-a：annotated 的缩写，表示创建附注标签（推荐，包含完整的标签信息）；
-m：指定标签说明，记录该版本的核心功能、修复的问题等，便于后续查阅。

步骤 3：查看所有标签

执行 git tag 指令，查看本地仓库的所有标签（按字母顺序排列）：

bash

运行

git tag
# 输出示例
v1.0.0

若标签较多，可通过正则匹配查询：

bash

运行

# 查看以 v1. 开头的标签
git tag -l "v1.*"

步骤 4：查看标签详情（可选）

执行 git show 指令，查看标签的详细信息（包括标签说明、对应的提交记录、代码变更等）：

bash

运行

git show v1.0.0

执行结果：输出标签的作者、创建时间、标签说明、对应的提交 ID、提交说明、代码变更等信息，便于确认标签的正确性。

步骤 5：推送标签到远程仓库

与分支不同，git push 不会自动推送标签到远程仓库，需要单独执行标签推送指令：

bash

运行

# 推送单个标签到远程
git push origin v1.0.0
# 推送本地所有标签到远程（适合多个标签同时推送）
git push origin --tags

执行结果：终端显示标签推送进度，推送成功后，远程仓库会同步该标签。

步骤 6：在远程仓库创建 Release（可选，企业级发布）

版本号：v1.0.0；
发布标题：如 “v1.0.0 正式发布：上线核心业务功能”；
发布说明：列出该版本的核心功能、修复的 bug、已知问题、升级指南等；
附件（可选）：上传编译后的项目包（如 .zip、.tar.gz 文件），方便用户直接下载使用。

创建完成后，团队成员和用户可通过 Release 页面查看版本信息、下载安装包，是项目对外发布的重要入口。

步骤 7：标签的删除（错误标签处理）

若标签打错（如版本号错误、标签说明错误），需要删除本地和远程的标签：

删除本地标签：
bash

运行
```
git tag -d v1.0.0
```

删除远程标签：

bash

运行

git push origin --delete tag v1.0.0
# 或简写
git push origin :refs/tags/v1.0.0

重新打标签并推送：

bash

运行

git tag -a v1.0.1 -m "Release: v1.0.1 正式版，修复 v1.0.0 中的支付 bug"
git push origin v1.0.1

该场景拓展：基于历史提交打标签

若需要为过去的某个历史提交打标签（如为 d4e5f6g 提交打标签 v0.9.0，标记为测试版本），可在 git tag 后指定提交 ID：

bash

运行

# 基于历史提交 d4e5f6g 打标签
git tag -a v0.9.0 d4e5f6g -m "Release: v0.9.0 测试版，包含基础功能"
# 推送标签到远程
git push origin v0.9.0

该场景常见问题与解决方案

问题 1：推送标签时提示 “权限不足”

原因：远程仓库的标签推送权限被限制（部分 Git 仓库仅允许管理员推送标签）。解决方案：联系仓库管理员，申请标签推送权限；或确认当前账号是否为仓库的 “开发者” 及以上角色。

问题 2：本地标签与远程标签不一致（如本地删除了标签，远程未删除）

原因：本地删除标签后，未同步删除远程标签，导致标签状态不一致。解决方案：执行远程标签删除指令（git push origin --delete tag 标签名），同步本地和远程的标签状态。

总结：Git 实战核心心法与指令速查

核心心法（避免踩坑的关键）

先拉后推：团队协作中，任何推送前必须先拉取远程最新代码，避免冲突；
小步提交：每完成一个小功能 / 修复一个 bug 就提交一次，提交说明规范清晰；
分支隔离：主分支仅保留稳定代码，功能开发 /bug 修复在专用分支中进行；
慎用危险指令：git reset --hard、git clean -f、git push -f 等指令不可逆，执行前务必确认；
善用状态查询：git status -s 随时查看文件状态，git log --oneline 随时查看提交历史，git reflog 恢复误操作。

高频指令速查（按场景分类）

场景	核心指令组合
本地新建→远程	`git init → git add . → git commit -m → git remote add → git push -u`
日常协作	`git pull → 开发 → git add . → git commit -m → git push`
多分支开发	`git switch -c → 开发 → git push → git switch main → git merge → git push`
临时切换分支	`git stash → git switch → 处理任务 → git switch → git stash pop`
本地版本回退	`git log --oneline → git reset [--mixed/--soft/--hard] 提交ID`
远程版本回退	`git log --oneline → git revert 提交ID → git push`
项目发布	`git switch main → git pull → git tag -a → git push origin 标签名`