mark2025

@GeruzoniAnsasu 这是我所有 git 项目钩子自动执行的：

git config --global i18n.commitencoding utf-8
git config --local core.autocrlf input
git config --local core.eol lf

if [ -z "$CI" ]; then
git config --local core.filemode false
git config --local core.hooksPath ./.githooks
git config --local core.ignorecase false
git config --local core.precomposeUnicode true
git config --local fetch.prune true
git config --local pull.rebase true
git config --local push.autoSetupRemote true
git config --local push.followTags true
git config --local rebase.autoStash true
git config --local remote.origin.prune true
git config --local remote.origin.tagopt --tags
git config --local remote.pushdefault origin
git config --local rerere.enabled true
fi;

@mark2025 并且线性合并的另外一个好处是 revert 时工作量低不容易出错。

@GeruzoniAnsasu 三路合并就是人多嘴杂，你不仔细查看变动就无法确定最终合并结果是否符合预期。所以基于 rebase 的线性合并在团队开发中是最高效的（ gitlab 可以设定强制线性合并）

为什么要在 featB 上面执行 featB 分支上 git merge master ？ 这就是混乱的根源
1. 要么是在 featB 分支上 `git merge featA`
2. 要么是在 featB 分支上 `git rebase master`

a -> b -> c
a -> c
两种调用链路可以设计为两个队列 topic ，以上面 4 步为基础对 步骤 3 进行扩展就行了

@mawen0726 你这个场景使用任务队列来做应该还算简单了：
1. 发布任务消息到消息队列（带执行）
2. 收到任务消息，上锁，发布任务状态消息（已上锁）
3. 收到已上锁的行任务消息，开始执行任务。根据任务执行结果（成功、失败），发布任务状态消息（执行状态，可以包含任务结果数据）
4. 收到包含执行状态的任务消息，解锁

抽象为 4 个步骤，使用任务状态值在消息队列中来流转，可以忽略 a 、b 、c 具体服务。

@mawen0726 感觉 主题 2 、3 、4 都可以合并，用执行状态键值表示 完成、终端、取消等状态

git config --global i18n.commitencoding utf-8
git config --global core.autocrlf input
git config --global core.eol lf

@zhu327 不走现有的索引而选择扫全表？