Shulou(Shulou.com)06/01 Report--

This article mainly explains "what are the ways in which git ignores file tracking?" the content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's way of thinking to study and learn "what are the ways that git ignores file tracking"?

There are two types of git ignore tracking files, one is files that have not been submitted to the git repository, and the other is files that have been submitted to the git repository.

Ignore tracking files that are not submitted to the git warehouse

Write the file path that ignores tracking to the .gitignore file under the root of the warehouse.

Ignore tracking files that have been submitted to the git repository

Option 1. Set manually in the warehouse under each clone not to check for changes to specific files.

Git update-index-assume-unchanged filename

Plan 2. Delete the tracking of the corresponding files directly (there are some problems in the actual operation test, which are not recommended. For more information, please see the error description)

The steps are as follows:

1. Git rm-cached path/to/xxx.file

2. Update .gitignore to ignore the target file

3. Git commit-m "We really don't want Git to track this anymore!"

Misunderstanding description: under this operation, the latest version of clone code will not be able to get files ignored by rm-cached.

Solutions are as follows:

1. Copy a copy of the ignored code cp-rv source.git tmp/2, enter the copied code base, restore to the previous version of cd tmp/source.gitgit reset-hard e496b8b6d38513, copy the ignored files to the current repository, and do not overwrite the .git folder\ cp-rv tmp/source.git/src/* source.git/src/.

4. Keep ignored files and update other files to the latest

Appendix

Description of option 1:

Gitignore can only ignore files that were not originally track, and modifying .gitignore is invalid if some files have been included in version management.

The right thing to do is to manually set up not to check for changes to specific files in the warehouse under each clone.

Git update-index-- assume-unchanged PATH # enter the file you want to ignore at PATH.

In addition, git provides another exclude way to do the same thing, except that the .gitignore file itself is submitted to the version library. The files used to save are public files that need to be excluded. The .git / info/exclude setting here is for files that you need to exclude locally. He won't affect anyone else. It will not be submitted to the version library.

Gitignore also has an interesting little feature, an empty .gitignore file can be used as a placeholder. This is useful when you need to create an empty log directory for your project. You can create a log directory and put an empty .gitignore file in it. So that when you clone the repo, git will automatically create an empty log directory.

Description of option 2:

The specific reasons are as follows:

Although the adopted answer can achieve the (temporary) purpose, it is not the most correct thing to do. Doing so misunderstands the meaning of git update-index, and the most direct (adverse) consequences of doing so are as follows:

All team members must execute on the target file: git update-index-- assume-unchanged. This is because even if you ask Git to pretend not to see the changes to the target file, the file itself is still in the history of Git, so everyone on the team will pull the changes to the target file during fetch. (but in fact, the target file does not want to be recorded by Git at all, rather than pretending not to see that it has changed.)

Once someone changes the target file without git update-index-assume-unchanged directly push, then all the members who pull the latest code must re-execute update-index, otherwise Git will start recording the changes in the target file again. This is actually very common, for example, a member changes the machine or hard drive, re-clone a code base, because the target file is still in the history of Git, so he or she is likely to forget update-index.

Why is this? The answer is in Git's man pages:

First, git update-index is defined as:

Register file contents in the working tree to the index (registers the contents of the file under the workspace with the index area)

The implication of this sentence is that update-index is aimed at files recorded in the Git database, not those that need to be ignored.

Then take a look at a few related descriptions about-- assume-unchanged:

When the "assume unchanged" bit is on, Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell Git when you change the working tree file. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat (2) system call (e.g. Cifs).

It roughly means:

After applying this logo, Git stops looking for possible changes to the workspace file, so you have to manually reset the logo so that Git knows you want to restore tracking of file changes. This is useful when you are working on a large project when lstat system calls to the file system are very slow.

We know that Git is used not only for code version management, but also for projects in many other areas to use Git. For example, a client of our company once had a project involving the version management of precision parts drawings and documents, and they also used Git. One use scenario is to make changes to some large files, but each time you save Git, you have to calculate the changes to the file and update the workspace, which is obvious when the hard drive is slow.

The real use of git update-index-assume-unchanged is as follows:

You are modifying a huge file, you first git update-index it-- assume-unchanged, so that Git will ignore your changes to the file for the time being.

When your work is over and you decide to submit, reset and change the logo: git update-index-- no-assume-unchanged, so that Git only needs to make one update, which is perfectly acceptable.

Submit + push.

In addition, according to the further description of the document:

This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what. Gitignore does for untracked files).

This description tells us two facts:

Although it can be used to achieve the desired results, but this is not fastidious approach (coarse)

The same thing should be done with .gitignore files (for untracked files).

The question that comes with it is: why did I add the rules in the gitignore and it didn't work?

This is because we misunderstand the purpose of the .gitignore file, which only works on Untracked Files, that is, files that have never been recorded by Git (files that have never been add and commit since they were added).

Your rules do not take effect because those .log files have been recorded by Git, so .gitignore has no effect on them at all. This is exactly what the short answer at the beginning does:

Remove tracking of the file from Git's database

Write the corresponding rules into .gitignore to make the neglect really take effect.

Submit + push.

Only in this way, all team members will be consistent without sequelae, and only in this way, other team members do not need to do extra work to maintain the ignorance of changes to a file.

Finally, it's important to note that git rm-cached deletes tracking status, not physical files; if you really don't want it at all, you can simply rm+ ignore + submit.

Thank you for your reading, the above is the content of "what are the ways git ignores file tracking?" after the study of this article, I believe you have a deeper understanding of the way git ignores file tracking, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.