Git Interview Questions

"Git is the version control tool itself. It runs on my laptop, and because it's distributed, every clone has the whole history, so I can commit, branch, look at logs and diff old versions with no network at all. GitHub is a hosting service built around Git. It stores a copy of the repository on a server and adds the team features: pull requests and code review, issues, permissions, and CI through Actions. So yes, I can use Git without GitHub, for a personal project or with another host like GitLab or Bitbucket, or even a bare repository on a shared server. Using GitHub without Git doesn't really make sense, because what GitHub hosts is a Git repository. The web editor just makes Git commits for you."

"There are three places a change can be. The working tree is just my files on disk, where I edit. The index, or staging area, is the draft of my next commit. When I run git add, Git copies the current content of that file into the index. Then git commit takes whatever is in the index and saves it as a commit in the repository, which is the .git folder. The useful part is that the index lets me commit only part of my work. If I fixed a bug and also tidied some formatting, I can stage just the bug fix, even just some hunks with git add -p, and commit that alone. To see where things are, git status shows all three, git diff shows what I changed but haven't staged, and git diff --staged shows what's about to be committed."

"Conceptually a commit is a snapshot, not a diff. It points to a tree object, which lists every file and folder in the project at that moment, and the files themselves are stored as blobs. On top of that it records its parent, or two parents for a merge, the author and committer with timestamps, and the message. The whole thing is hashed, and that hash is the commit's ID. Because the parent is part of what gets hashed, each commit locks in the full history behind it. That's why commits are effectively immutable: if I amend a message or rebase, I don't change a commit, I create a new one with a new hash. Diffs you see in git log or git show are computed on the fly by comparing snapshots. It stays space-efficient because an unchanged file is the same blob in every commit, and packfiles compress similar content."

"Stash takes my uncommitted changes, saves them on a stack, and gives me a clean working tree, so I can switch branches and fix the urgent thing. When I'm back, git stash pop puts the changes back and removes the entry. There are a few gotchas. By default it only stashes tracked files, so a brand new file I haven't added stays behind in the working tree; I use -u to include untracked files. If popping causes a conflict, Git keeps the stash entry so nothing's lost, and I resolve and drop it myself. And stashes pile up with vague names, so I always add a message with -m. For anything I'll be away from for more than an hour, I honestly prefer a quick 'wip' commit on my branch and amending it later, because a commit lives on a branch and is harder to forget about than an old stash entry."

"A branch and a tag both point at a commit. The difference is that a branch moves forward every time someone commits on it, while a tag is meant to stay fixed, so it's how we mark releases like v1.4.0. There are two kinds. A lightweight tag is only a name pointing at a commit, fine for a private bookmark. An annotated tag is a proper object stored in the repository, with who created it, when, and a message, and it can be signed so people can verify it. For releases I always use annotated tags. One thing that catches people: a normal git push doesn't send tags. I push the tag by name, or use --tags. And moving a published tag is a bad idea, because anyone who already fetched it keeps the old one, so if a release was wrong I cut a new version instead."

"The .gitignore file only applies to untracked files. It tells Git not to pick up new files that match. If the file was committed before the rule existed, Git is already tracking it and keeps showing changes. To fix it, I run git rm --cached on the file. That removes it from the index, so it'll be deleted from the repository in the next commit, but it stays on my disk. I commit that together with the .gitignore change. There's one side effect to warn the team about: when they pull that commit, Git removes the file from their working trees too, so for something like a local config file they should back it up first. And if the file ever held secrets and was pushed, ignoring it now doesn't help, because it's still in history, so the secret needs rotating. For debugging rules, git check-ignore -v tells me exactly which pattern matched a path."

"A branch is just a name that points to one commit. Internally it's a tiny file holding a commit hash. When I commit on that branch, Git makes the new commit with the old tip as its parent and moves the pointer forward. That's why creating a branch is instant: it's not a copy of anything. HEAD tells Git where I am. Normally it points to a branch, like main, so a new commit moves main. Detached HEAD means HEAD points directly at a commit instead of a branch, which happens if I check out a tag or an old hash to look around. I can still commit there, but no branch moves, so if I switch away those commits aren't on any branch and are easy to lose. If I want to keep them, I run git switch -c with a new branch name right there. And if I already switched away, the reflog still has the hash."

"A fast-forward happens when the branch I'm merging into hasn't moved since I branched off. Say main is at commit A, I branch, and add B and C. If nobody touched main, merging my branch doesn't need a new commit, because C already contains everything. Git just slides main forward to C. The history stays a straight line. Some teams use --no-ff to always create a merge commit anyway. The benefit is that the history shows 'feature X came in here', all its commits hang off that merge, and if the feature has to come out, I can revert that one merge commit. The cost is more merge commits in the log. There's also --ff-only, which I like for pulling main: it refuses to merge if my local branch has diverged, so I never get a surprise merge commit."

"Both get main's changes into my branch, but they shape history differently. A merge takes the two tips and creates a merge commit with two parents. Nothing that already exists changes, so it's safe on any branch, and the log shows what really happened, but it can get noisy with lots of 'merge main into feature' commits. A rebase takes my commits, sets them aside, moves my branch to the tip of main, and replays them one by one. The result looks like I started from the latest main, a clean straight line, but every replayed commit is new with a new hash. If there are conflicts, I may resolve them commit by commit. My rule is simple: I rebase my own branch while nobody else is building on it, to keep it tidy before review. Once a branch is shared, I merge, because rewriting commits other people have makes a mess for them."

"First I run git status to see which files are unmerged. In each file, Git has put conflict markers: the part between the opening marker and the equals line is my side, HEAD, and the part after is the incoming branch. I don't just pick one side. I read both and figure out what each change was trying to do, and if it's not obvious I look at the commits on each side or ask the person who wrote them. Then I edit the file to what the combined code should be, delete all the markers, and search for any stray ones. Before committing I build and run the tests, because a file can merge cleanly and still be broken. Then git add on each resolved file and git commit to finish the merge. If I realise it's messier than I thought, git merge --abort puts me back exactly where I was before the merge."

"Git compares each branch tip to their common ancestor, the merge base. That's the three-way merge. For each part of a file, if only my side changed it compared to the base, Git takes my version. If only their side changed it, Git takes theirs. If both sides made the identical change, that's fine too. It's only a conflict when both sides changed the same region in different ways, because Git has no way to know which is right. That model also explains the blind spot: Git works on text, not meaning. If I rename a function on my branch and a teammate adds a new call to the old name in a different file, the merge is perfectly clean and the build is broken. So a clean merge tells me there's no textual overlap, and the tests tell me if it works. I also like the diff3 conflict style, which shows the base version inside the markers."

"Rebase doesn't move commits, it makes new copies with new hashes and drops the old ones from the branch. On my own branch that's harmless. But say I rebase a branch two teammates have pulled, and force push it. Their local branches still point at the old commits, and anything they committed since is built on top of those. When they pull, Git sees two different histories with the same changes in different commits. Depending on what they do, they get a merge that brings the old commits back next to the new ones, so every change appears twice, or they reset to the remote and lose their own work. Either way someone spends an afternoon untangling it. So the real rule is: don't rewrite commits that other people have based work on. Rebasing my feature branch before I open the pull request, or while I'm the only one pushing to it, is fine and I do it all the time."

"I use an interactive rebase. I fetch first, then run git rebase -i against origin/main, so it covers exactly the commits on my branch and also puts them on top of the latest main. Git opens a list of my commits, oldest at the top. I keep the meaningful ones as pick, mark the 'wip' and 'fix typo' ones as fixup so they fold into the commit above them and their messages disappear, and use reword where a message needs fixing. I can also reorder lines to group related changes. I'm aiming for a handful of commits that each tell one part of the story. When I save, Git replays them. Because the hashes are new, I push with --force-with-lease, which is fine since it's my branch and nobody's built on it. Going forward, git commit --fixup plus rebase with --autosquash saves me doing this by hand."

"If I haven't pushed yet, it's one command. I git add the file I forgot, then run git commit --amend with the corrected message. That replaces my last commit with a new one containing both the original changes and the file, with the fixed message. If the message was fine and I only forgot the file, I add --no-edit so it keeps the old message. The thing to remember is that amend doesn't edit the commit, it creates a new one with a new hash. So if I'd already pushed, the remote has the old commit and a normal push would be rejected. On my own feature branch I'd amend and push with --force-with-lease. If other people might have pulled it, I'd leave history alone and just make a small follow-up commit adding the file."

"Cherry-pick takes the change introduced by one commit, the diff between it and its parent, and applies it on my current branch as a new commit. It's the same change, but a different commit with a different hash. The classic use is a hotfix: we fix a bug on main and also need it on the release branch that's already in testing, but we can't merge main there because it would drag in unfinished features. So I switch to the release branch and cherry-pick just the fix. I use -x so the message records which commit it came from. Another use is when I committed on the wrong branch and want to move that one commit. I don't use it as a substitute for merging whole features, because you end up with duplicate commits all over the place, and when the branches are merged later, Git may have to reconcile the same change twice."

"All three modes start the same way: they move the branch I'm on back to the commit I give, say HEAD~1. The difference is how far the reset spreads into the other two areas. With --soft, it only moves the branch. My index and files stay as they were, so the changes from the undone commit show up as staged, ready to recommit. I use that to redo a commit or combine the last few into one. --mixed is the default. It also resets the index, so the changes are still in my files but unstaged. Good for splitting a commit differently. --hard also resets the working tree to match, so everything since that commit is thrown away, including any edits I hadn't committed. Committed work can usually be found again through the reflog, but uncommitted changes wiped by --hard are usually gone for good. So I run git status before any hard reset."

"They undo things in opposite ways. Reset moves my branch pointer backwards, so the commits I reset past are no longer on the branch. That's rewriting history, which is fine when the commits only exist on my machine. Revert doesn't remove anything. It creates a new commit that does the exact opposite of the one I'm undoing, so the bad change is cancelled but both commits stay in the history. That's what I use once a commit has been pushed to a shared branch like main. Everyone can just pull the revert like any other commit, nobody's history breaks, and there's a clear record that the change was backed out and why. If I reset and force pushed main instead, I'd be pulling commits out from under everyone who already has them."

"Because main is shared, I revert rather than reset. A merge commit has two parents, so a plain revert doesn't know which side to go back to. I run git revert -m 1 with the merge hash. Parent one is the branch that was merged into, main, so this says: make main look like it did before the feature came in. That lands as a normal new commit everyone can pull. The part people miss comes later. The feature's commits are still in main's history, the revert just cancelled their effect. So when the team fixes the feature and merges the same branch again, Git sees those old commits as already merged and only brings in the new fixes, and the original code stays missing. The fix is to revert the revert first, which restores the feature's changes, and then merge the new work on top."

"First I'd post in the team channel that it's my merge and I'm looking at it, so nobody else wastes time investigating. Then I'd check whether it's a one-line obvious fix. If it isn't clear within a few minutes, I'd revert. If it was a merge commit, that's git revert -m 1 on the merge; if it was squash-merged, a plain revert of that commit. I'd push the revert through the normal path, so main goes green and people can deploy again. I wouldn't reset main and force push, because others have already pulled it. Then, with no pressure, I'd find the cause on my branch. Often it's something that passed on my branch but conflicts with what landed on main in between. I'd add a test that fails without the fix, re-open the pull request, and afterwards ask whether our checks should run against the latest main before merging."

"git fetch talks to the remote, downloads any new commits, and updates my remote-tracking branches, like origin/main. It doesn't touch my own branches or my files, so it's always safe to run. git pull is a fetch plus a second step that integrates the remote branch into my current branch, by default with a merge, or with a rebase if I pass --rebase or set it in config. Some developers avoid pull because that second step can surprise you: if your branch and the remote both have new commits, you get an automatic merge commit or a conflict you weren't expecting. Recent versions of Git refuse and tell you to choose merge or rebase when the branches have diverged and you haven't configured it. I usually fetch, look at git log HEAD..origin/main to see what came in, then rebase or merge deliberately."

"It means someone pushed to that branch after I last synced. My branch and the remote have diverged, so if Git accepted my push, the remote branch would jump to my commit and their commits would drop off it. Git refuses rather than lose work. The wrong fix is adding --force, because that's exactly what deletes their commits. The right fix is to bring their work in first. I run git fetch, check what came in, then either rebase my commits on top of origin's version, which is what I do on a feature branch to keep it tidy, or merge it if that's the team's habit. git pull --rebase does both steps in one. If there are conflicts I resolve them, run the tests, because their change and mine now meet for the first time, and then push again, which goes through as a normal fast-forward."

"Plain --force says: make the remote branch equal to mine, whatever's there. If a teammate pushed five minutes ago, their commits are gone from the remote. --force-with-lease adds a check. It compares the remote branch with my remote-tracking ref, origin slash that branch, which is what I last saw. If the remote has moved since, it refuses, so I don't overwrite work I haven't seen. That's why I use it after rebasing my own branch. It isn't perfectly safe, though. The check is against my last fetch, not against what I actually looked at. If my editor fetches in the background, origin's ref updates to include the teammate's commit, the lease passes, and I overwrite it anyway. The --force-if-includes option closes that gap by also checking that the remote tip I last fetched is something I actually integrated into my local branch. And for main and release branches, the real protection is branch protection on the server, so nobody can force push there at all."

"The commits aren't gone, the branch just stopped pointing at them. Git keeps unreferenced commits around until garbage collection eventually cleans them up, and the reflog records every place HEAD has pointed, locally. So I run git reflog and look for the line just before the reset, something like 'commit: add export'. That hash is my old tip. Before doing anything clever I pin it by creating a branch at that hash, so it can't be lost again. Then I can reset my branch back to it, or merge it. The same trick recovers a deleted branch or commits made in detached HEAD. The limits matter. The reflog exists only on my machine, it's not pushed, and old entries expire. And if the reset --hard also wiped changes I never committed, the reflog can't help, because those were never commits. If they had been staged, git fsck can sometimes find the loose file content, but that's a last resort."

"The first step isn't a Git command, it's revoking the key. Once it's been pushed, I have to assume someone has it, especially on a public repository, where automated scanners look for exactly this. So I'd rotate it with the provider, update the running services with the new key, and tell my lead or the security team, and check the provider's logs for any use I don't recognise. Then the code: remove the key, read it from an environment variable or the secrets manager, and add the config file to .gitignore. Deleting it in a new commit doesn't remove it from history, so the old commit still shows it. Whether to rewrite history depends on the team. If we do, I'd use git filter-repo to strip it, force push with everyone warned, and have people re-clone. But clones, forks and caches may still hold it, which is exactly why rotating the key is the real fix and rewriting is just tidying up."

"First, I don't force push back, because that would wipe whatever they just pushed, and we'd be taking turns deleting each other's work. My commits are almost certainly still on my machine, on my local branch. Even if I'd already pulled, the reflog would have them. So I'd fetch, then create a rescue branch at my current local tip so nothing can be lost. I'd compare it with the new remote to find the commits the remote no longer has and pick out my two. Then I'd reset my local branch to match the new remote and cherry-pick just those two commits on top, run the tests, and push normally, with no force needed. Then I'd talk to the teammate, not to blame them, but because they probably rebased without realising others were pushing to the branch. We'd agree that shared branches never get force pushed, or only with --force-with-lease after a heads-up in the channel."

"In trunk-based development, main is the one branch that matters. People work on small branches that live a day or two at most, merge them often, and anything unfinished ships switched off behind a feature flag. It needs good automated tests and CI, because main must always be releasable. Git Flow has a develop branch where features collect, release branches where a version is stabilised, main holding what's been released, and hotfix branches for urgent fixes. It fits software that ships as numbered versions on a schedule, like a mobile app or a library where you support several versions at once. For a web app deploying several times a day, I'd pick trunk-based. Git Flow's extra branches slow that down, and long-lived branches are exactly what causes big painful merges. I'd back it with branch protection, required checks on every pull request, and feature flags, so merging often doesn't mean releasing half-built features."

"As an author, the biggest thing is size. One pull request does one thing, so a reviewer can actually read it instead of skimming. The description says what changed, why, and how to test it, with screenshots for UI work and a link to the ticket. I review my own diff first, because I always catch something, and I make sure CI is green before I ask anyone. During review I reply to every comment, even if it's just 'done', and I push fixes as new commits so reviewers can see what changed since last time, rather than force pushing over everything silently. As a reviewer, I try to respond within the day, because a pull request waiting three days turns into a merge conflict. I explain why I'm asking for a change, I separate blocking issues from nits, and I comment on the code, not the person. Approving with small suggestions is fine."

"At my last company we used Git Flow with a develop branch and fortnightly release branches, but we deployed a web app and customers were waiting two weeks for tiny fixes. Worse, release branches regularly needed a day of conflict fixing and cherry-picks. I pulled the last few releases' history and showed the team how much time went into merging rather than building. I proposed trunk-based development: short branches merged to main within a couple of days, feature flags for unfinished work, and main protected, with required CI and one approval. Some people worried about half-built features going live, so we ran it on one service for a month first, with flags and a clear rollback plan, which was just reverting. It worked, merge pain mostly disappeared, and we went from fortnightly releases to deploying most days. Then we rolled it out to the rest. What I'd change is investing in tests earlier, because a flaky suite nearly killed the trial."

"In my last job, the evening before a client demo, a teammate ran git reset --hard on the wrong branch and his whole afternoon of commits vanished. He was about to start rewriting. I asked him to stop and not run anything else, because the commits were almost certainly still there. We ran git reflog, found the commit line from just before the reset, and I had him create a branch at that hash first so it was safe, then reset his branch back to it. Everything was back in about ten minutes and the demo went fine. Afterwards we changed two things. We agreed to push feature branches at least daily, so work always lives somewhere besides one laptop. And I did a short session for the team on reflog and on using git status before any hard reset. Since then, when someone panics about lost work, they check the reflog before messaging anyone."

"In my final-year project, I spent three weeks on a branch reworking the booking module while a teammate refactored the same service layer for a new feature. Neither of us had merged main in that time. When I tried, there were conflicts in about fifteen files, and in several the right answer needed both our changes combined. Instead of resolving her side by guessing, I asked her to sit with me for an hour. We went file by file: she explained the intent of her changes, I explained mine, and we wrote the combined version together. Then we ran the full test suite and clicked through the booking flow, because a couple of files had merged cleanly but called methods she'd renamed. The lesson was about branch lifetime, not Git. After that we rebased on main every day and split work into smaller pull requests, and we never had a merge like that again."