Linux and Command-Line Basics
"build/" was written in the .gitignore of a project managed with Git, but changes to build/out.log, which was committed earlier, keep appearing in git status. Which of the following is the reason?
- A.gitignore affects only files that are not yet tracked, so a tracked file must be removed from tracking with git rm --cached
- BDirectories cannot be written in .gitignore, so the names of the files to ignore must be written one by one
- C.gitignore has no effect on any file until the .gitignore file itself is added with git add and committed
Show answer and explanation
Answer: A. .gitignore affects only files that are not yet tracked, so a tracked file must be removed from tracking with git rm --cached
.gitignore is a setting that removes files that are not yet tracked (never committed or added with git add) from the git status listing and from what git add picks up. A file that is already tracked stays tracked even if it is written in .gitignore, so its changes keep appearing. git rm --cached build/out.log stops tracking it while keeping the file in the working directory, and after that is committed, the .gitignore entry takes effect. Large generated files such as simulation outputs and build results are best written in .gitignore from the start.
- A. Correct. .gitignore does not affect tracked files; git rm --cached removes them from tracking.
- B. Writing it with a trailing slash, as in "build/", ignores the whole contents of a directory named build.
- C. .gitignore takes effect as long as it is in the working directory, even if it is not committed. It is usually committed, however, so that the team shares the same settings.