背景：手头的一个代码仓库，每个分支的 push 都会触发一次 CI/CD，构建、部署到一个单独的测试环境，为了保证测试环境及时同步最新代码，CI 流程中会有一个步骤，检查当前 push 的分支是否已合并 master 的改动。
与其让人干等着解决冲突，有无绕过 CI 的 master 合并检查的姿势？把工作流程变的异步非阻塞一些。
带着这个问题 Google 一番，发现了
git merge -s ours master 的操作，大意是合并时忽略 master 的代码，只用自己这一侧的改动，但 commit 的父子关系能包含到 master。
If you want to do something like this but not have Git even try to merge changes from the other side in, there is a more draconian option, which is the “ours” merge strategy. This is different from the “ours” recursive merge option.
This will basically do a fake merge. It will record a new merge commit with both branches as parents, but it will not even look at the branch you’re merging in. It will simply record as the result of the merge the exact code in your current branch.
$ git merge -s ours mundo
Merge made by the 'ours' strategy.
$ git diff HEAD HEAD~
You can see that there is no difference between the branch we were on and the result of the merge.
This can often be useful to basically trick Git into thinking that a branch is already merged when doing a merge later on. For example, say you branched off a release branch and have done some work on it that you will want to merge back into your master branch at some point. In the meantime some bugfix on master needs to be backported into your release branch. You can merge the bugfix branch into the release branch and also merge -s ours the same branch into your master branch (even though the fix is already there) so when you later merge the release branch again, there are no conflicts from the bugfix.
$ git checkout -b feature-1-debug
# 合并远程的 master（虚假的合并）
$ git fetch
$ git merge -s ours origin/master
# 推上远端，触发 CI 构建
$ git push -u origin feature-1-debug