在 GitHub 上处理 Pull Requests（PRs）时，有三种主要的合并策略：创建合并提交（Merge Commit）、挤压合并（Squash and Merge）、变基合并（Rebase and Merge）。下面简要解释每种策略的特点及其区别：

1. 创建合并提交（Merge Commit）

• 操作：当你选择创建合并提交时，GitHub 会创建一个新的合并提交来将 PR 的更改合并到基分支（如 main 或 master）。这个合并提交会包含一个特殊的提交信息，通常包括一个指向 PR 的引用。
• 结果：在基分支的提交历史中，PR 的所有提交都将被保留，并附加一个额外的合并提交。这保持了完整的历史记录和PR的独立性。
• 适用场景：当你想保留对 PR 的每一次单独提交的完整历史时。

2. 挤压合并（Squash and Merge）

• 操作：挤压合并会将 PR 中的所有提交合并成一个单独的提交，然后将这个提交合并到基分支。
• 结果：基分支的提交历史更简洁，因为它只包含一个代表整个 PR 的提交。但这意味着PR中原始提交的细节被压缩。
• 适用场景：适用于PR包含许多小的、渐进的更改，但你想在基分支上保持一份干净、未混杂的历史记录。

3. 变基合并（Rebase and Merge）

• 操作：变基合并首先会将 PR 的提交历史变基到目标分支的最新提交上，然后将这些提交直接加入到基分支，而不创建额外的合并提交。
• 结果：这在基分支上产生一条线性的提交历史，但不会保留 PR 作为独立实体的信息。
• 适用场景：当你希望保持线性历史且避免合并提交时。这通常适用于较小的、清晰的更改。

总结

• 创建合并提交保留了所有的提交历史和PR的独立性，增加了一个额外的合并提交。
• 挤压合并将PR的所有提交压缩成一个单独的提交，使历史更干净。
• 变基合并保持了线性的提交历史，但不会创建合并提交。

选择哪种策略取决于你的项目团队如何希望管理其版本控制历史的清晰度和连贯性。