Git笔记---分支相关操作

1. 什么是分支

Git 分支是并行开发的核心功能，可实现「功能开发、Bug 修复、版本发布」等场景的隔离，避免影响主分支稳定性。

团队成员可以在一个仓库的各个分支进行独立功能的开发，在开发完成之后进行分支的合并。

• 主分支：默认是 main（或旧版本 master），用于存放稳定代码（生产环境可用）。我们创建好本地仓库之后，默认就处于主分支。
• 功能分支：如 feature/login，用于开发新功能，开发完成后合并回主分支。
• Bugfix 分支：如 bugfix/order-err，用于修复线上问题，修复后合并回主分支。
• HEAD：指向当前所在的分支（可理解为「当前工作位置」）。

建议先看：Git笔记---简单介绍与基本使用

2. 分支的创建与切换

1. 查看本地分支：

   git branch  # 列出所有本地分支，当前分支前带「*」

   

2. 创建新分支：

   git branch <分支名>  # 例：git branch dev

3. 切换到指定分支：

   # 方法1：git checkout（兼容旧版本）
   git checkout <分支名>  # 例：git checkout dev# 方法2：git switch（Git 2.23+ 推荐，更直观）
   git switch <分支名>

注：不同分支的暂存区与版本库都是独立且互不可见的，如果工作区没有新的修改，那么我们在切换分支时工作区的内容会同步到该分支下的最新版本，例如：

在master分支下的README.md文件中输入如下内容并提交到版本库：

切换到dev分支：

此时，我们会发现README.md中的内容消失了：

同时，日志当中也没有相关提交记录：

3. 分支的合并

将某一分支合并到当前分支：

git merge <分支名>  # 例：git merge dev

3.1 无冲突的合并

当主分支和开发分支的修改没有重叠时，Git 会自动完成合并。

例如，我们将主分支合并到dev分支：

会看到主分支提交的内容被同步到了dev分支下：

3.2 有冲突的合并

当主分支和开发分支修改了同一文件的同一部分，Git 无法自动判断保留哪部分，会提示「冲突」，需手动解决。

例如，在3.1的基础之上，master分支将 " hello git " 改成 " hello master "，dev分支将 " hello git " 改成 " hello dev "：

二者分别提交自己的修改：

此时，我们再尝试将dev合并到master，会发现自动合并失败：

在这种情况下，git会修改我们工作区的内容，指示冲突所在并将取舍权交给用户：

用户需要自己决定哪些内容留下来，当然你也可以什么都不做，就保留上面的内容。

但是，此时我们的合并还未完成，我们还需要手动进行一次提交：

我们可以使用如下命令来可视化查看分支合并情况：

git log --graph --abbrev-commit

4. 分支的删除

删除本地分支（合并后安全删除）：

git branch -d <分支名>  # 例：git branch -d dev

若分支未合并，Git 会提示拒绝删除，避免误删未提交的代码。

强制删除未合并的分支（谨慎使用！）：

git branch -D <分支名>

5. 合并模式

在无冲突的情况下，git自动完成合并，这种合并模式也叫Fast-forward模式。

例如，在3.1当中我们进行了无冲突的合并：

可以看到在合并完成之后，提示信息当中显示：Fast-forward。

如果我们在此时查看日志：

我们会发现日志当中并不会体现出两条分支的合并，我们无法区分最新的这次提交是在当前分支下进行的，还是合并了其他分支。

为了解决这个问题，我们就不能使用Fast-forward模式进行合并，此时我们可以使用：

git merge --no-ff -m "提交信息" <分支名>

为了在团队中明确责任所在，建议使用非Fast-forward模式进行合并。

6. 工作区和暂存区保存

git stash 是 Git 中用于临时保存工作区和暂存区修改的核心命令 —— 当你正在分支上开发（代码未完成，不想提交），需要切换到其他分支（如紧急修复 Bug）时，可通过 stash 将当前进度 “暂存” 起来，待后续返回原分支后恢复，避免未提交的修改丢失或污染其他分支。

6.1 保存当前进度

将工作区已修改的文件和暂存区的内容（git add 过的文件）一起保存到 Git 的 “stash 栈” 中，同时清空工作区和暂存区（回到最近一次提交的干净状态）。

# 简化写法（推荐）：保存当前进度，默认生成系统提示的描述
git stash# 完整写法：自定义 stash 描述（便于后续识别，推荐）
git stash save "描述"

扩展：保存未跟踪文件（默认不保存）

默认情况下，git stash 只保存「已跟踪文件」（已加入版本控制的文件）的修改，未跟踪文件（新创建、未 git add 过的文件）不会被保存。若需保存未跟踪文件：

# -u / --include-untracked：保存未跟踪文件
git stash save -u "描述"# -a / --all：保存所有文件（包括未跟踪文件 + 忽略文件 .gitignore 中的文件）
git stash save -a "描述"

6.2 查看已保存的 stash 列表

stash 以 “栈” 的形式存储（先进后出），可通过以下命令查看所有已保存的 stash 记录：

git stash list

eg：

stash@{0}: On master: 描述0
stash@{1}: On dev: 描述1

• stash@{n}：stash 的索引（0 是最新保存的 stash，1 是上一个，以此类推）；
• On <分支名>：该 stash 是在哪个分支保存的；
• 后面是自定义的 stash 描述（便于识别）。

6.3 恢复 stash 进度

1. 恢复并删除 stash（推荐，用完即清）
   恢复最新的 stash（stash@{0}）到工作区，同时从 stash 栈中删除该记录：

   # 恢复最新的 stash（stash@{0}）
   git stash pop# 恢复指定索引的 stash（如恢复 stash@{1}）
   git stash pop stash@{1}

2. 恢复但保留 stash（需多次复用同一 stash 时）
   恢复 stash 到工作区，但 stash 记录仍保留在栈中（可后续再次恢复）：

   # 恢复最新的 stash
   git stash apply# 恢复指定索引的 stash
   git stash apply stash@{1}

恢复后，工作区会回到保存 stash 时的修改状态（包括暂存区的内容）；

若恢复时，当前分支的代码与 stash 中的修改有冲突（如同一文件被修改），Git 会提示冲突，需手动解决（类似合并冲突）。

6.4 删除 stash 记录

# 删除最新的 stash（stash@{0}）
git stash drop# 删除指定索引的 stash
git stash drop stash@{1}# 删除全部stash
git stash clear