关于语言不可知：什么不应该在源代码管理下？


What should NOT be under source control?

对于哪些文件和/或目录不应该(在大多数情况下)处于源代码管理之下，最好有一个或多或少的完整列表。您认为应该排除什么？

建议到目前为止：

一般来说

  • 配置包含敏感信息的文件(密码，私钥等)
  • Thumbs.db，.DS_Store和desktop.ini
  • 编辑器备份：*?(emacs)
  • 生成的文件(例如DoxyGen输出)

C＃

  • BIN *
  • OBJ *。
  • *。可执行程序

视觉工作室

  • 名为.suo *
  • * .NCB
  • *。用户
  • * .APS
  • * .cachefile
  • *的.backup
  • _UpgradeReport_Files

Java的

  • *。类

日食

我不知道，这就是我现在正在寻找的东西:-)

Python

  • * .pyc文件

临时文件
- 。*。sw？
- *?

相关讨论

任何生成的东西。二进制，字节码，从XML生成的代码/文档。

从我的评论者，排除：

  • 构建生成的任何内容，包括代码文档(doxygen，javadoc，pydoc等)

但包括：

  • 您没有OR源的第三方库不构建。

FWIW，在我为一个非常大的项目工作时，我们在ClearCase下有以下内容：

  • 所有原始代码
  • Qt源和内置调试/发布
  • (非常过时)规格

我们没有为我们的软件构建模块。每两周发布一个完整的二进制文件，包含最新的更新。

相关讨论

操作系统特定文件，由其文件浏览器生成
Thumbs.db和.DS_Store

一些其他Visual Studio典型的文件/文件夹

1
2
3
*.cachefile
*.backup
_UpgradeReport_Files

例如，我的乌龟全局忽略模式看起来像这样

1
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
相关讨论

不应检入构建的文件

相关讨论

就像Corey D所说的那样，生成的任何内容，特别是构建过程和开发环境生成的任何东西都是很好的候选者。例如：

  • 二进制文件和安装程序
  • 字节码和档案
  • 从XML和代码生成的文档
  • 由模板和代码生成器生成的代码
  • IDE设置文件
  • 由IDE或编辑器生成的备份文件

上述一些例外情况可能是：

  • 图像和视频
  • 第三方图书馆
  • 特定于团队的IDE设置文件

拿第三方库，如果你需要发货或你的构建依赖于第三方库，将它置于源代码控制之下是不合理的，特别是如果你没有源代码。还要考虑一些源控制系统在存储二进制blob方面效率不高，你可能无法利用这些文件的系统diff工具。

保罗也对生成的文件发表了很好的评论，你应该看看他的答案：

Basically, if you can't reasonably
expect a developer to have the exact
version of the exact tool they need,
there is a case for putting the
generated files in version control.

总而言之，您需要根据具体情况考虑您在源代码管理下的所有内容。定义一个简单的列表，列出什么和什么不放在它下面只会对某些人有效，而且可能只有这么长时间。当然，您添加到源代码控制的文件越多，更新工作副本所需的时间就越长。

相关讨论

可以由IDE，构建过程或二进制可执行过程生成的任何内容。

相关讨论

例外：

4或5个不同的答案表示生成的文件不应该受源代码控制。那不是真的。

专业工具生成的文件可能属于源代码管理，尤其是在需要这些工具的特定版本的情况下。

例子：

  • bison生成的解析器/ yacc / antlr，
  • autotools文件，如configure或Makefile.in，由autoconf，automake，libtool等创建，
  • 翻译或本地化文件，
  • 文件可能由昂贵的工具生成，只在几台机器上安装它们可能更便宜。

基本上，如果您无法合理地期望开发人员拥有他们所需的确切工具的确切版本，则可以将生成的文件放在版本控制中。

svn人员在他们的最佳实践谈话中讨论了这个例外。

相关讨论

我会以不同的方式解决问题;什么东西应该包含在源代码管理中？您应该只控制那些文件：

  • (需要修订历史记录或在构建之外创建，但它们是构建，安装或媒体的一部分)和
  • 无法通过您控制的构建过程生成AND
  • 对于构建产品的所有用户都是通用的(没有用户配置)

该清单包括以下内容：

  • 源文件
  • 制作，项目和解决方案文件
  • 其他构建工具配置文件(与用户无关)
  • 第三方图书馆
  • 预先构建的文件，如PDF和＆amp ;;文件
  • 文件
  • 图像，视频，声音
  • 描述文件，如WSDL，XSL

有时，构建输出可以是构建输入。例如，模糊重命名文件可以是输出和输入以保持相同的重命名方案。在这种情况下，使用签入文件作为构建输入，并将输出放在不同的文件中。构建之后，检查输入文件并将输出文件复制到其中并检入。

使用排除列表的问题在于，您永远不会知道所有正确的排除项，并且可能最终源控制不应受源控制的内容。

来自编辑的临时文件。

1
2
.*.sw?
*~

等等

相关讨论

desktop.ini是我见过的另一个Windows文件。

实际配置文件如asp.net中的web.config，因为人们可以有不同的设置。通常我处理这个问题的方法是在SVN上安装web.config.template。人们得到它，进行他们想要的更改并将其重命名为web.config。

除了这个以及你所说的，还要注意包含密码的敏感文件(例如)。

避免使用Windows(拇指)或Mac OS(.ds_store)生成的所有烦人文件

配置包含密码或任何其他敏感信息的文件。

*.bak由WinMerge制作。

另外：

视觉工作室

  • * .NCB

我发现考虑它的最好方法如下：

假装你有一台全新的，商店买的电脑。您安装操作系统和更新;您安装所有开发工具，包括源控制客户端;您创建一个空目录作为本地源的根目录;你做一个"获取最新"或源控制系统调用它来获取你想要构建的发行版的干净副本;然后运行构建(从源代码控制中获取)，然后构建所有内容。

这个思维过程告诉你为什么某些文件必须在源代码控制中：所有这些都是构建在一个干净的系统上工作所必需的。这包括.designer.cs文件，T4模板的输出以及构建不会创建的任何其他工件。

临时文件，配置除全局开发和敏感信息之外的任何内容

相关讨论

没有进入源代码控制的东西分为3类

  • 与项目完全无关的事情(显然)
  • 可以在安装介质上找到的东西，永远不会改变(例如：第三方API)。
  • 可以通过构建过程从源代码控制(或类2中的事物)中的东西机械生成的东西。
    • 相关讨论

    我总是使用www.gitignore.io生成一个正确的.ignore文件。

    如果您的代码有运行时环境(例如依赖库，特定的编译器版本等)，请不要将包放入源代码控制中。我的做法很残酷，但很有效。我提交了一个makefile，它的作用是下载(通过wget)这些东西，解压缩它，并构建我的运行时环境。

    无论用什么语言：

    • 缓存文件
    • 通常，导入的文件也不应该(如用户上传的图像，在Web应用程序上)
    • 临时文件;甚至是你的操作系统生成的(如windows下的thumbs.db)或IDE
    • 用密码配置文件？取决于谁有权访问存储库

    对于那些不了解它的人：svn:ignore太棒了！

    相关讨论

    我有一个特殊的.c文件，不进入源代码管理。

    规则在构建过程中生成的源代码控制中没有任何内容。

    唯一已知的例外是工具是否需要构建自身的旧版本(引导程序问题)。在这种情况下，您需要在源代码管理中使用已知的良好引导副本，以便可以从空白构建。

    在这里走出困境，但我相信如果您在Visual Studio中使用任务列表，它们将保存在.suo文件中。这可能不是让它们保持在源代码管理中的理由，但这是在某处保留备份的原因，以防万一......

    自从提出这个问题以来已经过了很多时间，而且我认为很多答案虽然相关，却没有关于每种语言或IDE级别的.gitignore的详细信息。

    Github推出了一个非常有用的，社区合作的.gitignore文件列表，用于各种项目和IDE，值得一看。

    这是git repo的链接：https：//github.com/github/gitignore

    要回答这个问题，以下是相关的例子：

    • C＃ - >请参阅Visual Studio
    • 视觉工作室
    • Java的
    • 日食
    • Python

    还有特定于操作系统的.gitignore文件。以下：

    • 视窗
    • OS X.
    • Linux的

    因此，假设您正在运行Windows并使用Eclipse，您只需将Eclipse.gitignore和Windows.gitignore连接到项目顶级目录中的.gitignore文件即可。很漂亮的东西。

    不要忘记将.gitignore添加到您的仓库并提交它！

    有可能，您的IDE已经为您处理了这个问题。无论如何，Visual Studio都可以。

    对于.gitignore文件，如果您看到特定.gitignore中缺少任何文件或模式，则可以使用建议的更改在该文件上打开PR。查看提交和拉取请求跟踪器的想法。

    相关讨论

    意见：如果需要，一切都可以在源代码控制中，除非它带来重大的存储库开销，例如频繁更改或大块。

    第三方二进制文件，难以生成(就时间而言)生成的文件以加快部署过程，一切正常。

    源控制的主要目的是将一个相干系统状态与修订号相匹配。如果可能的话，我会用代码构建工具和目标操作系统来冻结整个宇宙。

    相关讨论