今是昨非

今是昨非

日出江花红胜火,春来江水绿如蓝

gitignore does not ignore specified files

Background#

When using Tencent IMSDK, the corresponding library is included as a dependency through Pod, and the Pods folder is configured to be ignored in .gitignore. However, if you need to modify the source code of the IM SDK and are afraid that it will be overwritten after reinstalling, you may want to set it to not be ignored in .gitignore specifically for Tencent IMSDK. How can you do that?

Implementation#

Set it as follows:


!/Pods/
/Pods/*
!/Pods/TUI*/

After setting it, if you find that it is not taking effect, you can verify it with the following command:


git check-ignore -v Pods/TUIChat/

As shown in the figure below, during the first verification, it indicates that a line in .gitignore is causing it to be ignored. Then, after making the modification, running it again shows no results, indicating that it has been successful.

Example

Principle#

Reprinted from: [Git] Configuration and Usage of .gitignore File

The matching syntax for the .gitignore ignore rules is as follows:

In the .gitignore file, the syntax for each line of the ignore rule is as follows:
1. Spaces do not match any files and can be used as separators. They can be escaped with a backslash.
2. Lines starting with "#" will be ignored by Git. Lines starting with "#" are comments and can be escaped with a backslash.
3. Standard glob patterns can be used for matching. The so-called glob pattern refers to the simplified regular expressions used by the shell.
4. A pattern starting with a slash "/" indicates a directory. A pattern ending with a "/" only matches the contents in the folder and subfolders, but not the folder itself. A pattern starting with a "/" matches the root directory of the project. If a pattern does not contain a slash, it matches the content relative to the current .gitignore file path. If the pattern is not in the .gitignore file, it is relative to the project root directory.
5. An asterisk "*" matches multiple characters, matching any number of characters. Using two asterisks "**" matches any intermediate directory. For example, "a/**/z" can match "a/z", "a/b/z", or "a/b/c/z", and so on.
6. A question mark "?" matches a single character, matching any single character.
7. A matching list of single characters enclosed in square brackets "[]" matches any one of the characters inside the brackets. For example, [abc] means to match either an "a", "b", or "c". If a hyphen is used to separate two characters inside the square brackets, it represents all characters within that range. For example, [0-9] matches all digits from 0 to 9, and [a-z] matches any lowercase letter.
8. An exclamation mark "!" indicates not to ignore (track) the matched file or directory. It means to exclude files or directories other than the specified pattern. It is important to note that if the parent directory of a file has been excluded by a previous rule, the "!" rule will not take effect on that file. In other words, a pattern starting with "!" represents negation, and the file will be included again. If the parent directory of the file has been excluded, using "!" will not include it again. A backslash can be used to escape.

**Remember: **Git matches the .ignore configuration file rules from top to bottom, line by line. This means that if a previous rule has a larger scope of matching, the subsequent rules will not take effect.

**Very important: **If you accidentally push the project before creating the .gitignore file, even if you add new filtering rules to the .gitignore file, these rules will not take effect. Git will still manage all files. In other words, this problem occurs because Git has already started managing these files, so you cannot filter them out with filtering rules. Therefore, it is important to develop the habit of creating the .gitignore file at the beginning of the project, otherwise it will be very troublesome to deal with once you push it.


#               Indicates that this is a comment and will be ignored by Git
*.a             Ignores all files ending with .a
!lib.a          Except for lib.a
/TODO           Ignores the TODO file only in the root directory, excluding subdir/TODO
build/          Ignores all files in the build/ directory, filters the entire build folder;
doc/*.txt       Ignores doc/notes.txt but not doc/server/arch.txt
 
bin/:           Ignores the bin folder in the current path, and all contents in this folder will be ignored, except for the bin file
/bin:           Ignores the bin file in the root directory
/*.c:           Ignores cat.c, but not build/cat.c
debug/*.obj:    Ignores debug/io.obj, but not debug/common/io.obj and tools/debug/io.obj
**/foo:         Ignores /foo, a/foo, a/b/foo, etc.
a/**/b:         Ignores a/b, a/x/b, a/x/y/b, etc.
!/bin/run.sh    Does not ignore the run.sh file in the bin directory
*.log:          Ignores all .log files
config.php:     Ignores the config.php file in the current path
 
/mtk/           Filters the entire folder
*.zip           Filters all .zip files
/mtk/do.c       Filters a specific file
 
The filtered files will not appear in the Git repository (GitLab or GitHub). However, they will still exist in the local repository, but they will not be uploaded when pushed.
 
It should be noted that .gitignore can also specify which files to add to version control, as follows:
!*.zip
!/mtk/one.txt
 
The only difference is that the rules start with an exclamation mark, and Git will add files that meet these rules to version control. Why are there two types of rules? Imagine a scenario: if we only need to manage the one.txt file in the /mtk/ directory, and none of the other files in this directory need to be managed, then the .gitignore rule should be written as follows:
/mtk/*
!/mtk/one.txt
 
If we only have filtering rules and no adding rules, then we need to list all the files in the /mtk/ directory except for one.txt! Note that /mtk/* cannot be written as /mtk/, otherwise the parent directory will be excluded by the previous rule, and even if the one.txt file has a "!" filtering rule, it will not take effect!
 
----------------------------------------------------------------------------------
Here are some other rules:
fd1/*
Explanation: Ignores all contents under the fd1 directory; note that both the /fd1/ directory in the root directory and the /child/fd1/ directory in a subdirectory will be ignored;
 
/fd1/*
Explanation: Ignores all contents under the /fd1/ directory in the root directory;
 
/*
!.gitignore
!/fw/ 
/fw/*
!/fw/bin/
!/fw/sf/
Explanation: Ignores all contents, but does not ignore the .gitignore file, the /fw/bin/ directory, and the /fw/sf/ directory in the root directory; note that you need to use the ! rule on the parent directory of bin/ to prevent it from being excluded.

If you find that .gitignore is not taking effect, you can try the following steps, as mentioned in .gitignore File Ignoring Rules:

1. git rm -r --cached .
2. git add .
3. git commit -m "update .gitignore"

The reason is that after configuring the .gitignore file, it often does not take effect. This is because .gitignore can only ignore files that have not been tracked. Git has a local cache, so if a file has already been included in version control, modifying .gitignore will not make it take effect. The solution is to delete the local cache of Git and then recommit.

References#

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.