将什么置于版本控制之下? [英] What to put under version control?
问题描述
几乎所有 IDE 都会创建大量与正在开发的应用程序无关的文件，这些文件由 IDE 生成和维护，因此他知道如何构建应用程序、版本控制存储库在哪里等等.
Almost any IDE creates lots of files that have nothing to do with the application being developed, they are generated and mantained by the IDE so he knows how to build the application, where the version control repository is and so on.
这些文件是否应该与真正与应用程序有关的文件(源代码、应用程序的配置文件……)一起保存在版本控制之下?
Should those files be kept under version control along with the files that really have something to do with the aplication (source code, application's configuration files, ...)?
事情是:在某些 IDE 上，如果您创建一个新项目，然后使用嵌入在 IDE 中的版本控制客户端/命令将其导入版本控制存储库，那么所有这些文件都会发送到存储库.而且我不确定这是对的:在同一个项目上工作的两个不同的开发人员想要使用两个不同的 IDE 是什么意思?
The things is: on some IDEs if you create a new project and then import it into the version-control repository using the version-control client/commands embedded in the IDE, then all those files are sent to the respitory. And I'm not sure that's right: what is two different developers working on the same project want to use two different IDEs?
我想保持这个问题不可知，避免引用任何特定的 IDE、编程语言或版本控制系统.所以这个问题和这些不完全一样:
I want to keep this question agnostic avoiding references to any particular IDE, programming language or version control system. So this question is not exactly the same as these:
- SVN 和二进制文件 - 但这里讨论的是二进制文件和 SVN
- 您是否将构建工具置于版本控制中? - 但这是关于构建工具(例如将 jdk 置于版本控制之下)
- 哪些项目文件不应签入 SVN - 但这是关于 SVN 和 dll 的
- 您是否将项目文件置于版本控制之下? - 非常相似(以前没发现过)，谢谢 VonC
- SVN and binaries - but this talks about binaries and SVN
- Do you keep your build tools in version control? - but this talks about build tools (e.g. putting the jdk under version control)
- What project files shouldn’t be checked into SVN - but this talks about SVN and dll's
- Do you keep your project files under version control? - very similar (haven't found it before), thanks VonC
推荐答案
经验法则:
- 包括对构建结果有影响的所有内容(编译器选项、文件编码、ASCII/二进制设置等)
- 包括所有内容，以便可以从干净的检出中打开项目，并能够编译/运行/测试/调试/部署它而无需任何进一步的手动干预
- 不要包含包含绝对路径的文件
- 避免包含个人偏好(标签大小、颜色、窗口位置)
按照此顺序遵守规则.
[更新] 生成的代码应该发生什么总是一个问题.根据经验，我总是将它们置于版本控制之下.与往常一样，对这条规则持保留态度.
[Update] There is always the question what should happen with generated code. As a rule of thumb, I always put those under version control. As always, take this rule with a grain of salt.
我的理由:
版本化生成的代码似乎是在浪费时间.生成的对吗?我只需按一下按钮就可以取回它！
Versioning generated code seems like a waste of time. It's generated right? I can get it back at a push of a button!
真的吗?
如果您必须硬着头皮生成与某个先前版本完全相同的版本，而不会失败，您会付出多少努力?生成代码时，您不仅要正确获取所有输入文件，还必须为代码生成器本身倒转时间.你能做到吗?总是?如果您将生成的代码置于版本控制之下，那么检查它的某个版本是否一样容易?
If you had to bite the bullet and generate the exact same version of some previous release without fail, how much effort would it be? When generating code, you not only have to get all the input files right, you also have to turn back time for the code generator itself. Can you do that? Always? As easy as it would be to check out a certain version of the generated code if you had put it under version control?
即使可以，您能确定没有遗漏任何东西吗?
And even if you could, could you ever be sure that didn't miss something?
因此，一方面，将生成的代码置于版本控制之下是有意义的，因为这样可以轻松实现 VCS 的目标:回到过去.
So on one hand, putting generated code under version control make sense since it makes it dead easy to do what VCS are meant for: Go back in time.
还可以很容易地看出差异.代码生成器也有问题.如果我修复了一个错误并生成了 150'000 个文件，那么当我将它们与以前的版本进行比较时，会很有帮助，看看 a) 错误消失了，b) 没有任何else 意外更改.这是您应该担心的意外部分.如果你不这样做，请告诉我，我会确保你永远不会为我的公司工作永远 :-)
Also it makes it easy to see the differences. Code generators are buggy, too. If I fix a bug and have 150'000 files generated, it helps a lot when I can compare them to the previous version to see that a) the bug is gone and b) nothing else changed unexpectedly. It's the unexpected part which you should worry about. If you don't, let me know and I'll make sure you never work for my company ever :-)
代码生成器的主要痛点是稳定性.当您的代码生成器在您每次运行时随机生成一堆乱七八糟的字节时，它不会这样做(好吧，除非您不关心质量).代码生成器需要稳定且确定性.您使用相同的输入运行它们两次，并且输出必须到最低有效位都相同.
The major pain point of code generators is stability. It doesn't do when your code generator just spits out a random mess of bytes every time you run (well, unless you don't care about quality). Code generators need to be stable and deterministic. You run them twice with the same input and the output must be identical down to least significant bit.
因此，如果您无法签入生成的代码，因为生成器的每次运行都会产生不存在的差异，那么您的代码生成器就有错误.修理它.必要时对代码进行排序.使用保留顺序的哈希映射.尽一切努力使输出非随机.就像您在代码中的其他地方所做的一样.
So if you can't check in generated code because every run of the generator creates differences that aren't there, then your code generator has a bug. Fix it. Sort the code when you have to. Use hash maps that preserve order. Do everything necessary to make the output non-random. Just like you do everywhere else in your code.
我可能不会置于版本控制之下的生成代码将是文档.文档在某种程度上是一个软目标.当我重新生成错误版本的文档(例如，它或多或少有一些错别字)时，这并不重要.但是对于发行版，无论如何我都可能会这样做，以便我可以看到发行版之间的差异.例如，可能有助于确保发行说明完整.
Generated code that I might not put under version control would be documentation. Documentation is somewhat of a soft target. It doesn't matter as much when I regenerate the wrong version of the docs (say, it has a few typos more or less). But for releases, I might do that anyway so I can see the differences between releases. Might be useful, for example, to make sure the release notes are complete.
我也不签入 JAR 文件.因为我确实可以完全控制整个构建，并且完全有信心可以在一分钟内取回任何版本的源代码，而且我知道我拥有构建它所需的一切而无需任何进一步的手动干预，为什么我需要可执行文件?同样，将它们放入一个特殊的版本存储库可能是有意义的，但最好在您公司的 Web 服务器上保留过去三年的副本以供下载.想一想:比较二进制文件很难，而且不能告诉你太多.
I also don't check in JAR files. As I do have full control over the whole build and full confidence that I can get back any version of the sources in a minute plus I know that I have everything necessary to build it without any further manual intervention, why would I need the executables for? Again, it might make sense to put them into a special release repo but then, better keep a copy of the last three years on your company's web server to download. Think: Comparing binaries is hard and doesn't tell you much.
这篇关于将什么置于版本控制之下?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
