Using.gitignore files is one of the best practices for improving the quality of your code and Git repository.

I’ve noticed that many developers don’t use.gitignore files, although it’s one of the best practices to use.gitignore files to specify which files you don’t want Git to track in version control. .gitignore can improve code quality, so you shouldn’t ignore.gitignore in the repository.

What is.gitignore?

The files in the Git repository can be:

  1. Untracked: Changes that have not been provisioned or committed.
  2. Tracked: Changes that have been provisioned or committed.
  3. Ignored: Files that you have Git ignore.

Some files you’d like Git to ignore and not track in your repository include many auto-generated or platform-specific files, as well as other local configuration files such as:

  1. Files containing sensitive information
  2. Compiled code, such as.dll.class.
  3. System files, such as.DS_StoreThumbs.db.
  4. A file that contains temporary information, such as logs, caches, etc.
  5. Generated files, such asdistFolder.

If you don’t want Git to keep track of certain files in your repository, you can’t do this with Git commands. (Although you can stop tracking a file with git rm, such as git rm –cached.) Instead, you need to use the.gitignore file, which is a text file that tells Git which files not to track.

Creating a.gitignore file is as simple as creating a text file and naming it.gitignore. Remember that there is a dot at the beginning of the file name (.) . And that’s it.

Rules for writing.gitignore files

According to the documentation, “each line in the.gitignore file specifies a pattern.”

In this context, “pattern” can refer to a particular file name, or to parts of the file name combined with wildcards. In other words, example.txt is a valid pattern for matching files named example.txt, while ex* TXT is a valid pattern for matching files named example.txt and export.txt.

Here are some basic rules to help you set up.gitignore files correctly:

  1. Any hash (#The leading lines are comments.
  2. \Character can escape special characters.
  3. /Character indicates that this rule applies only to files and folders that reside in the same folder.
  4. An asterisk (*) represents any number of characters (zero or more).
  5. Two asterisks (六四风波) represents any number of subdirectories.
  6. A question mark (?) instead of zero or one character.
  7. An exclamation mark (!) reverses specific rules (that is, to include any files that were excluded from the previous schema).
  8. Empty lines are ignored, so you can use them to add space and make your document easier to read.
  9. Add at the end/The entire directory path is ignored.

Comparison of local and global.gitignore files

There are two types of.gitignore files:

  • Local: in the root directory of your Git repository, works only in that repository, and must commit to that repository.
  • Global: placed at the root of your home directory, affecting each repository you use on your machine, no submission required.

Many developers use local.gitignore files in their project repositories, but few use global.gitignore files. The most significant advantage of using global files is that you don’t need to commit to use them, and making a change affects all of your repositories.

Advantages that Git ignores

Besides ensuring that specific files are not tracked by Git, there are other benefits to using.gitignore files.

  1. It helps keep your code base clean by ignoring unwanted files.
  2. It can control the size of the code base, which is especially useful if you are working on a large project.
  3. Every submission, push, and pull request you make will be clean.

conclusion

Git is powerful, but at the end of the day, it’s just a computer program. Using best practices and keeping your code repository stable is a team effort, and one of the things to do is use.gitignore files.


Via: opensource.com/article/20/…

By Rajeev Bera (lujun9972

This article is originally compiled by LCTT and released in Linux China