git之Fast-forward模式:

1. 问题
git merge branch 没有产生新的提交信息，而是直接将 dev branch 的提交信息直接迁移过去。如何才能 merge branch 的时候，产生一次新的提交呢？  

2. 原因
为什么直接 merge 没有产生一次新的提交呢？
如果我们的祖先分支以 master 为例，再 checkout 一个新的分支（bugfix）后，产生了新的提交，与此同时，其他的开发分支没有往 master 合并新的提交。
这样，新的分支与 master 分支的最新提交历史是共同的祖先。但这种模式下，删除分支后，会丢掉分支信息。
此时，merge bugfix 分支后， master 拥有 bugfix 全部的提交，所以当合并到master 分支后，master 的 HEAD 会直接指向最新的 bugfix 提交历史上。不会产生新的提交。git 采用的模式即称为 fast-forward 模式（快进模式）  

3. 解决方案
在合并的时候，我们可以禁用 fast-forward 这种合并策略即可。操作指令如下：
# --no-ff 即 no-fast-forward 禁用快进模式
$ git merge --no-ff -m "merge with no-ff" dev  //这里将 dev 分支合并到 master 分支，同时启用 --no-ff 模式，这样就可以在master分支上看到一条新的合并记录




git之ort策略:
在实际使用中，查看git log 会发现：merge dev: Merge made by the 'ort' strategy，一时不知道这个ort策略是干啥的，所以记录一下
ort 策略是 Git 发布v2.33.0 版本时新增的一种合并策略。
ort 策略实际上是此前 recursive 策略（与之相对的另一种通常是 fast-forward策略）的重构，解决了一些功能问题和性能问题。
GitHub 报告称 merge-ort 能够在有许多文件重命名场景的合并过程中加速超过 500 倍，在一些具有 rebase 操作的情况能加速 9000 倍。总而言之，这个 merge-ort 策略稳定地比现有的合并代码方案更高效。

原文:
Git 2.33 brings the latest patches around geometric repacking, "merge-ort" as a new merge strategy for handling Git merges across branches, and a number of bitmap-related optimizations. There is also the usual assortment of fixes and smaller items.
Git's new merge-ort strategy is a scratch rewrite of its recursive strategy but addresses correctness and performance problems. GitHub reports merge-ort can be as much as a "500x" speed-up for large merges with many renames. Merge-ort for merges in a re-base operation can be a speed-up of over 9000x. The new merge-ort should perform consistently faster than the existing merge code.