Git合并删除原理

如果有 A 分支，从 A 分支上新建 B 分支，B 分支做出修改合并到 A 分支，然后删除 B 分支，A 分支还有没有 B 分支修改的内容

关键原理：合并的本质是提交历史的整合

1. 合并操作会将 B 的修改永久写入 A 的历史
当 B 分支的修改被合并到 A 分支时，Git 会做以下两件事之一：
快进合并（Fast-Forward）（若 A 分支未更新）：直接将 A 分支的指针移动到 B 分支的最新提交。
生成合并提交（若 A 分支有更新）：创建一个新的合并提交，将 A 和 B 的修改整合到一起。

无论哪种方式，B 分支的修改内容都会成为 A 分支历史的一部分。

2. 删除 B 分支只是删除指针，不影响已合并的提交
分支本质是提交的指针。删除 B 分支后，仅仅是删除了指向 B 分支最新提交的“标签”，已合并到 A 的提交仍然被 A 分支的提交历史引用，因此这些修改会永久保留。

示例流程：

1. 从 A 创建 B 分支：
```bash
A: C1 → C2
B: C1 → C2（初始状态）
```

2. 在 B 分支提交修改：
```bash
B: C1 → C2 → C3（新增修改）
```

3. 将 B 合并到 A：
```bash
# 合并后，A 分支会包含 C3 的修改
A: C1 → C2 → C3（快进合并）
# 或
A: C1 → C2 → C4（合并提交，包含 C3 的内容）
```

4. 删除 B 分支：
```bash
# 删除 B 后，A 仍保留 C3 或 C4 的内容
```

验证方法：

- **查看 A 分支的提交历史**：
```bash
git checkout A
git log --oneline
# 可以看到 B 分支的提交（如 C3 或合并提交 C4）
```

- **检查文件内容**：
B 分支修改的文件在 A 分支中仍然存在。

---

### 特殊情况：**未合并的提交会丢失**
如果 B 分支有未合并到 A 的提交（例如合并后又新增了提交），这些提交会随着 B 分支的删除变为“悬空对象”，最终可能被 Git 垃圾回收清理。例如：
```bash
# 合并后，B 分支继续开发：
B: C1 → C2 → C3（已合并到 A） → C4（未合并）
# 删除 B 后，C4 会丢失，但 C3 仍然在 A 分支中保留。
```