Version Control interview questions

A .gitignore file is a plain-text file listing patterns for files and folders Git should not track, such as dependencies, build output, logs, and secrets.

The most common reason is that the file was already tracked before you added the rule, because .gitignore only affects untracked files. Run git rm --cached <file> (add -r for a folder) and commit, and use git check-ignore -v <file> to see which rule, if any, matches.

Yes. Committing .gitignore shares the same ignore rules with everyone on the team. For personal rules, such as files created by your own editor, use .git/info/exclude or a global ignore file set with git config --global core.excludesFile.

Only if the secret was never committed. If a file containing passwords or API keys was ever pushed, it remains in the repository history, so revoke the exposed keys and issue new ones.

A branch in Git is an independent line of development that lets you work on a feature or fix in isolation, without affecting the main code until you merge it.

git switch is a newer command, added in Git 2.23, that does only one job: changing branches. git checkout can also switch branches but handles other tasks too, such as restoring files, which many beginners find confusing.

A branch is a separate line of work inside the same repository. A fork is a full copy of a repository, typically under a different account, often used to contribute to projects you don't have write access to.

Around 2020, major Git hosting platforms and many projects changed their default branch name from master to main to use more inclusive language. Git itself lets you pick any default name with the init.defaultBranch setting.

A cherry-pick in Git copies the changes from one specific commit onto your current branch as a new commit, without merging the rest of the branch it came from.

Merge brings every commit from another branch into yours. Cherry-pick copies only the specific commits you choose, creating new commits on your branch.

Yes. List several hashes, as in git cherry-pick a1b2c3d e4f5a6b, or use a range such as git cherry-pick A..B, which applies every commit after A up to and including B.

Not in itself, but it should be used deliberately. Cherry-picking the same change onto many branches duplicates commits and can make history and future merges confusing, so it works best for targeted cases like hotfixes and backports.

A code review is the practice of having other developers check code changes before they are merged, to catch bugs, improve quality, and share knowledge.

Check that the change does what it claims, handles edge cases and errors, is readable, and fits the existing design. Also look for security issues, missing tests, and unnecessary complexity, and leave style nitpicks to automated formatters and linters.

A pull request is the mechanism for proposing that a change be merged. Code review is the activity of examining that change; it usually happens inside a pull request, but it can also be done in person or through pair programming.

AI tools can quickly catch many common bugs, style issues, and security risks, and are increasingly used as a first reviewer. They don't yet reliably understand a team's goals, product context, or design trade-offs, so most teams still require human approval before merging.

A commit is a saved snapshot of a project's files in Git, recorded with a unique ID, an author, a timestamp, and a message describing what changed.

To undo a commit that has already been shared, use git revert <hash>, which creates a new commit that reverses it. To undo your most recent local commit while keeping its changes in your files, use git reset --soft HEAD~1.

A good commit message starts with a short summary line, around 50 characters, written as a command, such as 'Add password reset email'. If more context is needed, add a blank line followed by a longer explanation of why the change was made.

git commit saves a snapshot in your local repository. git push uploads your local commits to a remote repository so others can see them.

Conventional Commits is a specification for structured commit messages like feat: add search, so tools can write changelogs and pick versions automatically.

The specification requires feat and fix. Common additional types, taken from the Angular convention, are docs, style, refactor, perf, test, build, ci, chore and revert.

A fix commit corresponds to a patch release, a feat commit to a minor release, and any commit marked as a breaking change to a major release, so tools can calculate the next version from the history.

Use commitlint in a commit-msg Git hook, for example with Husky, and in CI to reject messages that don't follow the format. Squash-merge workflows can also check the pull request title instead.

A detached HEAD is a Git state in which you have checked out a specific commit instead of a branch, so any new commits you make don't belong to any branch.

If you made no commits you want to keep, switch back to a branch with git switch main. If you did make commits, first run git switch -c <new-branch> to put them on a branch, then merge or push that branch as usual.

Commits made while detached are at risk, because no branch points to them. After you switch away they can still be found with git reflog for a while, 30 days by default, before Git's garbage collection may delete them, so create a branch if you want to keep them.

A tag is a fixed pointer that is not supposed to move, so Git can't let new commits advance it the way a branch does. Instead it points HEAD straight at the tagged commit, leaving any new commits unattached until you create a branch.

A fast-forward merge happens when the target has no new commits since the other branch split off, so Git just moves its pointer ahead with no merge commit.

When the branch being merged into has no commits that the other branch lacks, meaning history hasn't diverged. Git then moves the pointer forward by default instead of creating a merge commit.

It forces Git to create a merge commit even when a fast-forward would be possible, so the feature's commits stay grouped under one merge in the history.

It is a team preference. Fast-forwards and rebases give a clean, linear history that is easy to read and bisect. Merge commits preserve when and how features were integrated. Many teams squash or rebase small changes and use merge commits for larger features.