构建后提交：好还是坏？
在成功构建后自动执行源代码控制提交是一个好策略吗？
编辑：我问这个问题是因为我希望在版本之间进行更频繁的增量提交，这样可以比在 v1.0 和 v1 之间回滚 2K+ 新代码行更容易找到引入错误的点.1.
Is it a good policy to automate source control commits following successful builds?
Edit: I'm asking because I want more frequent, incremental commits between versions that make it easier to find the point where a bug was introduced than rolling back 2K+ new lines of code between v1.0 and v1.1.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不。成功的构建并不意味着成功的代码更改。你从不测试你的代码吗？如果您进行某种自动化单元测试，我可以理解这个问题（尽管我仍然建议反对它 - 在您自己验证其功能之前我不会考虑测试代码更改）。但成功构建后会自动提交 - 如果你喜欢你的队友，或者他们有权使用武器，则不会。
No. A successful build does not imply a successful code change. Do you never test your code? IF you had some sort of automated unit testing, I could understand the question (although I would still recommend against it - I would not consider a code change tested until you verified its functionality yourself). But an automated commit after a successful build - not if you like your team mates, or if they have access to weapons.
不。有意义的提交消息从哪里来？以及问题跟踪项目的参考？自动化流程如何知道某项特定工作已完成？
有了这样的流程，您的存储库将降级为美化的 IDE 撤消缓冲区。
No. Where would the meaningful commit messages come from? And the references to issue tracker items? How is the automated process supposed to know that a particular bit of work is complete?
With such a process in place, your repository would degrade to a glorified IDE undo buffer.