我们正在将sitecore更新为8.2，在此过程中，我正在尝试优化我们的源代码控制和开发工作流程。
目标 1.为支持dll，configs，lic等提供单一的事实来源。 2.拥有从dev到prod重建整个站点所需的源代码控制中的所有内容。 （不包括）。
为了拥有各种机器所需的所有不同配置，我创建了gulp任务，可以改变构建（dev，staging，prod）上的配置。这些转换后的配置放在项目中的一个文件夹中，然后用于替换目标机器上的原件。这个文件夹发布了它的所有内容，到目前为止似乎运作良好。
我不知道的是如何处理所有未更改的配置文件。
最好在项目中包含所有这些.config文件，以便它们发布吗？如果没有，那么目标机器文件夹必须是手动管理（似乎是一个坏主意）或用于确保配置是最新的脚本（更多自定义......默认情况下不是一个好主意）。
包含项目中所有配置的唯一缺点（我看到）是它将添加到文件搜索的权重（这似乎不是一个非常强大的参数）。
我没有看到什么？
你是如何处理其他Sitecore人的？
格雷戈里
答案 0 :(得分：1)
作为一般经验法则，不要将任何默认文件签入到源代码管理中。
主要原因是;膨胀，从源代码控制中进行同步/下载需要更长时间，升级，后者是一个更重要的原因。
如果/将来升级，如果您没有将任何Sitecore文件签入源代码控制，那么您只需部署Sitecore的新/干净实例，修复您自己代码中的任何冲突，然后部署在顶部。您不必尝试找出版本之间默认安装文件中的更改内容。
您需要对Sitecore配置或设置进行任何更改using patch files，并且只将这些自定义文件添加到您的解决方案中。
如何处理部署？
有几个选择。您可以完成脚本路由，这将采用干净的Sitecore安装，解压缩并进行您需要的任何修改，然后逐个安装/解压缩您在解决方案中使用的模块。
另一种选择可能是创建一个包含所有模块的默认安装，然后将其压缩，然后安装将类似于上面的过程，但更简单的解压缩单个文件的情况。您可以使用Sitecore SIM来安装实例，模块然后备份或手动执行此操作。
另一种替代方法可能是将所有内容检查到源代码管理中，在单独的存储库或不同的项目下，以确保所有默认文件和配置保持独立。如果您将来需要升级，只需删除repo / project并重新添加它们。
我也会做同样的事情（一个单独的项目），以便将所有支持补丁/ dll分开，再次帮助您轻松识别已应用的修补程序，并在未来版本解决问题时轻松删除它们。
这些可能会为您的部署增加一个额外的步骤，但保持这种分离将使您的生活更加轻松升级。