兄弟，rebase 了解一下？

作者：Lxlxxx 链接：https://juejin.cn/post/7192823689426468919

前言

Git 作为我们日常开发代码的版本管理，开发分支的管理方面起着很大作用，我们开发过程中分支通常有生产、预发、测试、开发这几个分支，我们会根据项目进行的某个阶段，将代码提交到某个版本上，正常流程是先开发 —>测试 —>预发—>生产，但是通常会有很多版本，有先后上线顺序，并且我们的开发人员也会是多个，在各种因素下项目的开发版本远程分支，以及开发人员的本地分支管理就由为的关键。

普通开发流程

正常一个版本需要经过的几个阶段，分别是 dev、test、uat、master，我们通过下面流程图这么做是没什么问题的，每个阶段去将从 master 拉取的版本分支，push到对应的分支上进行发布，正常预发和生产环境的代码应该保持一致，test 分支由于会有多个版本并行开发，所以代码和预发和生产比起来会有一些不一样。

多版本并行开发

在多个版本并非开发的时候，对分支的管理就不像上面那么简单了，涉及到多个 version，这些版本的上线时间节点也是不同的，意味着上 test 和 uat 的时间节点也是不一样的。

这里涉及到多种情况

1. 在后端开发人员较少的情况下，通常 2-3人 为例，完全可以从 master 拉取一个开发分支，分支格式已服务名+上线时间，例如 xxx_20230130 这个本地分支，后端开发人员一起在这个分支上进行并行开发，开发阶段将自己的本地分支 merge 到 dev 分支，因为只有 2-3人 所以冲突解决起来还好，有冲突解决冲突。

2. 后端开发人员较多的情况，通常在 5-8人 为例，这时候从 master 分支拉取分支，分支格式就需要已 服务名+姓名缩写+上线时间来命名，尽量每个人在自己命名的分支下进行开发，这样在开发阶段本地测试的时候，可以做到相互不影响，但是在 merge 到远程分支的时候，解决代码冲突的时候需要认真仔细一些，这种活还是交给心细的人来做吧，测试的时候也需要根据版本上线的优先级进行测试。

3. 版本比较多的情况，比如一个月会有 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 这个命令，核心理念就是“变基”。

1. 由上图可看见，通过 reabse 命令将 feature 分支延续到了 master 分支后面。

2. 在多人开发过程中，如果其他人在 master 进行 commit，这个时候你在 feature 分支提交了几个 commit，这时候你使用 rebase 命令，会将你的 commit 提交记录放在 master 的 commit 记录的后面，而 merge 就会将不同分支的 commit 合并成一个新的 commit 记录，这就是 merge 和 rebase 的不同点。

3. 本地 feature 分支和远端的 master 分支如果是同一条分支的话，可以使用 rebase，保证 commit 的记录的清晰性，这个很关键！

⚠️不要在公共分支使用 rebase命令，这样会污染公共分支，这样公共分支就会存在你的 commit 记录，别人拉取的时候会存在你的最新的 commit 记录。

总结

在开发中不仅需要代码质量高，在版本管理上也是由为的重要，上线前漏掉代码的事情，相信大家都曾遇到过，但是这种事情是很危险⚠️的，希望此文章能给大家在日常代码版本管理中提交警惕，合理合并分支。