不要把配置文件放到你的 Git 代码仓库 已翻译 100%
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.
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.
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.
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.
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.
The bottom line is, be thoughtful of other developers on the project. The .gitignore file is your friend.