在git（或任何其他版本控制系统）中保存什么？

我将以Drupal作为第一个问题的示例。我们有一个具有自定义主题的drupal实例和许多下载的模块。我们有一个服务器用作源代码repo。 drupal开发实例的当前工作流程然后将更改迁移到测试。一旦客户对其进行了测试并喜欢这些更改，他们就可以投入生产。 -我应该把整个drupal目录放在git中吗？还是主题+插件？还是仅仅是主题？ 放置整个实例的一个优点是，我可以很容易地克隆prod上的更改，它看起来与dev和test相同

第二个问题是当我们对产品的核心代码进行本地定制时（让我们以DSpace为例）。我们得到了1.6版，进行了本地更改，并将其保存在我们的回购协议中。然后，当他们发布1.7版时，我必须获得该版本，并将我的本地更改合并到该版本。如何获得1.7分？我能进一家分店吗

在这些情况下，最佳做法是什么

谢谢

---

PS-我知道git ignore以及如何在技术上做到这一点。我要找的是关于最佳实践的建议

按重要性顺序：

将构建项目所需的所有内容放入Git中（即，包括构建过程本身无法下载的所有依赖项）

将所有内容放入Git，以便在开发人员机器上运行项目

所有生成的文件（通常对查找突然出现的bug很有用——也就是“但我什么都没改变！”）。这些很好，但可能是一个讨厌的，因为他们经常改变

所有依赖项（因此您可以轻松地重新创建旧版本）

我通常不会将生产版本放入Git中；相反，我有一个脚本，它在项目之外创建一个生产站点，再加上一个用于部署此站点的上载脚本。这样，我就可以在本地运行新的生产版本。上传脚本有一个“备份旧文件”的步骤，所以我可以在几分钟内恢复旧的生产站点（除非某些bug破坏了数据库）

[编辑]很多人不同意第3点和第4点

首先，（正如我上面已经说过的），这是一个有序列表。因此，前两点比其他两点重要得多

也就是说，对生成的文件进行版本转换仍然很有意义。常见的情况是IDE项目设置和代码生成器的输出

当重新创建它们如此简单时，为什么要对它们进行版本化？有几个原因：

硬盘空间很便宜。如果这可以帮助您在一小时内找到一个bug，那么这相当于大约100美元，即大约2TB的磁盘空间

IDE项目文件包含编译器设置和其他非常重要的配置。如果您不总是将它们置于版本控制之下，那么最终会出现这种情况：文件将位于您的“忽略”列表中。您发现了一个问题（如应该激活的重要警告）。你激活了警告您忘记将更改的文件添加到版本控制。

或者：你是团队的一员。一个月后，团队中的每个人都使用不同的选项来构建他们的项目。生成中断，因为某些内容在IDE中配置为警告，但对其他人来说是错误的

某些工具生成的代码当然不应该进行版本控制？对代码生成器的配置文件进行版本设置还不够吗

也许吧。问题又来了：你会在这段代码中发现bug吗？即使不是这样：当文件处于版本控制之下时，也很容易看到配置选项的更改意味着什么。您只需更改该选项，运行代码生成器，并让您的版本工具显示已更改的内容。当然，你可以手动做类似的事情，但是为什么要浪费那么多精力去做一些可以免费得到的事情呢

最重要的是，它将导致“虚假的合并冲突”。许多人认为这是一个问题，但事实并非如此。事实上，您希望看到这些问题，因为这意味着您的构建不稳定：

你的风投说一个文件在不应该改变的时候已经改变了；那不是虫子，是恩惠。如果没有版本控制，这种更改无论如何都会发生，但您不会注意到它。上次无知比知识好是什么时候

您在一个文件中多次合并冲突。这表明您的构建或项目设置需要一些爱。再次强调：解决合并冲突是一件痛苦的事情。但是每个开发人员在不注意的情况下获得自己的文件版本确实更好

---

我不同意第三条。除非您有特殊的用例，否则不应对生成的资源进行版本控制。看，我知道。通常，这样做是不好的。但是当使用代码生成器时，将生成的源代码放在版本控制上是查找和修复生成器中错误的一个非常好的方法。谢谢您的回复。因此，您的意思是，当使用Drupal或Wordpress等开源产品时，将整个系统置于Git中，而不仅仅是主题中？想象一下您的计算机死机（硬盘崩溃、被盗、病毒破坏您的所有数据、黑客更改生产文件）。哪种最快的方式能让你再次富有成效？#3和#4完全错了。实际上，即使是#1也是错误的，因为您应该将安装依赖项留给开发人员的包管理器，只需记录依赖项即可。