前言

本文图片来自网络

git merge

(下方运用对称的叙述手段来更好的说明)

首先, 需要明白的是

merge本质上是将其它分支从分叉点(如果两分支都有基于此分叉点的提交)至其最后的提交拿过来到我们的当前分支, diff对比后, 在全局视野下产生一个全新的commit项, 并移动当前分支的分支名至这个全新的commit项。

  • 若diff需要处理冲突, 则新提交中包含的是所取分支的从分叉点至末尾的非全部内容。
  • 若diff无需处理冲突, 则新提交中可能包含的是所取分支的从分叉点至末尾的全部内容。(因为某些新内容在两个分支上存在不谋而和的可能, 我们实际添加的仅是其它分支相比于当前新增的内容)
    • 若diff无需处理冲突, 且两分支基于分叉点的所有新提交完全不重复, 则新提交中包含的是所取分支的从分叉点至末尾的全部内容。

tips: 我们的merge本质是从其它分支那东西过来。 因此执行merge命令前, 要注意我们当前所在的分支。

merge本质上是将其它分支从分叉点(如国两分支只有一方存在基于此分叉点的提交)至其最后的提交拿过来到我们的当前分支, 则merge会按其默认的快进式提交, 在全局视野下不会产生任何新的commit项, 而是直接移动当前分支的分支名。

  • 若强制merge时的提交为非快进式提交的话(指定参数--no--ff), 就一定会在全局视野下产生一个全新的commit项, 在此情况下此单一的全新提交中所包含的内容是从分叉点至最新提交之间的所有更改内容(如例图中的C5)。 (一般可用于主分支处理pr时, 可以参考文章<<GitHub Merge Pull request 的三个选项说明>>其中有一部分对非快进式提交进行了运用)

快进式提交

非快进式提交

至于更详细的细节以及相关的命令, 可以自行查阅官方手册的书籍。 此处主要帮助你理解, 对于使用上的细节不做过多篇幅。

git rebase

rebase本质上是将当前分支从分叉点至其最后的提交拿到其它分支, 整个过程是分支的重定向, 不会产生新的提交, 对于分支名的移动, 也不是基于原有分支的移动, 而是基于其它分支所在基准的变基准移动。

当然, rebase是很强大的, 能做的事情还包括了分支历史的修订, 不过具体篇幅不再此过多书写, 可自行移步官方文档书籍中的对应章节。

总结

在项目中, 我们一般会根据不同的情况, 来选择不同的命令使用。 而由于git rebase 的强大, 造成很多初级程序员对此有不可控的畏惧感, 从而莫名引起一股不允许使用rebase的潮流(在我看来, 这潮流简直太low了)。

但这里我想说的是, 大可不必, 尽可放开去用就好了(前提是你熟悉当前项目的工作流, 明白自己在做什么)。