**命名警告：**我不建议将其称为“线性历史”，因为没有上下文几乎总是意味着根本没有合并提交。

您试图实现的通常被称为“半线性合并”或“重设基础，合并”策略。这提供了“气泡”功能，这些气泡在日志中线性显示。请注意，当功能分支只有一个提交时，有些人允许跳过合并提交，因为在功能上，结果图中没有信息丢失。你应该决定是否允许这样做。（出于一致性的考虑，我个人的偏好是不允许这样做。但这意味着我们最终会出现很多微小的一次提交+一次合并提交气泡，这并不困扰我。）
至于如何实现这一点，我不推荐您提出的别名想法。有太多的场景，您可能希望在本地回购的日常工作中快速进行合并。
相反，我首先倾向于在服务器端强制执行策略，如果这不可能，那么您可以尝试使用钩子。对于服务器端实现，here's an answer讨论了流行的工具及其与此策略相关的功能。（目前，Azure DevOps和Bitbucket都可以开箱即用地实施这一点。）如果您使用的工具没有内置支持，请考虑实现某种门控签入，在允许合并完成（或推送）之前，验证源分支是否与目标完全更新。有很多方法可以进行检查，其中一种可能是（使用Bash）：

# return the target branch tip commit if it passes, nothing otherwise:

git rev-list <source-branch> | grep $(git rev-parse <target-branch>)

关于本声明的注意事项：
我们都需要独立于其他分支提交到主分支，因此基于限制对主分支的访问或代码审查的解决方案并没有真正的帮助。
您仍然可以强制执行Pull Request完成策略，而无需其他人批准您的代码。例如，在Azure DevOps中，您需要PR将分支合并到main中，然后只允许半线性合并。AzDO将自动为您重新设置基础（如果需要），然后创建合并提交，您仍然不需要涉及其他人。我很确定Bitbucket也有这种开箱即用的功能。使用GL或GH时，您需要MR/PR，但允许自行完成，并打开门控签入，只有在完全更新时才允许您完成。
如果您在本地合并到main并直接推送远程main，则另一种机制将使用Git hooks。也许pre-merge或pre-push挂钩最有效。在钩子内部，您可以查看main的HEAD提交，并确保以下为真：
1.这是一个合并提交。
1.两个父提交（@^1和@^2）的合并基数等于第一个父提交的相同提交（mn8o1P）。

**旁注：**将功能分支合并到共享分支时，可以强制执行此策略。但是，如果您使用的工作流具有多个共享分支，则不希望将共享分支重新定位到另一个共享分支上，因此请确保在执行这些合并时只使用普通的旧合并。