我正在尝试为我的组织构建一组 git 钩子脚本，我想使用的一个（仅用于我自己的多个项目）是检查我没有的 git rebase --continue我的代码中剩余的冲突标记（<<<<<、===== 或 >>>>>）。
我已经为我的预提交准备了这样的脚本，但是什么脚本适用于 rebase --continue ？
【问题讨论】：
pre-rebase 挂钩太早了？
pre-commit 挂钩？确定一个变基（尤其是在合并决议之后！）正在提交新代码？
TL;DR: git rebase --exec --reschedule-failed-exec "run-your-tests" <sha> 将在每次提交后运行测试 <sha>: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---execltcmdgt
=======
如果我们能以某种方式让git rebase --continue 简单地运行我们所有的正常提交挂钩，那就太好了。
在这方面，“post-rewrite”和“pre-push”可能有助于验证刚刚重新设置的代码的质量，和/或在推送之前检查它。
但是 - 我们如何验证每个中间提交是否通过了测试/工作构建/没有 lint 错误？
Git rebase 作者/维护者有答案：
git rebase --exec "run-your-tests" <base-commit-ish>
这比@sleske 提到的“git rebase 的包装器”或“单独的检查工具”要好，它是一个原生的 git 功能！
当提交出现问题时，您会看到：
... output from failed tests ...
warning: execution failed: run-your-tests
You can fix the problem, and then run
git rebase --continue
这里有一些“伪”代码，您可以在重写后或推送前运行：
rm -rf node_modules
git rebase
--exec "no-conflict-markers"
--exec "npm install"
--exec "ensure-clean-git-status"
--exec "npm run lint"
--exec "npm run test"
--exec "npm run type-check"
master
（要为 npm/node 并行运行 lint、test 和 type-check，请参阅 run-p）
当您自己进行交互式 rebase 时，您会想要执行以下操作：
git rebase -i --exec "run-your-tests" --reschedule-failed-exec <sha>
您可以将其别名为更短的名称：
git quality-rebase <sha>
使用--resheculed-failed-exec 完全按照它所说的那样做。如果你没有通过质量检查，修复它，然后运行git rebase --continue，它会再次运行你的质量检查（这显然是 OP 想要的）。
感谢git worktree，您可以根据需要进行质量检查。
在等待质量检查完成时，您可以打开新终端，运行 cd myapp; git worktree add ../myapp2 master; git checkout <whatever> 并在新的工作目录中继续编码，不受 rebase-exec 质量检查状态的影响。
我认为，只要您有良好的工作代码，最好将其备份到您的 git 远程，这也允许其他人发现它，并且您还可以拥有其他 webhook thingys“广播”新分支已发布。此外，如果您的质量检查需要一些时间，您不会想坐下来观看它。因此，我认为最好使用任何较重的检查作为pre-push 钩子。只需尝试git push，然后何时以及如果 rebase-exec 质量检查完成，它将被推高。您可以使用say 命令告诉您他们是否失败：git push && say "successfully pushed changed" || say "quality checks failed"
这是我临时推荐的具体命令，您需要为您的具体项目编辑--exec 命令：
CURRENT_BRANCH=`git branch --show-current`
git checkout master
git pull
git checkout $CURRENT_BRANCH
git fetch origin master
git rebase origin/master --reschedule-failed-exec --exec "yarn install --ignore-scripts && yarn run-p --print-label lint test type-check" origin/master
改变
【讨论】：
commit-msg 钩子，它将元数据添加到提交消息中（我有一个名为 git-guilt-staged 的 npm 包，它在每个提交消息中添加“建议的审阅者：”），也许我们'd 能够“改写”所有提交并看到这个钩子运行 - idk。
--no-verify 提交， - 这反映了您工作的时间顺序，并且更容易遵循 - 或者，您是否反转提交，以避免使用@987654347 @?
手册页githooks 列出了可用的 git 钩子。
git rebase --continue 没有钩子（列表很详尽）。
有一个钩子“post-rewrite”，它“被重写提交的命令调用”，例如git rebase。但是，它只会在命令完成后运行（即当 rebase 完成时）。
它将为您提供重写创建的新提交列表，因此您可以检查提交是否引入了任何冲突标记并抱怨，但此时中止 rebase 为时已晚。当然，您仍然可以使用 reflog 恢复变基。
总而言之，为git rebase 编写一些包装器或手动调用单独的检查工具可能更容易。无论如何，您应该（恕我直言）在调用git rebase --continue 之前始终查看您所做的更改。如果您坚持这样做，就不会意外签入冲突标记。
【讨论】：