将 .sln 文件提交到源代码管理是否是最佳实践?什么时候这样做合适或不合适?
更新 答案中有几个要点。感谢您的回复!
将 .sln 文件提交到源代码管理是否是最佳实践?什么时候这样做合适或不合适?
更新 答案中有几个要点。感谢您的回复!
我认为从其他答案中可以清楚地看出,解决方案文件很有用并且应该提交,即使它们不用于官方构建。对于使用诸如转到定义/声明等 Visual Studio 功能的任何人来说,它们都很方便。
默认情况下,它们不包含绝对路径或任何其他特定于机器的工件。(不幸的是,一些插件工具没有正确维护这个属性,例如 AMD CodeAnalyst。)如果你小心地在项目文件(C++ 和 C#)中使用相对路径,它们将与机器无关也。
可能更有用的问题是:您应该排除哪些文件?这是我的 VS 2008 项目的 .gitignore 文件的内容:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(最后一个条目仅适用于 AMD CodeAnalyst 分析器。)
对于 VS 2010,您还应该排除以下内容:
ipch/
*.sdf
*.opensdf
是的——我认为它总是合适的。用户特定的设置在其他文件中。
是的,你应该这样做。解决方案文件仅包含有关解决方案整体结构的信息。该信息对于解决方案是全局的,并且可能对您项目中的所有开发人员都是通用的。
它不包含任何用户特定的设置。
你绝对应该拥有它。除了其他人提到的原因之外,还需要使整个项目的一步构建成为可能。
是的,你应该提交的事情是:
你不应该提交的事情是:
关于其他自动生成的文件,有一个单独的线程。
我通常同意应该签入解决方案文件,但是,在我工作的公司,我们做了一些不同的事情。我们有一个相当大的存储库,开发人员不时在系统的不同部分工作。为了支持我们的工作方式,我们要么拥有一个大的解决方案文件,要么拥有几个更小的解决方案文件。这两者都有一些缺点,需要开发人员进行手动工作。为了避免这种情况,我们制作了一个插件来处理所有这些。
该插件让每个开发人员只需从存储库中选择相关项目即可检查源树的子集以进行工作。然后插件生成一个解决方案文件并为给定的解决方案动态修改项目文件。它还处理引用。换句话说,开发人员所要做的就是选择合适的项目,然后生成/修改必要的文件。这也使我们能够自定义各种其他设置以确保公司标准。
此外,我们使用插件来支持各种签入策略,这通常可以防止用户向存储库提交错误/不合规的代码。
是的,它应该是源代码控制的一部分。每当您从应用程序中添加/删除项目时,.sln 都会得到更新,最好将其置于源代码控制之下。它将允许您拉出您的应用程序代码 2 个版本并直接进行构建(如果需要)。
是的,您总是希望包含 .sln 文件,它包含指向解决方案中所有项目的链接。
在大多数情况下,将 .sln 文件提交到源代码管理是一个好主意。
如果您的 .sln 文件是由另一个工具(例如 CMake)生成的,那么将它们放入源代码控制可能是不合适的。
我们这样做是因为它使一切保持同步。所有必要的项目都集中在一起,没有人担心错过一个。我们的构建服务器(Ant Hill Pro)也使用 sln 来确定要为发布构建哪些项目。
我们通常将所有解决方案文件放在解决方案目录中。通过这种方式,我们将解决方案与代码稍微分开,并且更容易挑选出我需要处理的项目。
您甚至会考虑不将其存储在源代码管理中的唯一情况是,如果您有一个包含许多项目的大型解决方案,这些项目处于源代码管理中,并且您想创建一个小型解决方案,其中包含一些主要解决方案中的一些项目私人瞬态要求。
是的 - 用于生成您的产品的所有内容都应该在源代码管理中。
我们在 TFS 版本控制中保留或解决文件。但是由于 or main 解决方案真的很大,大多数开发人员都有一个只包含他们需要的个人解决方案。主要解决方案文件主要由构建服务器使用。
.slns 是我们在 tfs 中唯一没有遇到问题的东西!