[英]What should NOT be under source control?
对于哪些文件和/或目录不应该(在大多数情况下)处于源代码管理之下,最好有一个或多或少的完整列表。 您认为应该排除什么?
建议到目前为止:
一般来说
C#
视觉工作室
Java的
日食
我不知道,这就是我现在正在寻找的东西:-)
蟒蛇
临时文件 - 。*。sw? - *〜
任何生成的东西。 二进制,字节码,从XML生成的代码/文档。
从我的评论者,排除:
但包括:
FWIW,在我为一个非常大的项目工作时,我们在ClearCase下有以下内容:
我们没有为我们的软件构建模块。 每两周发布一个完整的二进制文件,包含最新的更新。
特定于操作系统的文件,由其文件浏览器(如Thumbs.db
和.DS_Store
一些其他Visual Studio典型的文件/文件夹
*.cachefile
*.backup
_UpgradeReport_Files
例如,我的乌龟全局忽略模式看起来像这样
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
不应检入构建的文件
就像Corey D 所说的那样,生成的任何内容,特别是构建过程和开发环境生成的任何东西都是很好的候选者。 例如:
上述一些例外情况可能是:
拿第三方库,如果你需要发货或你的构建依赖于第三方库,将它置于源代码控制之下是不合理的,特别是如果你没有源代码。 还要考虑一些源控制系统在存储二进制blob方面效率不高,你可能无法利用这些文件的系统diff工具。
基本上,如果您无法合理地期望开发人员拥有他们所需的确切工具的确切版本,则可以将生成的文件放在版本控制中。
总而言之,您需要根据具体情况考虑您在源代码管理下的所有内容。 定义一个简单的列表,列出什么和什么不放在它下面只会对某些人有效,而且可能只有这么长时间。 当然,您添加到源代码控制的文件越多,更新工作副本所需的时间就越长。
可以由IDE,构建过程或二进制可执行过程生成的任何内容。
我会以不同的方式解决问题; 什么东西应该包含在源代码管理中? 您应该只控制那些文件:
该清单包括以下内容:
有时,构建输出可以是构建输入。 例如,模糊重命名文件可以是输出和输入以保持相同的重命名方案。 在这种情况下,使用签入文件作为构建输入,并将输出放在不同的文件中。 构建之后,检查输入文件并将输出文件复制到其中并检入。
使用排除列表的问题在于,您永远不会知道所有正确的排除项,并且可能最终源控制不应受源控制的内容。
例外:
4或5个不同的答案表示生成的文件不应该受源代码控制。 那不是真的。
专业工具生成的文件可能属于源代码管理,尤其是在需要这些工具的特定版本的情况下。
例子:
基本上,如果您无法合理地期望开发人员拥有他们所需的确切工具的确切版本 ,则可以将生成的文件放在版本控制中。
svn人员在他们的最佳实践谈话中讨论了这个例外。
来自编辑的临时文件。
.*.sw?
*~
等等
desktop.ini
是我见过的另一个Windows文件。
配置包含密码或任何其他敏感信息的文件。
实际配置文件如asp.net中的web.config,因为人们可以有不同的设置。 通常我处理这个问题的方法是在SVN上安装web.config.template。 人们得到它,进行他们想要的更改并将其重命名为web.config。
除了这个以及你所说的,还要注意包含密码的敏感文件(例如)。
避免使用Windows(拇指)或Mac OS(.ds_store)生成的所有烦人文件
*.bak
由WinMerge制作。
另外:
视觉工作室
我发现考虑它的最好方法如下:
假装你有一台全新的,商店买的电脑。 您安装操作系统和更新; 您安装所有开发工具,包括源控制客户端; 您创建一个空目录作为本地源的根目录; 你做一个“获取最新”或源控制系统调用它来获取你想要构建的发行版的干净副本; 然后运行构建(从源代码控制中获取),然后构建所有内容。
这个思维过程告诉你为什么某些文件必须在源代码控制中:所有这些都是构建在一个干净的系统上工作所必需的。 这包括.designer.cs文件,T4模板的输出以及构建不会创建的任何其他工件。
临时文件,配置除全局开发和敏感信息之外的任何内容
没有进入源代码控制的东西分为3类
无论用什么语言:
对于那些不了解它的人: svn:ignore
是伟大的!
如果您的代码有运行时环境(例如依赖库,特定的编译器版本等),请不要将包放入源代码控制中。 我的做法很残酷,但很有效。 我提交了一个makefile,它的作用是下载(通过wget)这些东西,解压缩它,并构建我的运行时环境。
我有一个特殊的.c文件,不进入源代码管理。
规则在构建过程中生成的源代码控制中没有任何内容。
唯一已知的例外是工具是否需要构建自身的旧版本(引导程序问题)。 在这种情况下,您需要在源代码管理中使用已知的良好引导副本,以便可以从空白构建。
在这里走出困境,但我相信如果您在Visual Studio中使用任务列表,它们将保存在.suo文件中。 这可能不是让它们保持在源代码管理中的理由,但这是在某处保留备份的原因,以防万一......
自从提出这个问题以来已经过了很多时间,我认为很多答案虽然相关,但在每种语言或IDE级别上都没有关于.gitignore
详细信息。
Github推出了一个非常有用的,社区合作的.gitignore
文件列表,用于各种项目和IDE,值得一看。
这是git repo的链接: https : //github.com/github/gitignore
要回答这个问题,以下是相关的例子:
还有特定于操作系统的.gitignore
文件。 以下:
因此,假设您正在运行Windows并使用Eclipse ,您可以将Eclipse.gitignore
和Windows.gitignore
连接到项目顶级目录中的.gitignore
文件。 很漂亮的东西。
不要忘记将.gitignore添加到您的仓库并提交它!
有可能,您的IDE已经为您处理了这个问题。 无论如何,Visual Studio都可以。
对于.gitignore
文件,如果您看到特定.gitignore
缺少任何文件或模式,则可以使用建议的更改在该文件上打开PR。 查看提交和拉取请求跟踪器的想法。
我总是使用www.gitignore.io生成一个正确的.ignore
文件。
意见:如果需要,一切都可以在源代码控制中,除非它带来重大的存储库开销,例如频繁更改或大块。
第三方二进制文件,难以生成(就时间而言)生成的文件以加快部署过程,一切正常。
源控制的主要目的是将一个相干系统状态与修订号相匹配。 如果可能的话,我会用代码构建工具和目标操作系统来冻结整个宇宙。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.