我确定有很多有力的反对意见针对这种不良做法。
你错误地认为将“build artifacts”提交到版本控制是一个不好的主意(除非你错误地阐述了你的问题)。事实并非如此。
在版本控制中保存你所谓的“build artifacts”是可以的,而且非常重要。你还应该保存编译器和其他用于将源文件转换为成品的工具。
从现在起五年后,你肯定会使用不同的编译器和不同的构建环境,这些环境可能无法编译今天的版本,出于任何原因。对一个旧版本进行修复一个小bug可能会变成噩梦,需要将旧软件移植到当前编译器和构建工具中,只是为了重新编译一个有一行更改的源文件。
因此,你没有理由害怕将“build artifacts”存储在版本控制中。你可以将它们分开存储。
我建议将它们分开,例如:
ProjectName
|--- /trunk
| |--- /build
| | |--- /bin <-- compilers go here
| | |--- /lib <-- libraries (*.dll, *.jar) go here
| | '--- /object <-- object files (*.class, *.jar) go here
| '--- /source <-- sources (*.java) go here
| |--- package1 <-- sources (*.java) go here
| |--- package2 <-- sources (*.java) go here
你需要配置你的IDE或者构建脚本,将目标文件放在/ProjectName/trunk/build/object中(可能需要重新创建.../source下的目录结构)。
这样,你可以让用户选择检出/ProjectName/trunk以获取完整的构建环境,或者检出/ProjectName/trunk/source以获取应用程序的源代码。
在../build/bin和../build/lib中,你必须放置编译最终产品所使用的编译器和库,也就是用于向用户提供软件的工具。5年或10年后,你还可以在那里找到它们,以备不时之需。