What Git is, clone vs fetch vs pull, repositories, commits, branches, merges and conflicts, remotes, Gitflow vs GitHub Flow, reverting commits, and five everyday scenarios — stashing, resolving a conflict, rebasing onto main, and safely undoing a bad deploy.
Published September 25, 2026
Git questions for freshers are practical: "what would you type?". Give the actual commands, and add one safety note wherever history is being rewritten. Never rewrite history on a shared branch is the rule interviewers most want to hear.
Short answer: Git is a distributed version control system. Every clone holds the full history, so commits, branches, diffs and log searches all work locally and quickly, even offline. Centralised systems such as SVN keep the history on one server, and most operations need the network.
Key points to cover:
git clone, git fetch and git pull?Short answer:
clone: copies a remote repository to your machine, once. It includes the full history, and sets up origin.fetch: downloads new commits and branches from the remote into the remote-tracking branches (origin/main), without touching your working branch.pull: fetch plus integrating the changes into your current branch, by merge (the default) or rebase (--rebase).git fetch origin
git log --oneline main..origin/main # see what's new before integrating
git pull --rebase # replay my local commits on top of the latest remote
Short answer: The .git directory and its contents: the object database (commits, trees, blobs, tags), refs (branches and tags pointing to commits), the index (staging area) and the configuration. Together with the working tree, it tracks every version of the project.
Key points to cover:
git init --bare) has no working tree. Servers (GitHub, GitLab) host bare repositories.Short answer: A commit is an immutable snapshot of the whole project. It records a tree of files, parent commit(s), author and committer, timestamps and a message, all identified by a SHA hash. Commits form a DAG (directed acyclic graph), which is the project's history.
Key points to cover:
feat:, fix:) to generate changelogs.Short answer: A branch is just a movable pointer (ref) to a commit. Creating one is almost free. As you commit on a branch, the pointer moves forward. HEAD points to the branch you have checked out.
git switch -c feature/order-export # create and switch (the modern replacement for checkout -b)
Short answer: A merge integrates the history of one branch into another:
Key points to cover:
--no-ff forces a merge commit, which preserves the fact that a feature branch existed.Short answer: A conflict happens when both branches changed the same lines of a file (or one side edited a file the other deleted), so Git can't decide which change wins. Git marks the file with conflict markers, and stops so you can resolve it by hand.
<<<<<<< HEAD
int timeoutMs = 2000;
=======
int timeoutMs = 5000;
>>>>>>> feature/slow-partner
Short answer: A remote is a named reference to another copy of the repository, usually on a server, such as origin → https://github.com/shop/order-service.git. You fetch from remotes and push to them. Forked workflows often also have an upstream remote.
git remote -v
git remote add upstream https://github.com/shop/order-service.git
Short answer:
main (releases), develop (integration), and short-lived feature/*, release/* and hotfix/* branches. It suits versioned, scheduled releases, such as installed software, but it's heavyweight.main is always deployable. You create a short-lived branch, open a pull request, get it reviewed and tested by CI, merge it, and deploy. It suits continuous delivery of web services.Short answer: Use git revert <sha>. It creates a new commit that applies the inverse of the given commit, so history is preserved, and it's safe on shared branches.
git revert a1b2c3d # undo one commit
git revert -m 1 <merge-sha> # undo a merge commit (keep parent 1: the mainline)
Key points to cover:
git reset moves the branch pointer backwards. It rewrites history, so use it only on commits that haven't been pushed.feature-x, and priorities change. How do you put your work on hold and start a new task?Short answer: Save the uncommitted work, branch from an up-to-date main, and come back later.
git stash push -m "feature-x: half-done export" # shelve uncommitted changes (add -u to include untracked files)
git switch main && git pull
git switch -c feature-y # the new task
# … later …
git switch feature-x
git stash pop # restore the shelved work
Key points to cover:
feature-x (git commit -m "WIP"), amended or squashed later. Stashes are easy to forget.feature-y into main gives a conflict in Abc.java. How do you resolve it?Short answer:
git switch main
git merge feature-y # CONFLICT (content): Merge conflict in Abc.java
git status # lists the conflicted files
# edit Abc.java: combine both intentions, delete the <<<<<<< ======= >>>>>>> markers
./mvnw test # make sure the combined code still compiles and passes tests
git add Abc.java
git commit # completes the merge (or: git merge --abort to back out)
Key points to cover:
git config rerere.enabled true remembers how you resolved repeated conflicts.main. How do you use rebase to update it?Short answer: Replay your branch's commits on top of the latest main:
git fetch origin
git switch feature-z
git rebase origin/main # resolve any conflicts commit by commit: fix, git add, git rebase --continue
git push --force-with-lease # needed if the branch was already pushed; refuses to clobber others' new commits
Key points to cover:
main or other shared branches.--force-with-lease is the safe form of force-pushing.Short answer: Stash them, fix the bug on its own branch, then restore them:
git stash push -m "wip before hotfix"
git switch -c hotfix/null-price main
# fix, commit, push, open a PR
git switch - # back to the previous branch
git stash pop # or 'git stash apply' to keep a copy in the stash list
Key points to cover:
git stash list shows the stashes, and git stash show -p stash@{0} shows what's in one.git worktree add ../hotfix main) let you work on the hotfix in a separate folder, without stashing at all.Short answer: On a shared branch such as main, use git revert. It creates a new commit that undoes the change, deploys like any other commit, and doesn't disturb anyone else's history.
git revert <bad-sha>
git push
Remove the commit from history (git reset --hard HEAD~1, then a force push) only if it hasn't been shared, or if the team explicitly agrees. For example, when secrets were committed: then you also rewrite history with git filter-repo and rotate the leaked secret immediately.
Common trap: answering git reset --hard HEAD~1 for a deployed commit. The commit is already on the remote, so a reset requires a force push. That breaks every teammate's clone, and can silently discard other people's commits.
Q: What's the difference between git reset --soft, --mixed and --hard?
A: All three move the branch pointer. --soft keeps your changes staged. --mixed (the default) keeps them in the working tree, but unstaged. --hard discards them, so use it carefully.
Q: How do you recover a commit you accidentally reset away?
A: git reflog lists every position HEAD has been at. Find the lost commit's SHA, then run git reset --hard <sha> or git branch rescue <sha>.
Q: What does git cherry-pick do?
A: It applies the changes from specific commits onto your current branch, creating new commits. It's typically used to port a hotfix to a release branch.
Q: What does .gitignore do?
A: It lists files Git shouldn't track: build output (target/), IDE files, and local secrets (.env). A file that's already tracked must be removed with git rm --cached before an ignore rule takes effect.