兄弟,rebase 了解一下?
共 2028字,需浏览 5分钟
· 2023-11-09
作者:Lxlxxx 链接:https://juejin.cn/post/7192823689426468919
前言
Git 作为我们日常开发代码的版本管理,开发分支的管理方面起着很大作用,我们开发过程中分支通常有生产、预发、测试、开发这几个分支,我们会根据项目进行的某个阶段,将代码提交到某个版本上,正常流程是先开发 —>测试 —>预发—>生产,但是通常会有很多版本,有先后上线顺序,并且我们的开发人员也会是多个,在各种因素下项目的开发版本远程分支,以及开发人员的本地分支管理就由为的关键。
普通开发流程
正常一个版本需要经过的几个阶段,分别是 dev、test、uat、master,我们通过下面流程图这么做是没什么问题的,每个阶段去将从 master 拉取的版本分支,push到对应的分支上进行发布,正常预发和生产环境的代码应该保持一致,test 分支由于会有多个版本并行开发,所以代码和预发和生产比起来会有一些不一样。
多版本并行开发
在多个版本并非开发的时候,对分支的管理就不像上面那么简单了,涉及到多个 version,这些版本的上线时间节点也是不同的,意味着上 test 和 uat 的时间节点也是不一样的。
这里涉及到多种情况
在后端开发人员较少的情况下,通常 2-3人 为例,完全可以从 master 拉取一个开发分支,分支格式已服务名+上线时间,例如 xxx_20230130 这个本地分支,后端开发人员一起在这个分支上进行并行开发,开发阶段将自己的本地分支 merge 到 dev 分支,因为只有 2-3人 所以冲突解决起来还好,有冲突解决冲突。
后端开发人员较多的情况,通常在 5-8人 为例,这时候从 master 分支拉取分支,分支格式就需要已 服务名+姓名缩写+上线时间来命名,尽量每个人在自己命名的分支下进行开发,这样在开发阶段本地测试的时候,可以做到相互不影响,但是在 merge 到远程分支的时候,解决代码冲突的时候需要认真仔细一些,这种活还是交给心细的人来做吧,测试的时候也需要根据版本上线的优先级进行测试。
版本比较多的情况,比如一个月会有 4-5 个版本的开发,那么上线时间也是分 4-5 个节点,这样就需要每次从先发上线的远程分支,将代码 merge 到下个版本的本地开发分支上,以此类推。
Git merge
作为 git 合并分支的命令,也是在日常开发过程中经常用到的一个命令,通常我们会将拥有最新代码的一个版本merge到较老的一个版本,实现版本同步。
大体就是这么一个步骤,从刚开始的公共分支,变为 master 和 feature 分支, 通过 git merge master 命令将master 分支 merge 到 feature 分支。Merge 命令会将前面 featrue 分支所有的 commit 提交全部合并为一个新的commit 提交。⚠️这里只有会在产生冲突的时候,才能产生新的 commit 记录。
可以理解为 git pull =git fetch +git merge,拉取最新的远程分支,然后将这个分支合并到另一个分支。
在公司开发的时候,通常大家喜欢这个命令,因为简单粗暴,直接将其他分支合并到自己分支,简单好理解。
Git rebase
作为自己的个人喜好,比较喜欢 rebase 这个命令,核心理念就是“变基”。
由上图可看见,通过 reabse 命令将 feature 分支延续到了 master 分支后面。
在多人开发过程中,如果其他人在 master 进行 commit,这个时候你在 feature 分支提交了几个 commit,这时候你使用 rebase 命令,会将你的 commit 提交记录放在 master 的 commit 记录的后面,而 merge 就会将不同分支的 commit 合并成一个新的 commit 记录,这就是 merge 和 rebase 的不同点。
本地 feature 分支和远端的 master 分支如果是同一条分支的话,可以使用 rebase,保证 commit 的记录的清晰性,这个很关键!
⚠️不要在公共分支使用 rebase命令,这样会污染公共分支,这样公共分支就会存在你的 commit 记录,别人拉取的时候会存在你的最新的 commit 记录。
总结
在开发中不仅需要代码质量高,在版本管理上也是由为的重要,上线前漏掉代码的事情,相信大家都曾遇到过,但是这种事情是很危险⚠️的,希望此文章能给大家在日常代码版本管理中提交警惕,合理合并分支。