无需任何回归测试的代码Git工作流
因此，我有一个项目，它没有任何回归测试或自动单元测试。我们每周都会释放。我们使用叉式git流程，这基本上是每个人都叉子回购，并推动他们的变化，在他们的具体叉子。
从他们的叉子驱动到开发分支，这个分支被推到测试人员测试它的预测试处，然后再发布。我们每周发行一次。
现在，有时会出现这样的情况:两个特性在预驱动分支中，一个功能被破坏，需要被恢复，另一个特性是今天需要发布的优先级特性。现在发生的情况是，对于一个特性，它们通常是4-5合并请求(包括bug修复)，每个请求包含1-2提交，有时很难恢复它们。
那么，在这种情况下，什么是最好的行动方针呢？是否有更好的git工作流更适合这种情况？是否有比手动还原每个提交更好的方法来恢复代码？我们用Gitlab。
回答 1
Software Engineering用户
发布于 2022-06-28 18:47:10
问题是，恢复是痛苦的。您不知何故发现，在合并提交到预生产之前，但在QA测试之前，您需要恢复。听起来像是有人测试过了。这很好。做得更快。在下次提交合并之前进行测试，这样可以节省很多痛苦。
没有神奇的git修复，这正是因为合并代码是工作的。要求还原总是需要重做该工作。
这就是为什么我们编写在提交合并之前要运行的测试。它们并不是QA想象的相同的测试。它们是那些厌倦了重做合并的程序员们想出来的测试。
如果这读起来像我说的那样，你需要自动化测试，你就错过了我的观点。所有密码都被破坏了。总会有虫子的。
但是，如果您能够在QA之前找到bug呢？太棒了！在做预刺激之前？甚至更好！在写代码之前？哇!在设计之前？太棒了！在它进入积压之前？太棒了！
为什么？因为你越早发现窃听器，修复它就越便宜。
发现bug不是留给QA的。在软件开发中，无论你是谁，你都不应该去寻找bug。
https://softwareengineering.stackexchange.com/questions/439516
复制相似问题
腾讯云开发者
