Git 团队协作开发流程：Rebase 与 Merge 对比

第五阶段：代码审查与合并 (GitHub 操作)

这一步主要在 GitHub 网页端进行，不涉及命令行：

1. 创建 Pull Request (PR)：在 GitHub 页面上，你会看到提示，点击 "Compare & pull request"。
2. Code Review：你的队友会检查你的代码，可能会提出修改意见。
3. Merge：审查通过后，项目维护者点击 "Squash and merge" 或 "Merge pull request"，你的代码正式进入 main 分支。

常见问题与解决方案

在协作过程中，最容易遇到的几个问题：

1. 冲突 (Merge Conflicts)

• 现象：当你执行 git pull 或在 GitHub 上合并 PR 时，提示 "Conflict"。这意味着你和队友修改了同一个文件的同一行代码，Git 不知道该听谁的。
• 解决：
  1. 打开冲突的文件（代码中会出现 <<<<<<< HEAD 这样的标记）。
  2. 人工判断保留哪段代码，或者两段都改写。
  3. 删除那些特殊符号。
  4. 执行 git add . 和 git commit 重新提交。

2. 推送失败 (Push Rejected)

• 现象：执行 git push 时报错，提示远程仓库包含你本地没有的工作。
• 原因：通常是因为远程分支比你本地的新（比如你队友刚往这个分支推了代码）。
• 解决：先执行 git pull 拉取最新代码，解决可能出现的冲突，然后再 git push。

3. 搞乱了本地环境

• 现象：代码改得乱七八糟，想回到修改前的状态。
• 解决：
  • git checkout . (或 git restore .)：丢弃所有未提交的修改（慎用！会找不回来）。
  • git stash：把当前的修改'藏'起来，让工作区变干净，以后可以用 git stash pop 拿出来。

命令速查表

相比 Merge 更安全的协作方式：Rebase

简单来说，它们都是把一个分支的代码合并到另一个分支，但结果的历史记录（Log）长得完全不一样。

我们可以把 Git 的提交历史想象成一串珍珠项链。

1. Git Merge (合并)：真实的记录者

这是最标准、最安全的方式。

• 原理：Git 会把两个分支的最新快照（Snapshot）以及它们共同的祖先找出来，创建一个新的'合并提交'（Merge Commit）。
• 视觉效果：你的历史记录会像铁路图一样，分叉再汇合，形成一个菱形或环状结构。
• 优点：
  • 诚实：它如实记录了代码发生的一切，包括你们是什么时候分叉的，什么时候合并的。
  • 安全：它不会修改现有的提交记录（Commit ID 不变），不会弄丢历史。
• 缺点：
  • 乱：如果团队人多，频繁 merge，历史记录会变成'蜘蛛网'，很难看清谁在什么时候做了什么。

2. Git Rebase (变基)：完美主义者

Rebase 的意思是'重新设定基底'。

• 原理：Git 会把你当前分支上的所有提交先'暂时拿下来'，然后把你分支的'基底'移动到目标分支的最新位置，最后再把你刚才拿下来的提交一个个重新在此基础上播放一遍。
• 视觉效果：历史记录会变成一条直线，就像你是在大家都改完代码之后，才开始写你这一部分的一样（虽然实际上你是并行开发的）。
• 优点：
  • 整洁：没有分叉，没有多余的'Merge Commit'，项目历史像一本干净的故事书，线性发展。
• 缺点：
  • 欺骗：它修改了历史（Commit ID 会变）。
  • 有风险：如果在公共分支上用，会导致队友的代码同步出错（下面会详细讲）。

核心区别图解（用 ASCII 示意）

假设你从主干 C2 处切出分支开发了 C4，通过 Git 协作：

初始状态：

A---B---C4 (你的分支 feature) / D---E---F---G (主分支 main)

使用 Merge 后：

A---B---C4------H (新的 Merge Commit) / / D---E---F---G-------/ (main)

*结果：保留了分叉结构，多了一个 H 提交。

使用 Rebase 后：

D---E---F---G---A'---B'---C4' (feature 变基到了 main 后面)

*结果：原本的 A、B、C4 被'搬运'到了 G 后面，变成了一点直线。注意：提交 ID 变了，所以叫 A'。

什么时候用 Rebase？（最佳实践）

在团队协作中，推荐遵循 "Local Rebase, Remote Merge" 原则：

✅ 场景一：拉取代码时（推荐！）

当你准备把本地代码 push 上去之前，发现远程 main 分支已经更新了。不要用 git pull (它默认是 fetch + merge)，而是用：git pull --rebase origin main

• 效果：这会把你本地还没推上去的修改，暂时'拿起来'，先把远程最新的代码拉下来垫在底下，再把你修改的放回去。
• 好处：避免了产生无意义的 "Merge branch 'main' of..." 这种提交记录。

✅ 场景二：整理自己的提交

你在开发功能时，可能为了保存进度提交了 10 次（比如 "fix typo", "save work"）。在合并进主分支前，你可以用交互式 rebase (git rebase -i) 把这 10 个提交合并成 1 个漂亮的提交，然后再推送到远程。

❌ 绝对禁止的场景（黄金法则）

永远不要在公共分支（如 main/master）或者别人正在使用的分支上执行 Rebase！

• 原因：Rebase 会改变提交的 ID。如果你 rebase 了 main 分支，而你的队友是基于旧的 main 开发的，当他们想推代码时，Git 会报错，提示历史不一致，这会导致巨大的混乱（通常被称为'Git 灾难'）。

总结建议

1. 对于新手：先坚持用 git merge 和普通的 git pull。虽然历史记录乱一点，但绝对安全，不会丢代码。
2. 对于进阶：
   • 在本地分支（还没 push 给别人的），尽情使用 rebase 来保持历史整洁。
   • 在拉取代码时，尝试使用 git pull --rebase。
   • 在合并回主分支时，GitHub 的 Pull Request 界面通常使用 Merge（或者 Squash and Merge），这没问题。