版本控制中的代码应如何存储？

版本控制中的代码应如何存储？

开发人员友好？这样程序员就可以快速获取最新的代码，并可以在不做许多更改的情况下从其编辑器运行它？（例如指向dev DB..etc的配置文件）

要么

它应该对生产友好吗？源代码应采用易于在生产环境上部署的方式，并且当开发人员采用最新版本时，他应根据开发需求进行更改。

为什么选择？应该两者兼而有之。

您的开发环境应该配置为与签出，打开，构建，运行，调试一样容易（例如：没有绝对路径！）。您可以使用编译指令，配置类+依赖注入，甚至是ASP.NET中的perso.config之类的技巧轻松完成此操作

您的自动构建脚本应该足够定制，以照顾特定的生产配置，清理，包装等。

当这是一个希望人们做出贡献的开源项目时，我当然会选择友好的开发人员。

我对开源项目的最大不满是，存储库很少包含构建代码所需的所有依赖关系（有时出于实际或法律原因），但是当它们不包含时-有些甚至不介意告诉您什么依赖关系您需要，或更重要的是，您需要它们的哪个版本。（最好是从哪里获得）

有时，您可能需要花费半天以上的时间来获取并编译其他几个项目，以构建您想要的项目。

当然，这实际上仅与Windows上的开发有关。

两者都有，但这取决于制作的频率。对于许多定制的应用程序，部署是手动完成的，也可以在本地完成。另一方面，无论项目大小，开发人员都会不断提交代码。我认为，确保开发人员可以正确使用版本控制更为重要，这样可以使他们的生活更轻松，因此他们将有时间专注于代码，而不是通过版本控制找到方法。

它应该对生产友好，否则维护自动化构建会出现问题。

我全力以赴降低摩擦，以便更轻松地完成工作，但是您还需要考虑故障模式。

如果始终将源存储库版本配置为供生产使用，那么开发人员在运行系统之前无法重新配置会导致什么结果？开发人员针对生产运行代码。

不管开发人员对生产进行随机更改的方式是否存在其他障碍，以失败模式进行构建以鼓励其发生似乎都是危险的。

我建议提交的代码中包含的默认值应始终安全。如果愿意，也可以将生产配置文件检入源代码管理中-我几乎总是这样做-但请将其保存在“不可用”的位置。

我倾向于争取生产友好。它可以使您的构建保持清洁，并防止不必要的设置进入生产环境。

绝对对开发人员友好，带有脚本以自动进行质量检查和生产更改。

为什么不为可部署代码创建一个分支（取决于您使用的版本控制-我使用Git），为开发人员准备的版本提供一个分支？这听起来好多了，设置起来也不难。

您可以工作并提交更改，然后将其合并到可部署版本上。