不会还有人没有用过git rebase合并分支吧？一文详解git merge与git rebase区别

作者：一灯架构

顺便吆喝一句，技术大厂，前后端测试可捞

在Git中，git merge、git merge --squash 和git rebase是用于合并分支的不同方法。每种方法都有其特定的用法和应用场景。以下是它们的详细区别和应用场景：

1. git merge

功能：

• git merge将两个分支的历史记录合并在一起，创建一个新的合并提交（merge commit）。
• 合并后，两个分支的历史都会保留，分支的提交历史将会有一个合并点。

使用场景：

• 保持完整历史记录：当你希望保留每个分支的完整历史记录，包括所有的提交和合并点时使用git merge。
• 多团队协作：在团队协作开发中，git merge可以清晰地显示出分支的合并历史，有助于追踪变化。

命令示例：

# 切换到主分支
git checkout master

# 合并 feature 分支到 master 分支
git merge feature

优点：

• 保留完整的历史记录和分支结构。
• 解决冲突时可以明确看到冲突的来源。

缺点：

• 可能会产生多次合并提交，使历史记录较为复杂。

2. git merge --squash

功能：

• git merge --squash将一个分支的所有提交压缩成一个单独的提交进行合并。
• 不会产生合并提交，提交历史上只有一个新的提交。

使用场景：

• 简化历史记录：当你希望将一个功能分支的所有工作合并为一个提交，以简化提交历史时使用git merge --squash。
• 合并大量微小提交：如果一个分支上有大量的微小提交，可以使用squash将这些提交压缩成一个，避免提交历史过于冗长。

命令示例：

# 切换到主分支
git checkout master

# 压缩合并 feature 分支的所有提交
git merge --squash feature

# 提交合并后的更改
git commit -m "Squashed commit for feature"

优点：

• 提交历史更加简洁，便于阅读。
• 保持功能开发的独立性，合并时减少了历史记录的噪音。

缺点：

• 失去了详细的提交历史，无法追踪每个单独的提交。
• 也会产生一次提交，不过不是合并提交，就是普通提交。

3. git rebase

功能：

• git rebase将一个分支的所有提交重新应用到另一个分支上，生成新的提交。
• 历史记录将被重写，避免创建合并提交。

使用场景：

• 保持线性历史：当你希望保持提交历史的线性结构，避免合并提交时使用git rebase。
• 整洁的提交历史：在个人开发或小团队合作中，可以使用git rebase保持整洁的提交历史，使日志记录更加简洁明了。

命令示例：

# 切换到 feature 分支
git checkout feature

# 将 feature 分支的提交重新应用到 master 分支上
git rebase master

# 切换到 master 分支
git checkout master

# 合并 feature 分支到 master 分支
git merge feature

优点：

• 保持线性的提交历史，日志记录更整洁。
• 合并后的历史更容易阅读和理解。

缺点：

• 需要解决所有提交的冲突，可能比较繁琐。
• 在公共分支上使用rebase可能导致混乱，建议仅在私有分支上使用。

总结

选择适当的合并方法应根据具体的开发流程和团队需求来决定。git merge适合需要保留完整历史记录的场景，而git merge --squash适合需要简化提交历史的场景，git rebase适合需要简洁线性历史的场景。