版本控制下的内容是什么?

经验法则:

1. 包括对生成结果有影响的所有内容(编译器选项、文件编码、ASCII/二进制设置等)
2. 包括所有可以从干净的签出中打开项目并能够编译/运行/测试/调试/部署它的内容。 无需进一步的人工干预
3. 不包括包含绝对路径的文件
4. 避免包括个人偏好(标签大小、颜色、窗口位置)

按此顺序遵循规则。

[更新] 总是有一个问题,生成的代码应该发生什么。根据经验,我总是把它们放在版本控制之下。像往常一样,把这条规则和一粒盐放在一起。

我的理由:

版本控制生成的代码似乎是在浪费时间。它产生了,对吗?我只要按一下按钮就能把它拿回来!

真的?

如果您不得不咬紧牙关,生成与以前某个版本完全相同的版本,那么会付出多少努力呢?在生成代码时,您不仅必须正确地获取所有输入文件,还必须为代码生成器本身返回时间。你能做到吗?总是?如果您将生成的代码置于版本控制之下,那么签出它的某个版本就很容易了吗?

即使你可以,你能确定那没有错过什么吗?

因此,一方面,将生成的代码置于版本控制之下是有意义的,因为这样做非常容易实现VCS的目的:回到过去。

这也使得我们很容易看到不同之处。代码生成器也很麻烦。如果我修复了一个bug,并生成了150000个文件,那么当我将它们与以前的版本进行比较,以发现a)bug已经消失,b)什么都没有时,这会有很大帮助。 其他的 意外更改。这是你应该担心的意想不到的部分。如果你不这样做,告诉我,我保证你永远不会为我的公司工作。 曾经 -)

代码生成器的主要难点是稳定性。当你的代码生成器每次运行时都随机吐出一堆字节时,情况就不一样了(好吧,除非你不关心质量)。代码生成器需要稳定并且 deterministic . 使用相同的输入和输出运行它们两次 必须 与最低有效位相同。

因此,如果您不能签入生成的代码,因为生成器的每次运行都会产生不存在的差异,那么您的代码生成器就有一个bug。修好它。必要时对代码进行排序。使用保持顺序的哈希映射。做一切必要的事情使输出非随机。就像在代码中的其他地方一样。

我可能不会将生成的代码放在版本控制下的文档中。文档是一个软目标。当我重新生成错误版本的文档时(比如说,它或多或少有一些拼写错误),这并不重要。但是对于发行版,我可能无论如何都会这样做,这样我就可以看到发行版之间的区别。例如,可能有助于确保发行说明是完整的。

我也不签入JAR文件。因为我完全控制了整个构建过程,并且完全有信心在一分钟内返回源的任何版本,而且我知道我拥有构建它所必需的一切。 无需进一步的人工干预 ,为什么我需要可执行文件?同样,将它们放入一个特殊的发行版repo可能是有意义的,但是,最好在公司的Web服务器上保存一份过去三年的副本以供下载。想想:比较二进制文件很难,而且不会告诉你太多。

我认为最好是将任何有助于开发人员快速入门的东西置于版本控制之下,忽略任何可能由IDE或构建工具自动生成的东西(例如Maven的Eclipse插件generates.project和.classpath——无需检入这些东西)。尤其要避免经常更改的文件,这些文件只包含用户首选项,或者IDE之间的冲突(例如,与Eclipse一样,另一个使用.project的IDE)。

对于Eclipse用户,我发现添加代码样式(settings/org.eclipse.jdt.core.prefs-打开保存时自动格式化)以获得一致的格式化代码特别方便。

所有可以从源+配置文件自动生成的内容都不应该受版本控制!它只会引起问题和限制(如您所说的那样——由不同的程序员使用两个不同的项目文件)。

它不仅适用于IDE“垃圾文件”,也适用于中间文件(如.pyc在python中,.o在c中等)。

这里就是 build automation 生成文件就进来了。

例如,您仍然可以构建项目(两个开发人员显然需要相同的构建软件),但是他们可以反过来使用两个不同的IDE。

至于产生的“垃圾”,我倾向于忽略大部分。我知道这意味着语言不可知论,但考虑一下Visual Studio。它生成用户文件(用户设置等)。这不应该在源代码管理下。

另一方面,项目文件(由构建过程使用)当然应该。我应该补充一点,如果您是一个团队的成员,并且都同意使用一个IDE,那么签入特定于IDE的文件是可以的,前提是它们是全局的,而不是特定于用户和/或不需要的。

这些其他问题很好地解释了什么应该和不应该被检入源代码管理,所以我不会重复它们。

在我看来,这取决于项目和环境。在每个人都使用同一个IDE的公司环境中,向存储库中添加IDE文件是有意义的。虽然这有点依赖于IDE,因为有些包含到事物的绝对路径。

对于一个在不同环境下开发的项目来说,这是没有意义的,而且从长远来看,这将是一件痛苦的事情,因为项目文件不是由所有开发人员维护的,并且很难找到“相关”的东西。

如果它丢失了,任何破坏性的东西都应该在版本控制之下。

在我看来,构建项目所需的任何东西(代码、生成文件、媒体、具有所需程序信息的数据库等)都应该在存储库中。我知道,特别是对于媒体/数据库文件,这是一种发明,但对我来说,如果您不能进行分支,然后点击构建源代码管理,这不是工作。对于具有廉价分支创建/合并的分布式系统来说,这是双倍的。

别的?把它放在不同的地方。开发人员应尽可能选择自己的工作环境。

从我在版本控制中看到的情况来看,似乎大多数事情都应该涉及到它——例如源代码等等。然而,许多VCS遇到的问题是,当试图处理大型文件(通常是二进制文件)时,有时还会遇到音频和图形文件之类的问题。因此,我个人的方法是将源代码和一般的小型图形一起置于版本控制之下,并将任何二进制文件留给其他管理系统。如果这是我自己使用IDE的构建系统创建的二进制文件,那么可以完全忽略它,因为它将重新生成每个构建。对于依赖库,依赖包管理器就是在这里出现的。

至于IDE生成的文件(我假设这些文件不是在构建过程中生成的,例如Visual Studio的解决方案文件),我认为这取决于您是否单独工作。如果您是单独工作的,那么继续添加它们-它们将允许您恢复解决方案中的设置或您所做的任何设置。其他非解决方案也一样,比如文件。但是,如果您是合作的,那么我的建议是不——大多数IDE生成的文件都是特定于用户的——也就是说,它们在您的机器上工作,但不必在其他机器上工作。因此,在这种情况下最好不要包括IDE生成的文件。

DR 您应该将与您的程序相关的大部分内容放入版本控制中,不包括依赖项(库、图形和音频等内容应该由其他依赖性管理系统处理)。至于由IDE直接生成的东西,这取决于您是单独工作还是与其他人一起工作。