Git & GitHub interview questions and answers

Question 1

What is version control, and why use it?

Accepted Answer

Version control is a system that records every change to a set of files over time, so you can see what changed, who changed it, and when, and go back to any earlier version. Why it matters: you can undo mistakes safely, work on a feature without breaking the main code, let many people edit the same project without overwriting each other, and keep a full history that doubles as documentation of how the project got here. Git is the version control tool almost everyone uses today. Analogy: the undo history in a document editor, but permanent, shared with your team, and able to hold many parallel drafts at once. In an interview: Version control records the full history of a project so changes are reversible, parallel work is safe, and collaboration does not mean emailing files around. Git is the standard tool.

Question 2

What is the difference between Git and GitHub?

Accepted Answer

Git is the tool. It runs on your computer, tracks your files, and stores the whole history locally. You can use Git with no internet and no account anywhere. GitHub is a website that hosts Git repositories in the cloud. It adds things Git itself does not have: a place to share your repo, pull requests for code review, issue tracking, permissions, and automation (GitHub Actions). GitLab and Bitbucket are competitors that do the same job. So Git is the engine, GitHub is one popular place to park a copy of your repo and collaborate around it. Analogy: Git is the word processor on your laptop. GitHub is a shared drive plus a review-and-comments system built around documents made with that word processor. In an interview: Git is the distributed version control tool that runs locally. GitHub is a hosting service built on Git that adds collaboration features like pull requests, issues, and CI. You can use Git without GitHub.

Question 3

What are the working directory, staging area, and repository?

Accepted Answer

Git has three places a change can live. Working directory: the actual files in your folder that you edit. Staging area (also called the index): a list of exactly which changes will go into the next commit. You put changes here with git add. This lets you commit some changes now and leave others for later. Repository: the .git folder, where committed history is stored permanently. git commit takes what is staged and records it here. A change moves working directory to staging with git add, then staging to repository with git commit. Analogy: packing a parcel. The room is your working directory (everything you own). The box is the staging area (only what you decided to send). Posting the box is the commit (now it is on record and on its way). In an interview: Working directory is your files, the staging area is the shortlist for the next commit, and the repository is the saved history. git add moves changes into staging, git commit writes staging into history.

Question 4

What is a commit, and what is a commit hash?

Accepted Answer

A commit is a saved snapshot of your whole project at one point in time, plus a message, the author, a timestamp, and a link to the commit that came before it (its parent). Chaining commits by parent is what forms the history. Each commit has a hash, a 40-character SHA-1 string like a1b2c3d4..., which is a fingerprint of its contents. If anything in the commit or its history changes, the hash changes. You usually refer to a commit by the first 7 characters. The hash is how Git knows two commits are truly identical. Analogy: a photo of your whole project with a caption, filed under a unique reference number. The number is calculated from the photo, so you cannot alter the photo without the number changing. In an interview: A commit is a full snapshot with a message, author, timestamp, and a pointer to its parent. Its hash is a fingerprint of its content and history, so it uniquely and tamper-evidently identifies that snapshot.

Question 5

What is HEAD in Git?

Accepted Answer

HEAD is a pointer to 'where you are right now'. Almost always it points at the current branch, and that branch points at its latest commit. So HEAD effectively means 'the commit my next commit will build on'. When you switch branches, HEAD moves to point at the other branch. If you check out a specific commit directly (not a branch), you get a 'detached HEAD', which means HEAD points straight at a commit with no branch. Commits you make there are easy to lose because no branch is tracking them. Analogy: the 'you are here' arrow on a map. Normally it sits on a labelled path (a branch). If you step off the path onto a random spot (a commit), the arrow still shows where you are, but there is no trail marking your way back. In an interview: HEAD is the pointer to your current position, normally the tip of the checked-out branch. A detached HEAD means it points at a commit with no branch attached, so new commits there are not safely tracked.

Question 6

How is Git different from older centralized tools like SVN?

Accepted Answer

Older tools like Subversion (SVN) are centralized: there is one server that holds the history, and your computer only has the latest version of the files. Every commit, every log lookup, every branch needs the server. Git is distributed: when you clone a repo you get the entire history on your machine. You can commit, branch, view history, and diff completely offline. A remote like GitHub is just another copy that everyone agrees to sync with. This makes Git fast, makes branching cheap, and means there is no single point of failure for the history. Analogy: SVN is a single library where you borrow one book at a time and must go back to the desk for everything. Git gives every person a full photocopy of the whole library, and you occasionally meet up to merge in each other's notes. In an interview: Centralized tools keep history on one server and need it for most operations. Git gives every clone the full history, so almost everything is local, fast, and offline, and remotes are just copies you choose to sync with.

Question 7

How do you start tracking a project with git init or git clone?

Accepted Answer

git init turns the current folder into a Git repository. It creates a hidden .git folder to store history. The files are not tracked yet, you still have to add and commit them. git clone <url> copies an existing repository from a remote (like GitHub) to your machine: it downloads the full history, creates the folder, checks out the default branch, and sets up 'origin' as a link back to where you cloned from. Use init for a brand new project, clone to work on one that already exists. Analogy: git init is starting a fresh notebook. git clone is photocopying someone's finished notebook, including every past page, so you can add your own. In an interview: git init makes a new empty repo in place. git clone downloads an existing repo with its full history and wires up the origin remote. New project: init. Existing project: clone.

Question 8

How do you check what has changed with git status and git diff?

Accepted Answer

git status is the summary: which branch you are on, which files are modified, which are staged for the next commit, and which are untracked (new files Git does not know about yet). git diff is the detail: the exact line-by-line changes. Plain git diff shows changes in your working directory that are not staged. git diff --staged shows what is staged, which is a preview of your next commit. Run status to know what changed, diff to see how. Analogy: status is the table of contents of your changes. diff is reading the actual edited paragraphs with the crossed-out and added text marked. In an interview: git status lists which files are modified, staged, or untracked. git diff shows the actual line changes, with --staged showing a preview of the next commit.

Question 9

How do you stage and commit changes?

Accepted Answer

git add <file> puts a file's current changes into the staging area. git add . stages everything changed in the current folder and below. Staging is a choice: you decide exactly what goes in this commit. git commit -m "message" takes everything staged and records it as a new commit on the current branch. If you skip -m, Git opens an editor for the message. git commit -am "..." is a shortcut that stages all already-tracked modified files and commits in one step (it does not pick up brand new files). Analogy: git add is putting items in the checkout basket. git commit is paying: now it is a recorded transaction you can look up forever. In an interview: git add stages the specific changes you want, git commit records them as a snapshot with a message. -am stages and commits tracked files in one go but ignores new untracked files.

Question 10

What makes a good commit message?

Accepted Answer

A commit should be one logical change, and the message should say what changed and why. The common format: a short summary line under about 50 characters, written in the imperative ('Add', 'Fix', 'Remove', not 'Added' or 'Fixes'), then a blank line, then a longer body explaining the reasoning if it is not obvious. The 'why' is the valuable part. Six months later the diff shows what changed, but only the message can tell you why it was necessary. Analogy: a good commit message is like a lab-notebook entry: 'Switched buffer to 5s because the payment API times out at 4s under load'. A bad one is 'stuff' or 'fix'. In an interview: One logical change per commit, an imperative summary line under about 50 characters, and a body that explains why. The diff already shows what changed, so the message earns its keep by capturing intent.

Question 11

How do you look at history with git log?

Accepted Answer

git log lists commits from newest to oldest with the hash, author, date, and message. On its own it is verbose, so people use flags. git log --oneline gives one line per commit. Add --graph to draw the branch structure, --all to include every branch, and -n to limit the count. git log -p shows the diff for each commit, and git log <file> shows only commits that touched that file. Analogy: the edit history of a shared document, where you can zoom from a one-line-per-change list all the way into the exact text of any single edit. In an interview: git log shows commit history newest first. I usually use --oneline --graph --all for a compact view of all branches, and -p or a filename when I need the detail.

Question 12

What does .gitignore do?

Accepted Answer

.gitignore is a text file listing patterns for files Git should not track: build output, dependency folders like node_modules, secrets like .env, editor settings, log files. Git will not show these as untracked and will not let a plain git add pick them up. Important catch: .gitignore only affects files that are not already tracked. If you committed a file and then add it to .gitignore, Git keeps tracking it until you run git rm --cached on it. Analogy: a 'do not pack' list for moving house: the rubbish, the rented furniture, the perishables. Things that either regenerate or should never leave the building. In an interview: .gitignore lists patterns for files Git should never track, like build artifacts and secrets. It only applies to untracked files, so anything already committed needs git rm --cached to untrack.

Question 13

What is a branch, and how do you create and switch branches?

Accepted Answer

A branch is just a lightweight, movable pointer to a commit. The default is usually called main. Making a branch lets you work on a feature or a fix in isolation without disturbing main, then merge it back when it is ready. git branch creates a branch. git switch moves onto it (older syntax: git checkout ). git switch -c creates and switches in one step. Because a branch is just a pointer, creating one is instant and cheap, which is why Git encourages lots of small branches. Analogy: a branch is a bookmark you can move. 'main' bookmarks the official version. You drop a new bookmark, write a few pages down a side path, and later fold those pages into the main story. In an interview: A branch is a movable pointer to a commit, so it is cheap to create. git switch -c makes and moves onto a new branch, letting you work in isolation and merge back later.

Question 14

How do you merge a branch, and what is fast-forward vs a merge commit?

Accepted Answer

git merge brings the changes from another branch into your current one. If your current branch has not moved since the other branch started, Git does a fast-forward: it just slides the pointer forward. No new commit, history stays linear. If both branches have new commits, Git makes a merge commit: a special commit with two parents that ties the two histories together. Use git merge --no-ff to force a merge commit even when a fast-forward was possible, which keeps a visible record that a feature branch existed. Analogy: fast-forward is catching up to a friend who walked ahead on the same path: you just move to where they are. A merge commit is two paths rejoining, with a signpost saying 'these two routes met here'. In an interview: git merge integrates another branch. If the current branch has not advanced, it fast-forwards the pointer with no new commit. If both have new work, it creates a two-parent merge commit. --no-ff always creates that merge commit.

Question 15

What is a merge conflict and how do you resolve it?

Accepted Answer

A conflict happens when two branches changed the same lines of the same file in different ways, so Git cannot decide which version wins. The merge stops and Git marks the conflicted spots in the file with <<<<<<<, =======, and >>>>>>>. To resolve: open each marked file, edit it to the correct final result, delete the marker lines, then git add the file to say 'resolved', and git commit (or git merge --continue) to finish. git merge --abort backs out entirely and returns to before the merge. Analogy: two editors rewrote the same sentence. The system cannot know which rewrite you want, so it shows you both, side by side, and asks you to write the final sentence yourself. In an interview: A conflict is Git asking you to choose when both sides edited the same lines. You edit the file to the intended result, remove the conflict markers, git add to mark it resolved, and commit. git merge --abort cancels.

Question 16

What is rebase, and how is it different from merge?

Accepted Answer

Both combine work from two branches. Merge keeps both histories and adds a merge commit that joins them. Rebase instead rewrites your branch's commits so they start from the tip of the other branch, as if you had branched from there today. The result is a straight, linear history with no merge commit. git rebase main, run from your feature branch, replays each of your commits on top of the current main. The commits get new hashes because their parent changed. You may have to resolve conflicts commit by commit. Analogy: merge staples your pages into the book where they are, adding a note about where they joined. Rebase re-copies your pages onto fresh paper so they follow directly after the latest chapter, leaving no seam. In an interview: Merge preserves history and adds a joining commit. Rebase rewrites your commits onto the target branch's tip for a linear history with no merge commit. Rebase changes commit hashes, so it is rewriting history.

Question 17

When should you not rebase? What is the golden rule?

Accepted Answer

The golden rule: do not rebase commits that other people have already pulled. Rebase rewrites commits and gives them new hashes. If a branch is shared and you rebase it, everyone else still has the old commits, and their next pull creates a tangled mess of duplicates. So: rebase freely on your own local, unpushed branch to tidy it up. Once work is shared (pushed and others may have it), use merge. The one common exception is your own feature branch that only you use, where a force-push after rebase is fine. Analogy: you can rearrange the furniture freely in your own room. You do not rearrange the shared living room after guests have already memorised where everything is. In an interview: Never rebase commits others have already pulled, because rebase gives them new hashes and everyone else's history diverges. Rebase private unshared work to clean it up, merge once it is shared.

Question 18

What is git cherry-pick?

Accepted Answer

git cherry-pick <hash> copies one specific commit from anywhere and applies it as a new commit on your current branch. It does not bring the branch, just that one change. Common use: a bug fix was committed on a feature branch or on main, and you need only that fix on a release branch without the rest of the work. The new commit has the same changes and message but a different hash, because it has a different parent. Analogy: copying one useful paragraph out of a draft into a different document, rather than merging the whole draft. In an interview: cherry-pick replays a single commit from elsewhere onto your current branch as a new commit. It is for pulling one specific fix across branches without merging everything.

Question 19

How do you discard uncommitted changes to a file?

Accepted Answer

If you edited a file and have not staged or committed it, and you want to throw those edits away and go back to the last committed version, use git restore (older syntax: git checkout -- ). This is destructive: the edits are gone, Git had no record of them. git restore . discards changes to every file. To also delete new untracked files, use git clean -fd, which is even more dangerous, so run git clean -n first to preview. Analogy: hitting 'revert to last saved' on one document. Anything typed since the last save is lost for good. In an interview: git restore throws away uncommitted edits and restores the last committed version. It is irreversible. git clean removes untracked files, so preview with -n first.

Question 20

How do you unstage a file you added by mistake?

Accepted Answer

If you ran git add on something that should not be in the next commit, git restore --staged takes it out of the staging area but keeps your edits in the working directory. (Older syntax: git reset .) Nothing is lost. The change is still there in your files, it is just no longer queued for the next commit. Analogy: taking an item back out of the checkout basket and putting it back on the shelf. You still have it in the shop, you just are not buying it right now. In an interview: git restore --staged removes a file from staging while keeping its edits. It undoes a git add without touching your work.

Question 21

What is the difference between git reset --soft, --mixed, and --hard?

Accepted Answer

git reset moves the current branch pointer to an earlier commit. The flag decides what happens to your changes. --soft: move the branch back, keep everything staged. Good for squashing the last few commits into one. --mixed (the default): move the branch back, keep the changes in your files but unstaged. --hard: move the branch back and throw away all changes in staging and working directory to match that commit. This deletes work. Only use it when you are sure. Analogy: rewinding a tape. Soft: rewind but keep your notes ready to re-record. Mixed: rewind, notes scattered on the desk. Hard: rewind and shred the notes. In an interview: reset moves the branch to an older commit. --soft keeps changes staged, --mixed keeps them unstaged, --hard discards them entirely. --hard is the only destructive one.

Question 22

What is git revert, and when do you use it instead of reset?

Accepted Answer

git revert <hash> creates a new commit that undoes the changes of an earlier commit. The bad commit stays in history, and a new commit on top cancels it out. Use revert, not reset, when the commit has already been pushed and others may have it. Reset rewrites history and would force everyone else to untangle their copies. Revert only adds a commit, so it is safe on a shared branch. Analogy: reset is tearing a page out of the shared book (confusing for everyone who already read it). revert is adding a new page that says 'ignore what page 40 said, here is the correction'. In an interview: git revert adds a new commit that undoes an old one, leaving history intact. It is the safe choice on shared branches, where reset would rewrite history others have already pulled.

Question 23

How do you fix the last commit with git commit --amend?

Accepted Answer

git commit --amend replaces the most recent commit with a new one. Use it to fix a typo in the message, or to add a file you forgot: stage the missing file, then run amend and it folds into the last commit. It creates a new commit with a new hash, so it is rewriting history. Fine if you have not pushed. If you already pushed, you would need a force-push, so only amend shared commits on your own feature branch. Analogy: fixing a signed form before you hand it in, versus after. Before handing it in (not pushed): just correct it. After (pushed): you have to explain the change to whoever received it. In an interview: git commit --amend rewrites the last commit, to fix its message or include a forgotten change. It changes the hash, so only use it before pushing, or on a private branch.

Question 24

What is git stash?

Accepted Answer

git stash takes your uncommitted changes (staged and unstaged), saves them on a side stack, and gives you a clean working directory matching the last commit. Use it when you need to switch branches quickly but your current work is not ready to commit. git stash pop brings the most recent stash back and removes it from the stack. git stash list shows saved stashes. git stash apply brings one back but keeps it in the list. Analogy: sweeping your half-finished work into a labelled drawer so the desk is clear for an urgent job, then tipping the drawer back out afterwards. In an interview: git stash shelves your uncommitted changes and cleans the working directory so you can switch context. git stash pop restores them later.

Question 25

What is the reflog and how does it save you?

Accepted Answer

git reflog is a local log of everywhere HEAD has been: every commit, checkout, reset, rebase, merge. Even when a commit is no longer on any branch, for example after a hard reset or a bad rebase, it is usually still in the reflog for about 90 days, and you can get back to it. Find the hash in the reflog, then git reset --hard or git branch rescue to recover it. The reflog is your safety net for 'I think I just destroyed two hours of work'. Analogy: a CCTV recording of your own movements through the project. Even if you deleted the signpost to a room, the footage still shows the room existed and how to get back to it. In an interview: The reflog records every position HEAD has held, so lost commits from a bad reset or rebase can be found by hash and recovered. It is Git's local undo history for branch operations.

Question 26

What is a remote, and what is origin?

Accepted Answer

A remote is a named link to another copy of the repository, usually one hosted on GitHub. It is just a nickname for a URL. origin is the default name Git gives to the remote you cloned from. You can have more than one remote, for example origin for your fork and upstream for the original project. git remote -v lists them with their URLs. Analogy: a contact in your phone. 'origin' is the saved number for the main office. You can save more contacts, like 'upstream' for head office, and call whichever you need. In an interview: A remote is a named URL pointing to another copy of the repo. origin is the conventional name for the one you cloned from. You can add more, like upstream for the project you forked.

Question 27

What do git fetch, git pull, and git push do?

Accepted Answer

git fetch downloads new commits and branches from a remote into your local copy, but does not change your working files or your branches. It just updates your knowledge of the remote (the origin/main pointer). git pull is git fetch followed by a merge (or rebase) of the remote branch into your current branch. It updates your files. git push uploads your local commits to the remote so others can see them. It only works if your branch is not behind the remote, otherwise you must pull first. Analogy: fetch is checking the noticeboard and copying down what is new. pull is copying it down and acting on it. push is pinning your own note to the board. In an interview: fetch downloads remote changes without touching your work. pull is fetch plus merge into the current branch. push uploads your commits to the remote.

Question 28

What is the difference between git fetch and git pull?

Accepted Answer

git fetch is safe and non-disruptive: it brings the remote's latest commits into your repo but leaves your branches and files exactly as they are. You can then look at what changed with git log main..origin/main before deciding what to do. git pull is fetch plus an immediate merge (or rebase) into your current branch, which changes your files and can produce merge conflicts on the spot. Many people prefer to fetch, review, then merge or rebase deliberately, rather than pull blind. Analogy: fetch is having the delivery left at the door so you can check it first. pull is letting the courier walk in and put everything away immediately. In an interview: fetch updates your view of the remote without changing your branch. pull does fetch then merges into your current branch immediately. Fetching first lets you inspect before integrating.

Question 29

What is an upstream or tracking branch?

Accepted Answer

A tracking branch is a local branch that is linked to a specific remote branch, its 'upstream'. When set, plain git pull and git push know which remote branch to use, and git status can tell you 'ahead 2, behind 1'. git clone sets this up automatically for the default branch. For a new local branch, the first push needs git push -u origin (the -u sets the upstream), and after that plain git push works. Analogy: pairing your phone to one specific speaker. Once paired, 'play' just works. Before pairing, you have to say which speaker every time. In an interview: A tracking branch is a local branch bound to a remote branch, so pull and push know the target and status shows ahead/behind. Set it with git push -u origin on the first push.

Question 30

What is a fork, and how is it different from a branch?

Accepted Answer

A branch is inside one repository. A fork is a whole separate copy of a repository under your own account on GitHub, made with one click. You fork when you do not have permission to push to the original (for example an open-source project). You push to your fork, then open a pull request asking the original project to pull your changes. If you are a team member with write access, you skip forking and just make a branch in the shared repo. Analogy: a branch is a new draft chapter in the shared manuscript. A fork is photocopying the entire manuscript to work on at home because you are not on the official author list. In an interview: A branch lives within a repo. A fork is a personal server-side copy of the whole repo, used when you cannot push to the original. You push to your fork and open a pull request back to the source.

Question 31

What is a pull request?

Accepted Answer

A pull request (PR), called a merge request on GitLab, is a GitHub feature, not a Git command. It is a proposal: 'please merge my branch into yours'. It shows the diff, runs automated checks, and gives teammates a place to comment on specific lines and approve or request changes. The typical flow: push your feature branch, open a PR against main, address review comments with more commits, get an approval and green checks, then merge. The PR becomes a permanent record of why the change was made and who reviewed it. Analogy: submitting an article to an editor with tracked changes. They comment, you revise, and once they sign off it goes into the publication. In an interview: A pull request is a GitHub proposal to merge one branch into another, wrapped in code review, discussion, and automated checks. It is the standard gate before code reaches the main branch.

Question 32

What is the difference between git clone and downloading the ZIP from GitHub?

Accepted Answer

Answer: git clone downloads the whole repository: every file plus the entire .git history, all branches and tags, and it sets up 'origin' pointing back to the remote. You can commit, branch, pull, and push. Downloading the ZIP (the 'Download ZIP' button) gives you only a snapshot of the files at one branch, with no .git folder. It is not a Git repository at all: no history, no branches, no way to pull updates or push changes. You would have to download a fresh ZIP every time. Use clone to work on a project. Use the ZIP only when you just want the files once and will never contribute or update. Analogy: clone is subscribing to a magazine, you keep getting new issues and can send letters back. The ZIP is buying one issue off the shelf. In an interview: clone brings the full history, all branches, and a remote link, so you can pull and push. The ZIP is a one-time file snapshot with no .git, no history, and no way to sync. Clone to work on it, ZIP to just look.

Question 33

What does a typical feature-branch workflow look like?

Accepted Answer

The common team workflow: main is always deployable, and all work happens on short-lived branches off main. 1. Update main. 2. Branch off it. 3. Commit your work in small steps. 4. Push the branch. 5. Open a pull request. 6. Get review and passing checks. 7. Merge into main (often a squash merge). 8. Delete the branch. Keep branches small and short so they do not drift far from main and cause big conflicts. Analogy: each task gets its own short side-trip from the main road, and rejoins quickly. Nobody drives a parallel road for three months. In an interview: Keep main deployable, do all work on short-lived branches, commit in small steps, push, open a PR for review and CI, merge, then delete the branch. Small branches mean small conflicts.

Question 34

How do you keep a feature branch up to date with main?

Accepted Answer

While you work, main moves. Before merging you should bring those changes into your branch so conflicts surface early and the PR merges cleanly. Two ways. Merge main into your branch: git merge main. Safe, keeps history, but adds merge commits into your branch. Rebase your branch onto main: git rebase main. Linear history, no extra merge commits, but rewrites your branch's commits, so if the branch is pushed and shared you must force-push and coordinate. For a solo feature branch, rebase is common; for a shared one, merge. Analogy: merge is stapling in the latest updates as you go. rebase is re-typing your pages so they follow cleanly after the newest chapter each time. In an interview: Regularly bring main into your branch so conflicts appear early. Merge main in for safety on shared branches, or rebase onto main for linear history on a solo branch, force-pushing with --force-with-lease.

Question 35

What is a squash merge?

Accepted Answer

A squash merge combines all the commits on a feature branch into a single commit on main. Your branch might have ten messy commits ('wip', 'fix test', 'typo'), but main gets one clean commit representing the whole feature. GitHub offers it as a merge option on pull requests. The upside is a tidy, readable main history with one commit per feature. The downside is you lose the fine-grained step-by-step history of how the feature was built. Analogy: handing in one clean final essay instead of every rough draft with the crossings-out. The examiner wants the finished piece, not your scratch paper. In an interview: A squash merge collapses a branch's commits into one commit on main. It keeps main history clean and readable at the cost of losing the intermediate commits.

Question 36

How do you check out and test someone else's pull request locally?

Accepted Answer

To run a teammate's branch on your machine, fetch it and switch to it. If it is a branch in the same repo, git fetch then git switch . If it is from a fork, GitHub exposes every PR as a ref you can fetch by number. After testing, switch back to your own branch. This is how reviewers verify a change actually works rather than only reading the diff. Analogy: borrowing a colleague's prototype to try it yourself before signing off, instead of just looking at their photos of it. In an interview: Fetch the branch and switch to it. For PRs from forks, GitHub provides pull//head refs you can fetch into a local branch. Then run it, test it, and switch back.

Question 37

What are tags and releases?

Accepted Answer

A tag is a fixed label on a specific commit, used to mark releases like v1.4.0. Unlike a branch, a tag does not move. git tag -a v1.4.0 -m "message" creates an annotated tag (the recommended kind, it stores author and date). Tags are not pushed by default: git push origin v1.4.0, or git push --tags for all of them. On GitHub, a 'Release' is a tag plus release notes and optional downloadable files, created from the Releases page. Analogy: a tag is a permanent bookmark marking 'this exact page is the first edition'. The story keeps being written past it, but that bookmark never moves. In an interview: A tag is an immutable label on a commit, used for release versions like v1.4.0. Annotated tags store metadata. Push them explicitly. A GitHub Release wraps a tag with notes and artifacts.

Question 38

What common mistakes do people make with Git?

Accepted Answer

Committing secrets (.env, API keys). Once pushed, treat the secret as leaked and rotate it, because it stays in history. Huge commits that mix ten unrelated changes, which makes review and reverting hard. Vague messages like 'fix' and 'update'. Committing generated files and dependencies instead of using .gitignore. Rebasing or force-pushing a shared branch and scrambling everyone's history. Long-lived branches that drift so far from main that merging is a nightmare. Using git reset --hard or git checkout . without realising the changes are gone for good. Analogy: most Git disasters are the same few habits: rushing commits, not reading what you are about to discard, and rewriting history other people are standing on. In an interview: The recurring ones are committing secrets, oversized unfocused commits, weak messages, committing build artifacts, force-pushing shared branches, letting branches go stale, and destructive commands run without checking what will be lost.

Question 39

Quick reference: the commands you use every day

Accepted Answer

If you only memorise one screen, memorise this one. This is the loop almost every working day is made of: see what changed, stage it, commit it, sync with the remote. Analogy: the daily driving routine: check mirrors (status), indicate (add), pull out (commit), join the motorway (push). In an interview: The everyday loop is status, diff, add, commit, pull, push, plus switch for branches and log for history. Everything else is for the less common situations.

Question 40

Reference: setup, config, creating and cloning

Accepted Answer

One-time setup on a new machine, plus the two ways to get a repository. In an interview: git config --global sets your identity and defaults once per machine. git init starts a repo, git clone copies an existing one with its full history.

Question 41

Reference: inspecting, comparing and searching history

Accepted Answer

Commands for answering 'what is the state', 'what changed', 'when did this change', and 'who wrote this line'. In an interview: status and diff for the current state, log for history with filters, show for a single commit, blame for line-by-line authorship, grep to search the tracked files.

Question 42

Reference: branching, merging, rebasing

Accepted Answer

Everything for creating branches, moving between them, and combining their work. In an interview: branch to list and manage, switch to move, merge to combine keeping history, rebase to replay for a linear history, cherry-pick to copy a single commit.

Question 43

Reference: remotes and syncing

Accepted Answer

Managing the named links to other copies of the repo, and moving commits between them. In an interview: remote to manage the links, fetch to download without changing your work, pull to download and integrate, push to upload, with --force-with-lease as the safe force push.

Question 44

Reference: undoing, resetting and recovering

Accepted Answer

The commands for taking things back, from a single unstaged edit all the way to recovering a commit you thought was gone. The ones that delete work are marked. In an interview: restore for uncommitted changes, amend for the last commit, reset to move the branch (soft keeps staged, hard deletes), revert for a safe undo on shared branches, and reflog to recover commits after a bad reset or rebase.

Question 45

Reference: stashing, tagging and housekeeping

Accepted Answer

Shelving work in progress, marking releases, and keeping the repo tidy. In an interview: stash to shelve work while you switch context, tag to mark releases, rm --cached to untrack a file, mv to rename one, gc to compact the repo.

Git & GitHub interview preparation

How Git works

The everyday workflow

Branches and merging

Undoing mistakes

Remotes and GitHub

Working with a team

Command cheat sheet