Git合并分支的几种方案

在 Git 中将当前分支合并到主分支 master有以下几种常见方案，每种方案适用于不同的场景：

1. 普通合并（git merge）

目的：保留完整提交历史，记录分支合并的上下文。
适用场景：常规功能分支合并，需要追溯分支开发过程。

# 切换到主分支
git checkout master

# 将当前分支（如 feature-branch）合并到 master
git merge feature-branch

注释：

• git checkout master：确保操作在主分支上进行。
• git merge：默认生成一个合并提交（若分支历史有分叉），保留原始分支的所有提交记录。
• 结果：主分支的历史中会包含分支的提交记录和合并节点。

2. 快进合并（git merge --ff）

目的：保持线性历史，避免生成合并提交。
适用场景：分支基于主分支最新提交开发，且未产生分叉（无并行修改）。

git checkout master
git merge --ff-only feature-branch

注释：

• --ff-only：仅允许快进合并，如果分支无法直接移动指针（存在分叉），则合并失败。
• 结果：主分支的指针直接移动到分支末端，历史记录保持线性，无合并提交。

3. 非快进合并（git merge --no-ff）

目的：强制生成合并提交，明确标识合并节点。
适用场景：团队协作中需要清晰标记功能分支的合并点。

git checkout master
git merge --no-ff feature-branch

注释：

• --no-ff：即使可以快进，仍生成合并提交。
• 结果：主分支历史中会新增一个合并提交，便于后续追溯分支的合并时间点。

4. 变基合并（git rebase + git merge）

目的：线性化提交历史，避免合并提交。
适用场景：个人分支整理提交记录，追求简洁历史（不适用于已共享的分支）。

# 在功能分支上操作
git checkout feature-branch
git rebase master   # 将功能分支的提交“移植”到主分支的最新提交之后

# 切换到主分支并合并（此时可以快进）
git checkout master
git merge feature-branch

注释：

• git rebase：将分支的提交基变更为主分支的最新提交，重写提交历史（修改提交哈希）。
• 结果：主分支的历史变为线性，无合并提交，但可能影响已发布的提交（需谨慎使用）。

5. 压缩合并（git merge --squash）

目的：将分支的多次提交压缩为一次提交。
适用场景：临时分支或实验性功能分支，仅需记录最终结果。

git checkout master
git merge --squash feature-branch  # 将分支修改合并到暂存区，不自动提交
git commit -m "Squashed: Implement feature X"  # 手动提交压缩后的结果

注释：

• --squash：将分支的所有修改合并到主分支的暂存区，但不保留原始提交记录。
• 结果：主分支仅新增一次提交，内容为分支修改的最终状态。

6. Pull Request/Merge Request（代码平台）

目的：通过协作平台合并分支，支持代码审查和自动化流程。
适用场景：团队协作、开源项目，需代码审核和自动化测试。

步骤：

1. 推送分支到远程仓库：

   git push origin feature-branch
   

2. 在 GitHub/GitLab 等平台创建 Pull Request（PR）或 Merge Request（MR）。
3. 审查代码后，选择合并方式（普通合并、压缩合并等）。

注释：

• 平台操作：合并时可选择保留历史（普通合并）或压缩提交。
• 自动化集成：支持触发 CI/CD 流程，确保合并前通过测试。

7. 强制覆盖合并（git reset --hard）

目的：强制将主分支指向当前分支的最新提交。
适用场景：紧急修复、主分支内容已损坏需彻底替换（高危操作）。

git checkout master
git reset --hard feature-branch  # 强制将 master 指向 feature-branch 的提交
git push origin master --force   # 强制推送覆盖远程分支（慎用！）

注释：

• git reset --hard：丢弃主分支的当前内容，直接指向目标分支的提交。
• 风险：会丢失主分支原有提交，需确保分支内容正确且已备份。

总结

方案	命令/操作	历史记录特点	适用场景
普通合并	git merge	保留完整历史，有合并提交	常规合并
快进合并	git merge --ff-only	线性历史，无合并提交	未分叉的分支
非快进合并	git merge --no-ff	显式合并提交，保留合并节点	团队协作标识合并点
变基合并	git rebase + git merge	线性历史，无合并提交	个人分支整理历史
压缩合并	git merge --squash	单次提交，简化历史	临时分支合并
Pull Request	代码平台操作	灵活选择合并方式	团队协作、代码审核
强制覆盖	git reset --hard	覆盖历史，危险操作	紧急修复或彻底替换内容

• 最佳实践：

  • 团队协作优先使用 非快进合并 或 Pull Request，保留合并上下文。
  • 个人项目可使用 变基合并 或 压缩合并，保持历史简洁。

• 注意事项：

  • 避免在公共分支使用 git rebase 或 git reset --hard，以免影响他人协作。
  • 合并前务必拉取最新代码（git pull），减少冲突概率。

通过上述方案，开发者可根据项目需求灵活选择合并策略，既能保留必要的历史信息，又能维护代码库的整洁性。(本文章仅供个人学习参考记录使用)