Git 分支合并

Merge（合并）

Merge 是 Git 中最常用的分支合并方式之一。当你想要将一个分支的更改合并到另一个分支时，你可以使用 Merge 操作。

合并步骤：

通常是从开发分支往主分支上合并代码的时候用 merge

1、git checkout master，确保当前在要接受更改的目标分支上（通常是主分支）。
2、git merge feature，将开发分支的更改合并到目标分支。

# 合并前
A —— B —— C             master
     └── D —— E         feature

# 合并后
A —— B —— C —— F

优点：

• 保留分支历史: Merge 会将源分支的整个历史记录合并到目标分支，因此你可以清晰地看到每个分支的更改历史。
• 非破坏性操作: Merge 操作不会改写提交历史，因此在团队协作中更为安全，不容易丢失提交内容。

缺点：

• 冗余提交: Merge 会产生一系列冗余的 Merge 提交，可能会让提交历史变得复杂。
• 分支图表混乱: 当存在大量 Merge 提交时，分支图表可能会变得凌乱难读，不够整洁。

Rebase（变基）

Rebase 是另一种用于合并分支的方法。当执行 rebase 操作时，git 会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。

变基步骤：

通常是在开发分支拉取主分支的最新提交记录的时候用 rebase

1、git checkout feature，确保当前在待变基分支上（通常是开发分支）。
2、git rebase master，将基分支上的更改同步到待变基分支上。

# 变基前
A —— B —— C             master（基分支）
     └── D —— E         feature（待变基分支）

# 变基后
A —— B —— C —— D —— E

优点：

• 简洁的提交历史: Rebase 将源分支的更改整洁地复制到目标分支上，使得提交历史看起来更加线性和清晰。
• 更容易解决冲突: 由于每个提交逐个应用，Rebase 可以更容易地解决合并冲突，因为你可以在每个提交上解决冲突，而不是在整个分支上解决冲突。

缺点：

• 潜在风险: 变基操作会改写提交历史，如果在错误的分支上执行 Rebase，可能会导致提交丢失或冲突变得更加复杂。
• 不适合公共分支: Rebase 应该仅在本地分支上执行，不适合用于公共分支，因为它会改变提交历史，导致其他团队成员的工作受到干扰。

对比：Merge vs Rebase

在选择使用 Merge 还是 Rebase 时，取决于项目的特定需求和团队的工作流程。

• 如果你希望保留分支的完整历史，以及清晰地查看每个分支的更改过程，那么使用 Merge 是一个不错的选择。
• 如果你希望提交历史保持整洁，更像是线性开发，并且在合并时更容易解决冲突，那么 Rebase 可能更适合你。

一般来说，在合并公共分支（如主分支）时，应该使用 Merge，因为 Rebase 可能会产生潜在的冲突和提交丢失。
而在合并个人分支或本地分支时，Rebase 可以帮助你保持提交历史的整洁性，提供更好的开发体验。