Git Interview Prep

Think of Git like a time machine for your code. Every time you save a "snapshot" (called a commit), Git remembers exactly what every file looked like at that moment. Mess something up? Roll back. Want to try a crazy idea without breaking the main code? Create a branch.

The "distributed" part means everyone on your team has the full history on their own machine — not just a connection to one central server. So even if the server dies, nobody loses any work.

Git was created by Linus Torvalds in 2005 — the same guy who made Linux — specifically because he was frustrated with how slow and restrictive existing tools were for managing the Linux kernel.

Git is like the engine. GitHub is like the car dashboard — it makes the engine easier to use and shows you everything nicely. You can use Git completely without GitHub (just local repos), but you can't use GitHub without Git under the hood.

GitHub adds things Git doesn't have: pull requests, issue tracking, Actions (CI/CD), project boards, a web UI to browse code, and social features like stars and forks. Alternatives to GitHub include GitLab, Bitbucket, and Azure DevOps — they all wrap around Git.

When you run git init in a folder, Git creates a hidden .git directory inside it. That .git folder IS the repository — it stores every commit, branch, tag, and config. The files you see in the folder are just your working copy.

There are two kinds: local repos (on your machine) and remote repos (on GitHub/GitLab/server). They sync through push and pull. You can have multiple remote repos — like origin pointing to your GitHub fork and upstream pointing to the original project.

Imagine you're working on a Google Doc with a team, but you turned off auto-sync. git fetch is like checking "what did others change?" without applying anything. git pull is like applying all those changes to your own doc right now.

git pull is literally just a shortcut for git fetch followed by git merge. In teams, many senior engineers prefer git fetch + manual review before merging, so they know exactly what's coming in before it hits their branch.

Imagine you're writing a book with a friend. Merge is like: "Here's my chapters, here's yours, here's a note saying we combined them on Tuesday." Rebase is like: "Let me rewrite my chapters as if I had started writing after you finished yours" — so the final result looks like a single clean story, with no "combination note" in the middle.

Merge is safer and more honest — it shows the real history of what happened. Rebase makes history look cleaner and easier to read with git log, but it literally rewrites commit hashes. That's why the golden rule of rebase is: never rebase commits that have already been pushed to a shared branch.

In practice: teams use merge for integrating feature branches into main (preserving history), and rebase for keeping a feature branch up to date with main (before opening a PR).

Think of the main branch as the "live" train track. When you create a branch, you're laying a new side track from a specific point. You can work on that side track as long as you want, and when your feature is ready, you merge it back into the main track.

Because a branch is literally just a file containing a commit hash (40-character string), creating a branch is basically free and instant. This is very different from SVN (an older VCS) where branching was expensive and slow. In Git, most teams create a new branch for every single feature or bug fix.

Without PRs, developers could push anything directly to main. That's chaos in a team. PR is the "checkpoint" — your code needs a second pair of eyes before it can join the main codebase. It's standard in every real-world team.

PRs let reviewers leave comments, suggest changes, approve, or request changes. CI/CD pipelines (like GitHub Actions) run tests automatically on every PR, so bugs get caught before merging. It also creates a documented history of why changes were made.

Imagine you're halfway through a feature, and your manager says "quick, fix this prod bug!" You can't commit half-done work. You can't throw it away. git stash is like a drawer where you shove your half-finished work, switch to fix the bug, then come back and pull your work out of the drawer with git stash pop.

You can have multiple stashes. git stash list shows them all. git stash pop applies the latest and removes it from stash. git stash apply applies it but keeps it in the stash (useful when applying the same changes to multiple branches).

Think of git reset as going back in time and pretending commits never happened. The commits are gone (or detached). It's like erasing pages from a book. Safe for local work — dangerous if you've already pushed.

git revert is the opposite: you add a new page to the book that says "undo everything on page 37." The original page 37 is still there. It's transparent, safe for team repos, and doesn't rewrite history.

Reset has three modes: --soft (uncommit but keep changes staged), --mixed (default — uncommit, unstage, keep in working directory), --hard (uncommit AND delete changes from working directory — dangerous!).

Git is pretty smart about merging. If you changed line 5 and your teammate changed line 50, it handles that automatically. But if you both changed line 5? Git throws up its hands and says "I don't know which one you want — you decide." That's a conflict.

Git marks the conflicting section in the file with <<<<<<<, =======, and >>>>>>> markers. Above the ======= is your change. Below is theirs. You have to manually pick one (or combine them) and remove the markers.

Step 1: Git tells you which files have conflicts after git merge or git pull. Run git status to see them listed under "Unmerged paths."

Step 2: Open each conflicted file. Look for the <<<<<<< markers. Edit the file to look exactly how you want the final version to be — you're not restricted to choosing one side, you can blend both if needed.

Step 3: After fixing the file, run git add <filename> to mark it as resolved. Do this for all conflicted files. Then run git commit to finalize the merge.

Modern editors like VS Code show conflicts with a nice UI — "Accept Current," "Accept Incoming," "Accept Both." Tools like git mergetool open a three-way diff viewer.

Local repo lives in the .git folder on your laptop. You can commit, branch, and log without any internet. Remote repo is hosted online — it's the shared source of truth for the whole team.

When you git push, you send your local commits to remote. When you git pull, you bring remote commits down. A project can have multiple remotes — origin is just the conventional name for the primary one.

Not everything in your project folder belongs in the repo. node_modules/ (huge, auto-generated), .env (has secret API keys), __pycache__/ (Python compiled files), dist/ (build output) — all of these should be ignored.

You put patterns in .gitignore and Git pretends those files don't exist. The .gitignore file itself should be committed to the repo so all teammates use the same rules. A good starting point: gitignore.io generates .gitignore files for your specific tech stack.

Fork is a GitHub/GitLab concept, not a Git command. When you fork a public project (like an open-source library), you get your own copy in your GitHub account where you have full push access. Then you clone THAT fork to your machine, make changes, and send a Pull Request to the original project.

Clone is a pure Git operation — it just downloads a repo to your machine. The origin remote is set to whatever URL you cloned from.

You can think of HEAD as "you are here" on the Git map. It's a file in .git/HEAD that usually contains a reference to a branch name (like ref: refs/heads/main). When you make a new commit, HEAD moves forward to that new commit. When you switch branches, HEAD updates to point to that branch.

HEAD~1 means "one commit before HEAD." HEAD~3 means "three commits back." This syntax is used heavily with reset, log, and rebase commands.

git add . is convenient but can accidentally stage files you didn't mean to commit (debug logs, temporary test files). git add <file> gives you precise control. In professional teams, many engineers use git add -p (patch mode) to stage changes chunk by chunk — this lets you make one clean commit even if you changed multiple unrelated things in the same session.

Normally: HEAD → branch → commit. In detached HEAD: HEAD → commit (no branch in between). It's like stepping off the main track onto a platform — you can look around, even write things down, but if you leave without marking where you are, you'll never find it again.

This happens when you git checkout <commit-hash> or git checkout v1.0.0 (a tag). It's useful for inspecting old code. But if you make new commits here and then git checkout main, those commits become unreachable — "dangling commits" that Git will eventually garbage-collect.

Fix: before switching away, run git branch my-save-branch to create a branch pointing to where you are. Now it's safe.

Feature Branch Workflow (most common): Everyone branches off main for their feature, pushes when done, opens a PR, gets code reviewed, then merges back. Main is always deployable.

Git Flow: Has separate main, develop, feature/*, release/*, and hotfix/* branches. Used in projects with scheduled release cycles. More structure, more overhead.

Trunk-Based Development: Everyone pushes small, frequent commits directly to main (or short-lived feature branches that merge daily). Preferred by Google, Facebook, Netflix. Requires good CI/CD and feature flags. Moves fast, less merge pain.

If you just committed locally and want to undo it: git reset --soft HEAD~1 undoes the commit but keeps your changes staged. git reset --mixed HEAD~1 (default) unstages them too but keeps files. git reset --hard HEAD~1 deletes the changes entirely.

If it's already pushed to a shared branch: git revert HEAD creates a new "undo commit" on top. Everyone on the team can pull this cleanly without history conflicts. Never git push --force on shared branches unless you're absolutely sure and have team agreement.

This is a classic real-world scenario. First, look at what was actually merged. Run git log --merge to see commits that caused the conflict, or git diff HEAD~1 HEAD to see what changed in the latest merge commit.

Second, check for "resolved" conflicts where someone chose the wrong side. These are the sneakiest bugs — Git shows the conflict as resolved but the logic is now broken. Search the diff for lines around <<<<<<< markers that might've been removed but left incorrect code.

Third, use git bisect — an incredibly powerful command that does a binary search through your commit history to find the exact commit that introduced the bug. You run git bisect start, mark the current commit as bad (git bisect bad), mark a known-good older commit as good (git bisect good <hash>), and Git checks out commits in between for you to test. Takes O(log n) steps to find the culprit.