我从事一个大型项目，其中除项目文件之外的所有源文件都存储在版本控制中。这是首席开发人员的决定。他的理由是：
- 协调开发人员工作目录之间的差异非常耗时。
- 它允许开发人员独立工作，直到他们的更改稳定为止
相反，开发人员最初会获得其他开发人员的项目文件的副本。然后，当添加新文件时，每个开发人员都会通知其他所有人员有关更改的信息。从长远来看，这让我觉得更加耗时。
在我看来，不跟踪项目文件的更改所带来的好处被其危险所抵消。除了对其所需源文件的引用之外，每个项目文件还具有配置设置，如果该文件损坏或出现硬件故障，这些配置设置将非常耗时并且容易出错。其中一些嵌入了几乎不可能恢复的源代码。
我试图让领导相信他的两个理由都可以通过以下方式实现：
- 就标准文件夹结构达成一致
- 在项目文件中使用相对路径
- 更有效地使用版本控制系统
但到目前为止他还不愿意听从我的建议。我检查了svn日志，发现每个主要版本的历史记录都以Add开头。我有一种感觉，他根本不知道如何使用分支功能。
我是否无所顾虑，或者我的担忧是否合理？
你的担忧是有道理的。没有充分的理由从存储库中排除项目文件。他们应该绝对地处于版本控制之下。您还需要标准化自动构建的目录结构，因此您的领导只是推迟了不可避免的事情。
以下是将项目 (*.*proj) 文件签入版本控制的一些原因：
避免不必要的构建中断。每次添加、删除或重命名源文件时，依靠个别开发人员通知团队其他成员并不是一种可持续的做法。将会出现错误，您最终会得到损坏的构建，并且您的团队将浪费宝贵的时间来尝试确定构建损坏的原因。
维护权威的源配置。如果存储库中没有项目文件，则说明您没有足够的信息来可靠地构建解决方案。您的团队是否计划从您的开发人员的一台机器上交付构建版本？如果有，是哪一个？拥有源代码控制存储库的全部目的是维护权威的源配置，您可以从中构建和交付版本。
简化项目管理。当您引入并非每个人都熟悉的项目类型时，让每个团队成员独立更新各个项目文件的单独副本会变得更加复杂。如果您需要引入 WiX 项目来生成 MSI 包或数据库项目，会发生什么情况？
我还认为，为捍卫这种不检查项目文件的策略而提出的两点很容易被反驳。让我们分别看一下：
协调开发人员工作目录之间的差异非常耗时。
源配置应始终使用相对路径进行设置。如果您的源配置（项目文件、资源文件等）中有硬编码路径，那么您就做错了。选择忽视问题并不会让问题消失。
它允许开发人员独立工作，直到他们的更改稳定为止
不，使用版本控制可以让开发人员独立工作，直到他们的更改稳定为止。如果你们每个人都继续维护自己的项目文件的单独副本，那么一旦有人签入引用新源文件中的类的更改，您就会破坏团队中的每个人，直到他们停止正在做的事情并且仔细更新他们的项目文件。将这种体验与仅从源代码控制中“获取最新”进行比较。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
