当前位置：首页 > wzjs >正文

网站开发岗位简介网站建设艾瑞市场分析

wzjs 2025/9/10 6:18:00

网站开发岗位简介,网站建设艾瑞市场分析,wordpress centos,手机网站开发升上去一、前言对于git rebase 一直不太了解,这几天想着提高下git提交质量,就发现了这个好用的指令,顺便记录一下,好加深记忆贴出官方文档以便大家进一步学习 Git 二、rebase是作用 rebase 官方解释为变基,可以理解为移动你的分支根节点,维护一个更好的提交记录。rebase把你当前…

一、前言

对于git rebase 一直不太了解,这几天想着提高下git提交质量,就发现了这个好用的指令,顺便记录一下,好加深记忆

贴出官方文档以便大家进一步学习 Git

二、rebase是作用

rebase 官方解释为变基,可以理解为移动你的分支根节点,维护一个更好的提交记录。rebase把你当前最新分支与其他分支合并时候,会把其他分支的提交记录放在我们当前分支时间线最开始的位置。也就是说,会把我们的提交记录整合在公共分支的后面。
简单来讲,合并本地其他分支为了不产生多余的分叉,及合并记录时可以使用rebase。
接下来我们看一下rebase有哪些应用场景及使用技巧与merge的差异。

三、rebase与merge的差异

rebase 会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
merge 会把公共分支和你当前的 commit 合并在一起，形成一个新的 commit 提交。

四、应用场景

你刚入公司，技术leader让你以 master 分支为基础,拉出一个分支进行开发需求。此时 master 分支提交记录为 a、b。你在 dev 分支分别 commit 了2次记录为 e、f ,有其他同事在 master 分支提交了两次记录为 c、d 这个时候你要合并master分支代码。
当前分支状态节点如下图所示:

五、使用git merge 进行合并操作

5.1、结论

如上图所示 merge 会把两个分支合并在一起，形成一个新的 commit 提交记录。
我们发现 coomit 提交记录是把合并的分支记录放到我们当前dev分支记录的后面。
并且coomit 提交记录会产生分叉。

七、使用git rebase 进行合并操作

  $ git rebase master  // 合并master分支代码$ git log --graph --oneline // 查看log点线图// 符号解释:* 表示一个commit， 注意不要管*在哪一条主线上 | 表示分支前进 / 表示分叉 \ 表示合入

7.1、结论

首先，我们发现目前 dev 分支上面的提交记录为 abcdef 并没有像 merge 一样产生新的提交记录
其次 rebase master 分支到 dev 分支, dev 分支的历史记录会添加在 master 分支的后面。
如图所示，历史记录成一条线,非常整洁,最后并没有像使 merge 一样提交记录产生分叉。

八、rebase的使用业务场景

认识到了rebase,让我们来看看有哪些实战场景可以参考使用。

8.1 场景一

经典场景,优化本地提交记录,使其减少分叉。
和上面👆那个经典案例一样,这里就不做重复描述了😁

8.2 场景二

连续性冲突
此时你从master分支拉出一个dev分支来对以v1版本为基础a功能进行需求更改，由于项目经理分功能时,让你的同事也对master分支中的a功能中的某个公共页面a也进行了整改,过一会你同事改完,提交x版本并合并push到了master远程分支上面。此时我们在dev分支完成一次开发提交了v2版本,产品经理过来说,需求有变更,要再做修改,然后我们又以v2的基础上在做修改,并提交为v3版本。过一会测试又提了一个需求建议。我们接着以当前dev分支v3版本为基础做好了整改并commit一个v4版本。到此我们本地假设对页面a修改了三次。同事修改了一次,并push到了远程master上面。那么我们对master分支进行合并到时候就会产生冲突。
简单来讲就是。远程分支 master 对文件a进行了1次 commit ，而别的分支dev对文件A进行了3次commit，但是本地分支dev提交的n次 commit都与master分支的1次commit有冲突，

8.2.1 使用 git rebase 解决冲突

$ git fetch  // 更新本地存储的远程仓库的分支引用
$ git rebase origin/master // 拉去远程分支master中的代码与当前分支合并且变基
// 此时我们会产生第一次冲突,为当前dev分支版本v2中的a页面与远程分支master中的a页面冲突。解决后,根据提示进行 
$ git add .
$ git rebase continue // 继续进行合并
// 此时我们会产生第二次冲突,为当前dev分支版本v3中的a页面与远程分支master中的a页面冲突。解决后,根据提示进行 
$ git add .
$ git rebase continue // 继续进行合并
// 此时我们会产生第三次冲突,为当前dev分支版本v4中的a页面与远程分支master中的a页面冲突。解决后,根据提示进行 
$ git add .
$ git rebase continue // 继续进行合并
// 至此我们使用 rebase 变基完成 可以根据产品需求push到远程dev分支
$ git log --graph --oneline // 查看log点线图
// 符号解释:
* 表示一个commit， 注意不要管*在哪一条主线上 
| 表示分支前进 
/ 表示分叉 
\ 表示合入

8.3 结论

1、不会因为像使用 merge 时合代码时遇到冲突产生新的提交记录

2、用 merge 只需要解决一次冲突即,简单粗暴,而用 rebase 的时候，需要依次解决每次的冲突，才可以提交。

3、使用 rebase 提交记录不会分叉,一条线干净整洁

4、冲突解决完之后，使用 git add 来标记冲突已解决，最后执行git rebase --continue继续。如果中间遇到某个补丁不需要应用，可以用下面命令忽略：git rebase --skip

5、如果想回到 rebase 执行之前的状态，可以执行：git rebase --abort

8.4 场景三

你开发的一个需求产品反复更改,导致你的commit记录多次重复功能点
在日常开发中,难免有重复的commit提交记录.这时候我们想优化一下提交记录该如何做呢

当前分支状态节点如下图所示:

使用git rebase 进行commit记录合并操作

 $ git rebase -i HEAD~x  // i(interactive)交互，HEAD~x 代表要合并到距离HEAD最近的几个历史提交,如 HEAD～3就是历史的前3个提交.$ git log --graph --oneline // 查看log点线图// 符号解释:* 表示一个commit， 注意不要管*在哪一条主线上 | 表示分支前进 / 表示分叉 \ 表示合入