Git & Version Control Best Practices and Troubleshooting Syllabus

Best Practices and Troubleshooting syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Best Practices and Troubleshooting in Git & Version Control, not a summary of it.

1. 1

   Repository Hygiene

   4 topics

   • Effective .gitignore and .gitattributes
   • Keeping a Clean History
   • Atomic Commits
   • Documentation and README Standards
2. 2

   Common Problems and Recovery

   4 topics

   • Recovering Deleted Branches and Commits
   • Fixing Detached HEAD State
   • Undoing a Bad Merge or Rebase
   • Resolving Diverged Branches
3. 3

   Workflows for Different Team Sizes

   3 topics

   • Solo Developer Workflow
   • Small Team Workflow
   • Large Enterprise Workflows
4. 4

   Migration and Interoperability

   3 topics

   • Migrating from SVN to Git
   • Importing and Exporting Repositories
   • Mirroring and Backups

Best Practices and Troubleshooting flashcards for Git & Version Control

25 of 50 cards from the Best Practices and Troubleshooting deck — real questions with worked answers.

1. What is the primary purpose of a .gitignore file?

   To tell Git which intentionally untracked files or directories to ignore, preventing them from being staged or committed (e.g., build artifacts, logs, dependency folders, secrets).

2. How does .gitattributes differ in purpose from .gitignore?

   .gitignore excludes files from tracking, while .gitattributes defines per-path behaviors for tracked files, such as line-ending normalization, diff/merge strategies, export handling, and Git LFS filters.

3. In .gitignore syntax, what does a leading slash (e.g., /build) signify?

   It anchors the pattern to the directory containing the .gitignore file, matching only at that root level rather than in any subdirectory.

4. In .gitignore, what is the effect of a trailing slash (e.g., logs/)?

   It matches only directories named 'logs' (and their contents), not files with that name.

5. How do you re-include a file that was previously excluded by a broader .gitignore pattern?

   Use a negation pattern with a leading exclamation mark, e.g., '!important.log', though a file cannot be re-included if its parent directory is excluded.

6. Why does adding a pattern to .gitignore fail to remove a file that is already tracked?

   .gitignore only affects untracked files; an already-tracked file must first be removed from the index with 'git rm --cached <file>' and then committed.

7. Which .gitattributes setting normalizes line endings, and what does it do?

   '* text=auto' tells Git to auto-detect text files and store them with LF line endings in the repository while checking them out with the platform's native endings.

8. How do you mark a file as binary in .gitattributes, and what is the effect?

   Use '<pattern> binary' (shorthand for '-text -diff'); Git will not attempt line-ending conversion or textual diffs on that file.

9. What does the 'export-ignore' attribute in .gitattributes do?

   It excludes the matching paths from archives produced by 'git archive' (e.g., omitting tests or CI files from a release tarball).

10. Define an 'atomic commit' in Git best practice.

    A commit that represents one complete, self-contained logical change—it does exactly one thing, builds/passes on its own, and can be reverted independently without breaking unrelated functionality.

11. List three benefits of making atomic commits.

    Easier code review, cleaner and more meaningful history, and simpler debugging via 'git bisect' or targeted 'git revert' of a single change.

12. Which Git command lets you stage only selected portions (hunks) of a file to build an atomic commit?

    'git add -p' (or 'git add --patch'), which interactively presents each hunk to stage, split, or skip.

13. What are the conventional structural components of a good commit message?

    A concise imperative subject line (about 50 characters or fewer), a blank line, and a body wrapped near 72 characters explaining the what and why of the change.

14. What does 'keeping a clean history' mean, and name two techniques to achieve it.

    It means a linear, readable, logically ordered commit history. Techniques: interactive rebase to squash/reorder/reword commits ('git rebase -i') and rebasing feature branches onto main instead of merging.

15. What is the golden rule of rebasing regarding shared branches?

    Never rebase (or rewrite history of) commits that have been pushed to a shared/public branch others may have based work on, because it rewrites hashes and diverges everyone's history.

16. What is the difference between 'git merge' and 'git rebase' for integrating changes?

    Merge creates a new merge commit joining two histories, preserving branch topology; rebase replays your commits on top of another base, producing a linear history but rewriting commit hashes.

17. What is a fast-forward merge, and when does it occur?

    A merge where the target branch has no new commits since the branch diverged, so Git simply moves the branch pointer forward to the tip of the merged branch—no merge commit is created.

18. What should a good README document at minimum?

    Project name/description, installation/setup instructions, usage examples, configuration, contribution guidelines, license, and how to run tests—so a newcomer can understand and use the project quickly.

19. What lightweight markup language is conventionally used for README files on platforms like GitHub?

    Markdown (README.md).

20. What is the purpose of Conventional Commits, and give an example prefix.

    A specification standardizing commit message format to enable automated changelog generation and semantic versioning; example prefixes include 'feat:', 'fix:', 'docs:', 'refactor:', and 'chore:'.

21. How can you recover a branch you accidentally deleted in Git?

    Find the branch tip's commit hash using 'git reflog', then recreate the branch with 'git branch <name> <hash>' (or 'git checkout -b <name> <hash>').

22. What is the Git reflog, and why is it key to recovery?

    The reflog is a local log recording every update to branch tips and HEAD; it lets you find and restore commits or branches that are no longer referenced by any branch, before garbage collection removes them.

23. How long does Git typically retain unreachable objects before garbage collection, by default?

    Reachable-from-reflog entries expire after about 90 days, and unreachable objects after about 30 days (gc.reflogExpire and gc.pruneExpire defaults).

24. How do you recover a specific deleted commit whose hash you found in the reflog?

    Reset or cherry-pick it: 'git reset --hard <hash>' to move the current branch back to it, or 'git cherry-pick <hash>' to reapply it onto the current branch.

25. What is a 'detached HEAD' state in Git?

    A state where HEAD points directly at a specific commit rather than at a branch reference, so new commits are not attached to any branch and can be lost if you switch away.

See more Best Practices and Troubleshooting flashcards →

Planning Best Practices and Troubleshooting for Git & Version Control

Best Practices and Troubleshooting (Git & Version Control) FAQ