使用git这么久,特别是对:git merge 与 git rebase 命令一直没有详细的进行总结,写这篇文章,希望能帮助大家能明白这两个指令的区别和应用场景,感谢哈哈

前言

使用git这么久,特别是对:git merge 与 git rebase 命令一直没有详细的进行总结,写这篇文章,希望能帮助大家能明白这两个指令的区别和应用场景,感谢哈哈

Use git for so long, especially for git merge and git rebase command has not been detailed summary, write this article, hope to help you understand the difference between these two instructions and application scenarios, thank you ha ha

O(∩_∩)O哈哈~

首先我想说的git merge 和 git rebase 都是用于合并分支的命令,但是它们的实现方式不同:

git merge 采用三方合并策略:

会在主分支上创建一个新提交来合并分支上的修改。

这个新的提交会有两个父提交,分别是主分支上的最后一个提交和 FEATURE 分支上的最后一个提交。

划重点😀

git merge工作原理主要包含以下几个步骤:

  1. 查找最新公共祖先(common ancestor)提交。这是要合并的两个分支的最新的共同祖先提交。

  2. 对比公共祖先后的修改。比较公共祖先后的两个分支上的修改,以生成一个包含两个分支所有修改的索引(index)和工作树(working tree)。

  3. 检查是否有冲突。如果对同一个文件的同一个部分做了不同的修改,Git无法 gut merge,需要人工解决冲突后再提交。

  4. 创建新的合并提交(merge commit)。将步骤2生成的结果提交,创建一个新的提交。此提交会指向要合并的两个分支。

  5. 将分支指针移动到新提交。将当前分支(通常为主分支)指向新创建的合并提交。

  6. 删除无效分支(可选)。如果合并分支不再需要,可以选择删除。

    一个示例过程:

    master 分支:A-B-C
    feature 分支:A-D-E1. 公共祖先为 A 提交

​ feature 分支的 D 和 E 提交与 master 分支的 B 和 C 提交均属新修改

​ 无冲突,可以直接合并

​ 创建新提交 F,F 的父提交为 B 和 E

​ master 分支指针移动到提交 F

​ 删除 feature 分支(可选)最终 master 分支的提交历史为:

​ A-B-F可以看到,

通过👆的案例我们终于明白了:git merge 确实是采用了三方合并策略,将两个分支上的修改合并到一个新提交中,并将主分支指向这个新提交,实现分支合并。

😀这种合并方式最大的好处在于维持了分支的提交历史,每个分支的开发过程都在提交历史中得到了保留。但是,分支合并次数多了之后,提交历史会显得很乱,这时可以考虑使用 git rebase 策略进行变基,以便理清提交历史。

git rebase 会将FEATURE分支上的每个提交(commit)取消掉,并且把修改应用到主分支上,使之看起来就像这些修改是在主分支上完成的一样。

这个过程中不会创建新的提交,本地的改变都是在 Feature 分支上的提交上完成的,只是将这些提交移到主分支上的对应位置。

git rebase 工作原理主要是:

将一个分支上的提交(commit)取消,并把修改应用到另一个分支上,使之看起来像这些修改是在该分支上完成的一样。

这是通过以下几个步骤实现的:

  1. 找到当前分支和目标分支(通常是主分支)的最新公共祖先提交。

  2. 从当前分支取出自公共祖先之后的提交,暂存在一个临时区域。

  3. 目标分支的指针移动到公共祖先提交。

  4. 一个一个地取出暂存区域的提交,在目标分支上重复一次,直到所有提交都变基完成。

  5. 删除当前分支。

    一个示例:master:A-B-C
    feature:A-D-E1. 公共祖先A

​ 暂存D和E提交

​ master指针移动到A

​ 在master上重复D和E提交

​ 删除feature分支最后master的提交历史为:

​ A-D-E可以看出,git rebase 会重写提交历史,将feature分支的提交变成在master分支上的提交,

​ 并删除feature分支。

这使得提交历史变得很清晰简洁。

在工作中,常用git rebase的命令有:

  • git rebase master feature:将feature分支变基到master分支上。
  • git rebase -i master~5 master:交互式变基,将最近5条提交压缩为一条提交。可以编辑、删除、重排、合并提交。
  • git rebase --onto master server client:将client分支变基到master分支上,而不变基server分支的修改。
  • git rebase --abort:取消当前变基操作,分支会恢复到变基前的状态。git rebase 需要谨慎使用,因为它会重写提交历史,可能会引起分支与远程仓库的历史不匹配的问题。一般我们会将变基操作保留在本地,不推送到远程仓库。

总结一下区别:

  • git merge 会创建新的合并提交,git rebase 不会创建新的提交,只是将提交从一个分支移到另一个分支。

  • git merge 会在主分支上生成一条合并分支的记录,git rebase 看上去像分支上的所有修改都在主分支上完成的,无合并记录。

  • git merge 每次合并分支时都会对同一个分支做一次整体合并,git rebase 可以分批逐条修改合并。

  • git merge 基本不会改变分支的提交历史,git rebase 会重写历史。

    因此,一般来说:

    用于将分支合并到主分支时使用 git merge 更加适合。

    用于为提交压缩分支历史或将主题分支调整到主分支的最新状态时使用 git rebase 更加合适。

使用git这么久,特别是对:git merge 与 git rebase 命令一直没有详细的进行总结,写这篇文章,希望能帮助大家能明白这两个指令的区别和应用场景,感谢哈哈

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

滚动到顶部