不要把配置文件放到你的 Git 代码仓库

我总是惊讶地发现在一些私有的 git 仓库中缺乏管理。查看一个 git 仓库与之达成新的约定是我最恐惧的时刻之一。诚然，git 仓库中包含的文件应该是有个范围的。这可以优化开发和部署。

提交附加文件可显著提高下载（克隆一个仓库时）的时间，避开提交这些文件还有很多理由。非技术的发起人，可以使用这个原则作为指导，以确保你的团队是在聪明地提交代码。

编译后生成的文件/二进制文件

不要在一个 git 资源库中将你编译后生成的文件或者二进制文件包含进去！二进制文件 (或者可执行文件) 几乎总是将和操作系统相关的。如果你有一些开发使用 Mac 电脑，一些使用 Window，而一些使用 Linux —— 或者是这些操作系统的组合，那么这就会很令人头疼。甚至同一个操作系统的不同版本都有可能会造成问题。

此外，git 并不能很好的适用于二进制文件版本的比较。开发者要提交编译后的文件常常会造成恼人的合并冲突，打断“典型”的(或者至少是最佳状况下的) 提交请求流程。最好的选择就是存储源代码，然后让每个开发者在本地对其进行编译，或者使用一个构建服务器和公共的测试机器。

最后要注意，也不要包含哪些不是二进制文件的编译后的文件，因为这些文件会存储冗余的数据，git 资源库的会因此而不必要的变大。

图片/视屏/音乐/pdf

这些类型的文件实际上也是作为二进制文件被存储的，所以上面的规则在这里仍然适用。不过，当可以选择配备一些共享服务器，并在部署期间将多媒体资源引用进来时，将这些文件留在资源库中还是很容易的。此外, 当然也有充分的理由 (读取：文件保险) 来提交这些类型的文件。不过，因为 git 会在每次发生变化时都对整个二进制文件进行存储，这些文件将肯定会使得资源库的规模发生膨胀 - 特别是当他们经常发生变化时。

依赖

不要在 git 资源库中将下载过来的依赖包含进去! 这包括 Python 包和 Node 模块或者 Bower 组件。而是将诸如针对 Python/Pip 的 "requirements.txt" 文件或者针对 Node 的 "package.json" 文件这类对于依赖的引用包含进去。即使是一种解释型语言（比如 Python 和 Node）中的依赖，也常常会以特定于系统的方式被编译和安装。这也将会使得在不同系统/架构上进行的开发让人感觉痛苦。如果依赖引用被提交了，那么每个开发者都可以在资源库被克隆下来之后自行去获取到这些依赖。

专家建议：可以的话就要确保 "node_modules", "bower_components", "env", 以及 "target" 都包含在你的 .gitignore 文件中。

配置文件

永远不要把配置文件放在 GIT 仓库中！即使你百分之一百肯定没有人可以根据你暴露在配置文件中的密码和数据库连接信息来攻击你的系统， 对于其他开发人员来说这也将是一个噩梦。配置文件中的信息常常是和机器有关的（比如机器的 host name，ip 地址等等），特别对于那些不是使用虚拟机或者容器技术来进行开发的开放人员来说，更是如此。在这种情况下，开发人员之间经常会因为配置文件内容的不同而发生争吵。所以，请不要把配置文件放到 GIT 仓库中。

和操作系统相关的隐藏文件和第三方软件创建的文件

这个章节主要是针对工作在 OS X 上的开发者，对于这些开发者而言，提交一个名字叫".DS_store"文件夹下面的文件并不会让其他工作在 linux 下的开发者对你影响特别深刻。在通常情况下，但你创建 GIT 仓库的时候，在 gitignore 文件中指明忽略一切以 dot 开头的文件/文件夹（一般是隐藏文件）是一个非常好的选择。对于我而言，我一般将我的开发环境文件命名成 .env，将配置文件命名成 .config.json，这样通过在 gitignore 文件中指明忽略一切以 dot 开头的文件就自动将配置文件过滤掉了。

最后，如果你在使用一个第三方的文件系统工具，请确保这些工具没有输出任何的隐藏文件/文件夹到你的 GIT 仓库目录中。在大多数情况下，这下隐藏文件/文件夹是完全和 GIT 仓库无关的。

结论

关于应该不提交哪些文件到 GIT 仓库，底线就是请站在其他开发人员的角度来思考。再次强调一下，请善用 .gitignore 文件来过滤掉不需要提交的文件/文件夹。