git合并代码方法

你合并代码用 merge 还是用 rebase ?

macrozheng 2024年07月08日 14:10 江苏 1人听过
 

以下文章来源于古时的风筝 ,作者风筝

古时的风筝.

写代码是一种爱好,写文章是一种情怀。

图片

mall学习教程官网:macrozheng.com

你们平时合并代码的时候用 merge 还是 rebase?

我问了一圈,发现有些人不仅没用过 rebase,而且根本就没听说过。别慌,不要紧,没有 rebase 也不影响开发,不影响合并,不影响发版!

我用 Git 很长时间也一直根本没听过 rebase 为何物,只知道合并分支就是 merge ,直到有一个新入职的同事跟我说:“为什么合并分支不用 rebase 呢?我之前公司都用 rebase,不怎么用merge。"

在那之后,我还头一次听说 rebase 这个命令。

只有在涉及到分支合并的时候才谈到 merge 和 rebase,如果没有合并的需求,那怎么整都无所谓,就像我自己的小产品,从头到尾都只有个 main 分支,开发人只有我自己,也没有冲突一说,有时候写好几天都不带push一次的。

用到分支合并基本都是多人协作的团队项目,通常会有一个主分支,然后有开发分支,有时候还会有一些临时的 feature 分支。

merge 合并分支

同一个分支也可能出现 merge 的情况,例如我这边有一个老项目平时基本上没其他人动,所以我在修改这个项目的时候基本上想不起来要先pull 一下,当然了,这是一个非常不好的习惯,所以有时候一push代码,发现有人竟然提交新代码上去了,所以这种情况下就自动 merge 一下。

今天主要讨论的是分支合并时的 merge。

下图是 merge 合并分支时前后版本变化的情况。

图片

merge 会创建一个新的合并提交,将两个分支的历史记录保留在一起。

它的特点就是日志保存完整,不管你之前合并进来的那个版本有多少个提交历史,都会被完整的合并到目标分支。

以下是使用 merge 合并后的主分支 Graph 情况,看上去是不是有点乱。

图片

这或许是一个对你有用的开源项目,mall项目是一套基于 SpringBoot3 + JDK 17 + Vue 实现的电商系统(Github标星60K),采用Docker容器化部署,后端支持多模块和微服务架构。包括前台商城项目和后台管理系统,能支持完整的订单流程!涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能!

  • Boot项目:https://github.com/macrozheng/mall
  • Cloud项目:https://github.com/macrozheng/mall-swarm
  • 视频教程:https://www.macrozheng.com/video/

项目演示:图片

假设有两个分支,main 和 dev分支,在 dev 分支上开发,然后合并到 main 分支,合并的大致流程如下。

git checkout main
git pull origin main
git merge dev
# 解决冲突后
git commit -m "Merge dev into main"
git push origin main

Rebase 合并分支

rebase 会将分支上的更改重新应用在目标分支上,重写提交历史。

图片image.png

rebase 方式提交的版本历史是线性的,不会创建新的合并提交,历史记录非常干净。

同样地,假设当前有两个分支,main 和 dev,用 rebase 方式合并分支的大致流程如下。

git checkout dev
git pull origin dev
git rebase main
# 解决冲突后
git rebase --continue
git push origin dev --force

合并压缩

在rebase 的时候还可以使用 squash 参数来压缩提交记录,例如下图,Feature 1 分支的 A、B、C 三个提交记录,使用 rebase squash 后会在主分支变为一个提交记录 F。

图片

使用方式如下,git rebase -i HEAD~3 命令准备压缩最近的3次提交,然后在编辑模式下将pick 改为 squash,最后推送到远端仓库。

适合那种

git checkout dev
git rebase -i HEAD~3
# 进入编辑模式后,修改 `pick` 为 `squash`
# 保存并关闭编辑器后,编辑新的提交信息并保存
git push origin dev --force

选择使用哪种方法

具体使用哪种方式合并要根据场景和习惯而定,没有绝对的好坏。

使用 merge,如果你希望保留分支的历史记录,并且不介意有合并提交。适用于团队合作时保留每个人的工作记录。

使用 rebase,如果你希望保持提交历史的简洁和线性,适用于希望干净历史的项目。

有些公司规定只能用 rebase,它更适合那种只有单一版本的项目,只有一个主分支一直向前推进,且没有多个分支并行的情况,例如一个产品既要维护2.x 版本又要维护3.x版本,那用 rebase就不合适了。

之前 Vue 项目就是用 rebase 方式合并分支的。

图片

Github上标星60K的电商实战项目mall,全套 视频教程(2023最新版) 已更新完毕!全套教程约40小时,共113期,通过这套教程你可以拥有一个涵盖主流Java技术栈的完整项目经验,同时提高自己独立开发一个项目的能力,下面是项目的整体架构图,感兴趣的小伙伴可以点击链接 mall视频教程 加入学习。

图片

整套 视频教程 的内容还是非常完善的,涵盖了mall项目最佳学习路线、整体框架搭建、业务与技术实现全方位解析、线上Docker环境部署、微服务项目学习等内容,你也可以点击链接 mall视频教程 了解更多内容。

推荐阅读

macrozheng
专注Java技术分享,解析优质开源项目。涵盖SpringBoot、SpringCloud、Docker、K8S等实用技术,作者Github开源项目mall(50K+Star)。
297篇原创内容

图片

阅读 9056
留言 3
写留言
  •  
    我就习惯这么干、定期用rebase整理后结合no-ff再合并,历史记录舒服多了
     
     
  •  
    用git五年了,从来不用命令的我路过此地。。
     
     
  •  
    习惯用git小乌龟了,都是先fetch再rebase
     
     
已无更多数据
 
 
 
 
 
 
 
 
posted @ 2024-07-08 19:48  技术颜良  阅读(8)  评论(0编辑  收藏  举报