问题描述
传统的CI系统通常只对集成分支中的质量水平进行监控，通过对已提交的代码库进行QA验证，检测回归并发送通知以进行人工干预。
但是，当检测到这些回归时，分支至少从相应的QA验证开始就处于麻烦中，并且在所有罪魁祸首被识别、修复并进行新的QA验证确认分支质量水平恢复之前，分支将保持在这种状态（甚至变得更糟！）。在此期间，分支在正常开发过程中被视为被阻塞。
是否有一种CI工具能够实际上防止这种回归发生，即执行预提交QA验证，并且只有在更新了代码库并且通过了相应的预提交QA验证后，才允许提交，从而保证了最低分支质量水平？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在Git中，可以使用Git钩子（Git hooks）来实现拒绝破坏构建的提交。Git钩子是非常强大的，可以用于运行预提交检查。以下是如何创建一个Git钩子来拒绝不符合特定条件的推送的示例：
1. 打开你的代码库，并找到.git/hooks目录。
2. 在该目录中创建一个名为pre-commit的文件（如果该文件已存在，请确保它是可执行的）。
3. 在pre-commit文件中添加以下内容：
#!/bin/bash
# 运行你的QA验证脚本
./path/to/your/qa/verification/script.sh
# 检查QA验证结果
if [ $? -ne 0 ]; then
echo "QA验证未通过，请修复问题后再提交。"
exit 1
fi
在上面的示例中，我们创建了一个名为pre-commit的Git钩子文件，并在其中运行了一个QA验证脚本。如果QA验证未通过，将输出错误消息并拒绝提交。
请注意，这只是一个示例，你需要根据你的具体需求和QA验证脚本进行相应的修改。
方案2
另一种方法是使用Pull Request（PR）模型来控制提交的合并。你可以在PR中设置一些限制，例如要求至少N个审批和X个通过的构建，才允许合并PR。这样可以防止在测试失败或其他人未查看代码时意外合并。
以下是使用Atlassian Bitbucket Server的示例：
1. 打开你的项目，并进入项目设置。
2. 在设置中找到合并请求（Pull Request）相关的选项。
3. 配置所需的审批和构建要求。
通过这种方式，你可以在合并之前确保代码通过了一定的QA验证和构建要求。
请注意，这种方法只能减少回归发生的概率，而不能完全消除。此外，如果你的团队很大，这种方法可能不适用于并行开发的情况。
方案3
如果你希望更加灵活地控制提交的合并，并且能够在提交之前进行更多的QA验证，你可以考虑使用一些专门的CI工具，如ApartCI。ApartCI是一种CI系统，旨在防止回归，从而保证分支质量水平的稳定或提高。它通过集中化的预提交验证来确保只有在验证了所有先前提交的更改以满足或超过最新的分支质量水平后，才能提交更改。
请注意，ApartCI目前仍处于测试阶段。
以上是几种常见的方法，你可以根据你的具体需求选择适合你的解决方案。