加载中

I am perpetually amazed by the lack of curation found in private git repositories. Taking a look at a git repo after taking on a new contract is one of the moments I dread the most. To be sure, there is a spectrum of acceptable files to be included in a git repository. But there is also best-practice; optimization for developers and deployment.

Aside from the fact that committing extraneous files can significantly increase the download time when cloning a repo, there are many reasons to avoid committing certain files. For non-technical founders, feel free to use this as a guide to make sure your team is sensibly committing code.

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

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

Compiled files/binaries

Do not include your compiled files or binaries in a git repository! Binaries (or executable files) will almost always be operating-system-dependent. This will cause major headaches if you have some developers using Macs, some using Windows, and some using Linux - or any combination of alternate OSes. This can even cause problems within different versions of the same operating system.

Furthermore, git is not well suited to compare versions of binaries. Developers committing compiled files will often create annoying merge conflicts that disrupt the "typical" (or. at least, best-case) flow of a pull request. The best choice is to store the source, and let each developer compile it locally or use a build server and common test machine.

As a final note, do not include compiled files that are not binaries either because these files will be storing redundant data and therefore needlessly increase the size of the git repo.

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

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

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

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

Images/videos/music/pdfs

These kinds of files are actually stored as binary files so the same rules as above do apply here. However, when the alternative is to have some share server and pull the multimedia assets in during deployment, it is certainly easier to leave these files in the repository. Furthermore, there are certainly good reasons (read: file-insurance) to commit these kinds of files. However, since git stores the entire binary each time it changes, these files will definitely bloat the size of the repo - especially if they change frequently.

Dependencies

Do not include downloaded dependencies in a git repository! This includes Python packages or Node modules or Bower components. Instead, include references to the dependencies such as a "requirements.txt" file for Python/Pip or a "package.json" file for Node. Even dependencies in an interpreted language (like Python or Node) will often be compiled/installed in system-specific ways. This will also make developing on different systems/architectures painful. If the dependency references are committed, then each developer can grab the dependencies after the repo has been cloned.

Pro-tip: make sure "node_modules", "bower_components", "env", and "target" are all in your .gitignore if applicable.

图片/视屏/音乐/pdf

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

依赖

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

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

Configs

Do not include configs in your repository! Even if you are completely confident that your hosting service will never be hacked to expose your passwords and connection information, it can still be painful for developers. Configs can often be machine-specific, especially if developers do not use VMs or Docker containers for development. This will mean constant fighting (intentional or not) in git over who's config is most important. Do yourself a favor and keep configs out of the repo.

OS-specific hidden files and 3rd-party artifacts

This section is primarily looking at you, OS X. For instance, committing ".DS_store" files will not impress your Linux-using coworkers. In general, adopting a gitignore strategy of ignoring all files beginning with a dot (hidden files) is a safe bet. I personally use this to simplify my gitignore by using ".env" as my virtualenv and ".config.json" as my config file, for example.

Finally, if you are using any 3rd-party file system tools, make sure they are not leaving hidden files or folder artifacts in the git repo. Most likely these files are completely irrelevant to the repository and other machines.

Conclusion

The bottom line is, be thoughtful of other developers on the project. The .gitignore file is your friend.

配置文件

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

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

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

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

结论

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

返回顶部
顶部