我会把Drupal作为第一个问题的例子。我们有一个带有自定义主题和许多下载模块的drupal实例。我们有一台服务器用作源代码仓库。 然后，对drupal的dev实例的当前工作流程将更改迁移到test。一旦客户端测试出来，就像更改一样，将它们转移到生产中。 - 我应该将整个drupal dir放在git中吗？还是主题+插件？还是只是主题？ 放置整个实例的一个优点是我可以轻松克隆prod上的更改，它看起来与dev和test相同。
第二个问题是我们对产品的核心代码进行本地定制（让我们以DSpace为例）。我们获得1.6版本并进行本地更改并将其保留在我们的仓库中。然后，当他们发布版本1.7时，我必须得到它并合并我的本地更改。我如何获得1.7？我可以进入分店吗？
这些情况下的最佳做法是什么。
感谢。
PS - 我知道git忽略以及如何在技术上做到这一点。我正在寻找的是关于最佳实践的建议。
答案 0 :(得分：2)
按重要性排序：
我通常不把生产版本放到Git中;相反，我有一个脚本，可以从项目中创建一个生产站点，还有一个上传脚本来部署这个站点。这样，我可以为新的生产版本提供本地运行。并且上传脚本有一个“备份旧文件”的步骤，所以我可以在几分钟内恢复旧的生产站点（好吧，除非一些错误损坏了数据库）。
[编辑] 很多人不同意第3点和第4点。
首先，（正如我上面所说），这是有序列表。所以前两点比其他两点重要得多。
也就是说，版本生成的文件仍然很有意义。常见的情况是IDE项目设置和代码生成器的输出。
为什么要在重新创建它们时如此简单？有几个原因：
IDE项目文件包含编译器设置和其他非常重要的配置。如果您不总是在版本控制下使用它们，则最终会出现这种情况：文件将位于DVCS的忽略列表中。你发现了一个问题（就像一个应该激活的重要警告）。您激活警告。 您忘记将更改的文件添加到版本控制中。
或者：你是团队的一员。一个月后，团队中的每个人都使用不同的选项来构建他们的项目。构建中断是因为在IDE中将某些内容配置为警告但对其他人来说这是一个错误。
某些工具生成的代码肯定不应该版本化？是否足以对代码生成器的配置文件进行版本化？
也许。问题是：您是否必须在此代码中找到错误？即使不是：当文件受版本控制时，很容易看出配置选项的变化意味着什么。您只需更改选项，运行代码生成器并让您的版本工具向您显示已更改的内容。当然，你可以手动做类似的事情，但为什么要浪费这么多精力去买一些可以免费获得的东西呢？
最重要的是，它会导致“虚假的合并冲突”。许多人认为这是一个问题，但事实并非如此。实际上，您会希望看到这些问题，因为这意味着您的构建不稳定：