按重要性排序:
- 将构建项目所需的所有内容放入 Git 中(即包括构建过程不会自行下载的所有依赖项)
- 将所有内容放入 Git 以在开发人员机器上运行项目
- 所有生成的文件(通常用于发现突然的错误 - 也就是“但我没有改变任何东西!”)。这些很好,但可能会令人讨厌,因为它们经常变化。
- 所有依赖项(因此您可以轻松地重新创建旧版本)
我通常不会将生产版本放入 Git;相反,我有一个脚本,它从项目中创建一个生产站点,以及一个用于部署该站点的上传脚本。这样,我可以在本地运行新的生产版本。并且上传脚本有一个步骤“备份旧文件”,所以我可以在几分钟内恢复旧的生产站点(好吧,除非某些错误损坏了数据库)。
[编辑]很多人不同意第 3 点和第 4 点。
首先,(正如我上面已经说过的),这是一个有序列表。所以前两点比其他点重要得多。
也就是说,对生成的文件进行版本化仍然很有意义。常见的情况是 IDE 项目设置和代码生成器的输出。
当重新创建它们如此简单时,为什么要对它们进行版本控制?有几个原因:
硬盘空间便宜。如果这可以帮助您在不到一小时的时间内找到错误,则相当于大约 100 美元,即大约 2TB 的磁盘空间。
IDE 项目文件包含编译器设置和其他非常重要的配置。如果您不总是将它们置于版本控制之下,您最终会遇到这种情况:这些文件将在您的DVCS的忽略列表中。您发现了一个问题(例如应该处于活动状态的重要警告)。你激活警告。您忘记将更改的文件添加到版本控制。
或者:你是团队的一员。一个月后,团队中的每个人都使用不同的选项来构建他们的项目。构建中断是因为某些内容在您的 IDE 中配置为警告,但对其他人来说却是错误。
某些工具生成的代码肯定不应该进行版本控制吗?对代码生成器的配置文件进行版本控制还不够吗?
也许。问题又来了:您是否必须在此代码中找到错误?即使不是:当文件受版本控制时,很容易看出配置选项的更改意味着什么。您只需更改选项,运行代码生成器并让您的版本工具向您显示更改的内容。当然,您可以手动执行类似的操作,但为什么要为可以免费获得的东西浪费这么多精力呢?
最重要的是,它会导致“虚假的合并冲突”。许多人认为这是一个问题,但事实并非如此。实际上,您会希望看到这些问题,因为这意味着您的构建不稳定:
- 您的 VCS 说文件在不应该发生的情况下发生了更改;这不是一个错误,这是一个福音。如果没有版本控制,无论如何都会发生这种变化,但你不会注意到它。上一次无知胜于知识是什么时候?
- 您一遍又一遍地在一个文件中合并冲突。这表明您的构建或项目设置需要一些爱。再说一遍:解决合并冲突很痛苦。但是每个开发人员在不注意的情况下获得自己的文件版本真的更好吗?