不要把配置文件放到你的 Git 代码仓库 已翻译 100%

oschina 投递于 2015/10/29 11:15 (共 4 段, 翻译完成于 10-30)
阅读 10455
收藏 69
Git
5
加载中

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 2 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(32)

fucan
fucan
现在做的项目就是这样把配置放到git里面,还时不时修改,烦死了,ide 风格也在里面,一不小心就提交了,还被骂
tqp我就是我
tqp我就是我
确实应该这样,毕竟每个人的本地开发环境不一样,放一个.sample 类的配置文件就好了
QuenTine
QuenTine
不把编译好的代码放到git上,理论上应该这样。但如果我想把一个压缩过的组件挂到npm上,在github上存源码,怎么做?
sdvdxl
sdvdxl
只说了不要怎么样,却没有提出该怎么样,没有实质性的建议,等于没说
漆黑的尾巴
漆黑的尾巴
视频。。。
axiaofang
axiaofang
不明所以, 我的项目全部提交。 这个文章怕是会误导很多人, 其实关键点不是配置文件是否在提交, 在于你如何管理设计你的项目
金三胖
金三胖

引用来自“金三胖”的评论

太绝对了

引用来自“金正恩”的评论

+1
加个屁
金正恩
金正恩

引用来自“金三胖”的评论

太绝对了
+2
金正恩
金正恩

引用来自“金三胖”的评论

太绝对了
+1
金三胖
金三胖
太绝对了
返回顶部
顶部