git 合并分支

在 Git 中合并分支是日常开发中最常见的操作之一。以下是详细的步骤、冲突处理以及常用技巧的指南：

一、 基本合并步骤

假设你要将 feature 分支的代码合并到 main（或 master）分支。

1. 切换到目标分支 首先，确保你当前在你要合并进去 的目标分支上（例如 main）。

git checkout main
# 或者使用较新的命令
git switch main

2. 确保目标分支是最新的（推荐） 在合并前，最好先拉取远程目标分支的最新代码，避免与远程代码产生冲突。

git pull origin main

3. 执行合并 将 feature 分支合并到当前的 main 分支。

git merge feature

---

二、 处理合并冲突 (Merge Conflicts)

如果 main 和 feature 分支修改了同一个文件的同一部分，Git 无法自动决定保留哪个，就会产生冲突。

1. 查看冲突 Git 会在终端提示哪些文件有冲突（标红）。你也可以使用以下命令查看：

git status

2. 解决冲突 打开有冲突的文件，你会看到类似以下的标记：

<<<<<<< HEAD
这是 main 分支的代码
=======
这是 feature 分支的代码
>>>>>>> feature

你需要手动编辑文件，删除这些标记（<<<<<<<, =======, >>>>>>>），并修改、保留你最终想要的代码。

3. 标记冲突已解决并提交 修改完所有冲突文件并保存后，将它们添加到暂存区，然后完成合并提交：

git add .
git commit 

(注意：解决冲突后的 commit 通常不需要加 -m，Git 会自动打开编辑器生成默认的合并信息，直接保存关闭即可。)

---

三、 常用的合并选项 (进阶)

根据不同的需求，你可以使用不同的参数来控制合并行为：

1. 保留分支历史 (--no-ff)

默认情况下，如果 main 分支在分叉后没有新的提交，Git 会执行 "Fast-forward"（快进）合并。这会导致 feature 分支的提交历史直接混入 main，在历史线上看不出曾经有过一个分支。 使用 --no-ff 会强制创建一个合并提交 (Merge Commit)，保留清晰的分支拓扑结构。

git merge --no-ff feature -m "Merge feature branch into main"

2. 压缩提交 (--squash)

如果 feature 分支有很多细碎的提交（如 "fix typo", "update"），你想把它们压缩成一个提交 再合并到 main，可以使用 --squash。

git merge --squash feature

注意：执行后，代码会合并到暂存区，但*不会自动提交 。你需要手动执行 git commit -m "你的提交信息"。*

3. 放弃合并 (--abort)

如果你在合并过程中发现冲突太多，或者改主意了，想要撤销这次合并操作，恢复到合并前的干净状态：

git merge --abort

(注意：这只有在合并发生冲突、尚未完成最终 commit 时才有效。)

---

四、 合并前的最佳实践与注意事项

1. 保持工作区干净 ：在切换分支和合并前，确保当前分支的修改已经提交（commit）或暂存（stash），避免代码丢失或带入其他分支。

   git stash       # 临时保存未提交的修改
   # ... 执行合并操作 ...
   git stash pop   # 恢复修改

2. 先 Rebase 再 Merge（团队常用） ：很多团队喜欢先在 feature 分支上执行 git rebase main，把 feature 的基底变基到 main 的最新节点，让提交历史变成一条直线；然后再切换回 main 执行 git merge feature，这样 Git 历史记录会非常干净清晰。

如果你在合并时遇到了具体的报错信息，或者想了解某种特定的合并场景（如 cherry-pick、rebase），可以随时告诉我！