This quiz covers essential concepts of managing .gitignore files and maintaining clean, efficient repositories. Strengthen your understanding of best practices for ignoring files and ensuring repository hygiene during version control workflows.
Why should you include a .gitignore file in your version-controlled repository?
Explanation: The .gitignore file is used to specify files and directories that should not be tracked by version control, preventing accidental commits of sensitive or irrelevant files. Listing contributors is not its purpose, as that information is managed elsewhere. Automated release notes are generated through separate tools, not via .gitignore. While not tracking files can reduce repository bloat and indirectly improve some operations, the main reason is selective exclusion, not speeding up cloning directly.
Which .gitignore pattern will ignore all files ending with .log in a project, including those inside subdirectories?
Explanation: The pattern '*.log' tells Git to ignore all files ending with .log, regardless of their location within the project, including subdirectories. '/log/' only ignores a directory named 'log' at the root. '!error.log' is used to unignore 'error.log' if it was previously ignored, not to ignore .log files. 'log.*' only ignores files that start with 'log.' like 'log.txt', not those ending with '.log'.
What is a key benefit of regularly cleaning up untracked build artifacts and temporary files with .gitignore?
Explanation: Regularly ignoring build artifacts and temporary files keeps the repository tidy and lowers the risk of committing unwanted files, a cornerstone of repository hygiene. Cleaning up artifacts does not directly affect compilation speed. While a clean repository aids in collaboration, it does not enable branching or merging, as those are native version control features. Syntax highlighting is unrelated to repository file hygiene.
If a file was already tracked by Git before being added to .gitignore, what happens to that file in future commits?
Explanation: Files already tracked by Git will remain in the repository and continue to be tracked even after they are added to .gitignore; you must remove them explicitly if you no longer want them versioned. Git does not automatically remove or rename tracked files just because they now match a .gitignore pattern. .gitignore only impacts new untracked files, not ones already under version control. Hidden files and renaming are not standard behaviors linked to .gitignore.
In a collaboration, a teammate adds an OS-specific file like 'Thumbs.db' to their commit. What is a good preventive measure to avoid such files polluting your project history?
Explanation: Adding OS-specific files like 'Thumbs.db' to .gitignore ensures they are not tracked or committed in the future, keeping the repository clean and universally compatible. Removing git would eliminate version control entirely, which is impractical. Renaming OS-generated files is a tedious manual process and doesn’t address future occurrences. Disabling collaborator access is extreme and unnecessary for preventing such minor issues.