前往小程序,Get更优阅读体验!
立即前往
发布
社区首页 >专栏 >git-merge 和 git-rebase 原理解析与实践分享

git-merge 和 git-rebase 原理解析与实践分享

原创
作者头像
Lorin 洛林
修改2025-01-22 15:38:14
修改2025-01-22 15:38:14
1340
举报

前言

  • Git 提供了两种代码整合方式:git-mergegit-rebase。虽然它们都能实现将代码从一个分支整合到另一个分支的目的,但在具体实践中,它们的使用场景和效果却有很大差异。本文将从原理、使用场景到实际选择,全面解析这两种方式的适用性。
  • 现在假设在 master 分支上有的新提交与你正在开发的 feature 相关。需要将新提交合并到你的 feature 分支中,你可以有两个选择:merge 或者 rebase。我们分别看看最后的效果。

git-mergegit-rebase

git-merge

  • git-merge 是一种将两个分支合并的方式,它会保留两条分支的提交历史,并在合并后生成一个新的合并提交(merge commit)。

两种合并方式

快速合并
  • 如上图示例一,dev分支和branch1分支有相同的直系,branch1只是在dev上新增,此时只需要将branch1的内容合并进来,将head移动到当前branch1的head。
第三方合并
  • 第三方合并稍微复杂,它会寻找branch1和dev分支的公有节点,如上图的c6,然后将branch1分支的变更内容合并到dev分支上,并生成新的 commit 节点,如上图c1。

如何合并

  • 我们可以使用以下代码进行合并文章开头提到的场景:
代码语言:txt
复制
git checkout feature
git merge master

或者
git merge feature master
  • 上述命令会找到 master 和 feature 的公有节点,然后将 master 的变更内容合并到 feature 分支并生成新的 commit 节点。
  • 我们可以看到 git-merge 是一种非破坏式的整合,保留了清晰的提交历史便于追溯,但是生成了一次额外的提交。如果master 提交非常活跃,这可能会严重污染你的 feature 分支历史记录。

优缺点

优点
  • 保留完整的分支历史,清晰展现分支的合并轨迹。
  • 方便调试和审查,尤其是多人协作时。
缺点
  • 生成额外的 merge commit。
  • 提交历史可能变得冗杂,甚至污染你的提交历史,尤其是频繁合并的情况下。

git-rebase

  • git-rebase 是一种将一个分支的提交 重新应用到另一个分支上的方式。它会将提交历史整理为一条线性记录,消除分支合并点。

如何合并

  • 我们可以使用以下代码进行合并文章开头提到的场景:
代码语言:txt
复制
git checkout feature
git rebase master
  • 上述命令会进行变基操作,将 feature 的提交重新应用到 main 的最新提交之后,生成类似于 feature 分支新的提交历史(commit id 不同)。
  • 可以看到最后生成的提交历史记录呈线性,非常的直观,但是由于 rebase 存在安全性问题,即会重写历史提交记录生成新的提交记录,强烈不建议在共享分支上进行此操作。

优缺点

优点
  • 提交历史更加整洁,线性结构便于阅读和理解。
  • 适合在共享代码之前清理提交历史。
缺点
  • 如果多人协作,不当使用可能导致历史冲突(尤其是推送到远程后再修改历史)。

使用场景

git-merge

多人协作开发

  • 当团队成员并行开发多个功能分支时,合并分支后保留完整的提交历史有助于追溯问题。

解决冲突时需要上下文

  • merge 的历史结构包含分支的完整关系,便于在冲突发生时分析问题来源。

git-rebase

  • 我们可以根据实际情况使用 git-rebase ,但请遵守一个黄金法则:不要在已经推送到远程的分支上使用 rebase,否则可能导致其他开发者的分支失效。

整理提交历史

  • 当功能分支包含多个琐碎的提交时,可以通过 rebase 将其整理为一个清晰的提交序列。

保持提交历史线性

  • 如果项目对提交历史的整洁度有高要求(例如开源项目),可以使用 rebase 避免多余的合并提交。

总结

  • git-merge 和 git-rebase 是 Git 中强大的工具,选择合适的操作方式能够有效提高协作效率和代码维护性。
  • 最佳实践建议:团队协作开发中,在满足团队要求的情况下,建议使用 merge 对共享分支合并代码,对于本地分支的代码合并可以适当的采用 rebase 保证代码提交历史的线性和清晰。

个人简介

👋 你好,我是 Lorin 洛林,一位 Java 后端技术开发者!座右铭:Technology has the power to make the world a better place.

🚀 我对技术的热情是我不断学习和分享的动力。我的博客是一个关于Java生态系统、后端开发和最新技术趋势的地方。

🧠 作为一个 Java 后端技术爱好者,我不仅热衷于探索语言的新特性和技术的深度,还热衷于分享我的见解和最佳实践。我相信知识的分享和社区合作可以帮助我们共同成长。

💡 在我的博客上,你将找到关于Java核心概念、JVM 底层技术、常用框架如Spring和Mybatis 、MySQL等数据库管理、RabbitMQ、Rocketmq等消息中间件、性能优化等内容的深入文章。我也将分享一些编程技巧和解决问题的方法,以帮助你更好地掌握Java编程。

🌐 我鼓励互动和建立社区,因此请留下你的问题、建议或主题请求,让我知道你感兴趣的内容。此外,我将分享最新的互联网和技术资讯,以确保你与技术世界的最新发展保持联系。我期待与你一起在技术之路上前进,一起探讨技术世界的无限可能性。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • git-merge 和 git-rebase
    • git-merge
      • 两种合并方式
      • 如何合并
      • 优缺点
    • git-rebase
      • 如何合并
      • 优缺点
  • 使用场景
    • git-merge
      • 多人协作开发
      • 解决冲突时需要上下文
    • git-rebase
      • 整理提交历史
      • 保持提交历史线性
  • 总结
  • 个人简介
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档