Top 10 Git and GitHub interview questions

Git is a distributed version control system: a tool on your computer that records snapshots of your project (commits), lets you branch and merge, and keeps the full history locally, so you can work offline.

GitHub (like GitLab and Bitbucket) is a hosting service for Git repositories, adding collaboration features: pull requests and code review, issues, Actions (CI/CD), permissions and project boards.

"Distributed" means every clone has the complete history, so there's no single point of failure and most operations are fast and local.

1. Working directory: your files as you edit them.
2. Staging area (index): the changes you've chosen for the next commit (git add).
3. Local repository: committed snapshots (git commit).
4. Remote repository: shared on GitHub (git push, git pull).

git status                     # what changed
git add src/login.js           # stage a file (or: git add -p to stage parts)
git commit -m "Validate email before sign-up"
git push origin feature/login-validation

Staging lets you make small, focused commits even when you've changed many things.

Both bring changes from one branch into another.

• Merge creates a merge commit joining the two histories. Non-destructive; preserves exactly what happened; history can look busy.
• Rebase replays your commits on top of the other branch, producing a straight, linear history. It rewrites commit hashes.

git switch feature/search
git rebase main          # move my commits on top of the latest main
git switch main
git merge feature/search # fast-forward, or a merge commit

The golden rule: never rebase commits others have already pulled (shared branches). Rebase your own local feature branch to keep it current; merge (or squash-merge) into main via a pull request.

A conflict happens when two branches change the same lines (or one deletes a file the other edits). Git stops and marks the file:

<<<<<<< HEAD
const LIMIT = 20;
=======
const LIMIT = 50;
>>>>>>> feature/pagination

Steps:

1. git status lists conflicted files.
2. Open each one, decide the correct final code (sometimes a combination), and delete the markers.
3. Run the tests.
4. git add <file>, then git commit (or git rebase --continue during a rebase).
5. If it's a mess, git merge --abort or git rebase --abort returns you to the start.

Prevent conflicts by pulling or rebasing often and keeping pull requests small.

• git fetch downloads new commits and branches from the remote but doesn't change your working branch. You can inspect them first (git log main..origin/main).
• git pull is git fetch followed by git merge (or git rebase with --rebase or the pull.rebase setting) into your current branch.

Use fetch when you want to see what changed before integrating; git pull --rebase keeps your local history linear.

• Discard unstaged edits to a file: git restore file.js.
• Unstage a file: git restore --staged file.js.
• Fix the last commit message or add a forgotten file (not pushed yet): git commit --amend.
• Undo the last commit but keep the changes: git reset --soft HEAD~1.
• Throw away the last commit and its changes (dangerous): git reset --hard HEAD~1.
• Undo a commit that's already pushed: git revert <hash> creates a new commit that reverses it, without rewriting shared history.
• Recover "lost" commits after a bad reset: git reflog, then git reset --hard <hash> or create a branch from it.

Key distinction: reset moves the branch pointer (rewrites history: local only), revert adds a new commit (safe for shared branches).

A branching strategy is a team agreement on how work flows into production.

• GitHub Flow / trunk-based: main is always deployable; create short-lived feature branches; open a pull request; get a review and green CI; merge; deploy. Simple and common in startups.
• Git Flow: long-lived main and develop branches plus feature/*, release/* and hotfix/* branches. Suits scheduled releases (mobile apps, enterprise software) but is heavier.

Name branches clearly (feature/job-alerts, fix/otp-expiry), keep them short-lived, and protect main with required reviews and CI checks.

git stash saves your uncommitted changes and returns your working directory to a clean state, so you can switch branches (say, to fix an urgent bug) and come back later.

git stash push -m "half-done search filters"
git switch main            # fix the bug, commit, push
git switch feature/search
git stash list
git stash pop              # re-apply and remove from the stash

git stash apply re-applies but keeps the stash entry; git stash -u includes untracked files.

Commits

• Small and focused on one logical change.
• A clear message in the imperative: "Add rate limit to OTP endpoint", with a body explaining why if it isn't obvious.
• The code builds and tests pass at every commit.

Pull requests

• A descriptive title and summary: what changed, why, how to test it, screenshots for UI.
• Small enough to review in 15–20 minutes (a few hundred lines at most).
• Linked to the issue or ticket; CI green; self-reviewed first.
• Respond to review comments politely and push fixes as new commits (squash on merge if the team prefers).

Interviewers ask this to see whether you can work in a team, not just code alone.

.gitignore lists files and patterns Git should not track:

node_modules/
dist/
.env
*.log
.DS_Store
__pycache__/

Never commit secrets (API keys, passwords, .env files), dependencies that can be reinstalled (node_modules), build output, large binary datasets or editor and OS files.

If a secret is committed by mistake: rotate the secret immediately (assume it's leaked), then remove it from history (git filter-repo or BFG) and force-push, coordinating with the team. Deleting the file in a new commit isn't enough, because it remains in history.