›What's the difference between git merge and git rebase?
Both integrate changes from one branch into another. Merge creates a new commit with two parents, preserving exact history including how development actually interleaved. Rebase replays your branch's commits on top of the target's latest commit one by one, producing linear history with new commit hashes — never do this on commits someone else has already pulled.
›What's the difference between git fetch and git pull?
fetch downloads new commits and branch refs from a remote without touching your working branch at all. pull is
fetch immediately followed by a merge (or rebase, depending on config) into your current branch. Fetch is the
safe way to see what changed before deciding how to integrate it.
›How would you recover a commit after a hard reset?
git reflog — it logs every place HEAD has pointed, including commits a reset just stopped referencing rather than
actually deleted. Find the commit hash there, then git checkout or git cherry-pick it back. This works until
Git's garbage collector eventually reaps genuinely unreferenced objects.
›What's the difference between git reset --soft, --mixed, and --hard?
All three move HEAD (and the current branch pointer) to a different commit. --soft leaves the working directory
and staging area untouched — undone commits' changes stay staged. --mixed (the default) also unstages them,
leaving them as unstaged working directory changes. --hard discards the changes entirely, resetting the working
directory to match the target commit.
›Why is git revert safer than git reset for a commit that's already been pushed?
revert creates a new commit that undoes a previous one's changes, without altering existing history — safe for
anyone else who's already pulled. reset moves the branch pointer backward, and force-pushing that rewrites shared
history out from under every other collaborator's local branch.
›What is a detached HEAD state?
HEAD normally points at a branch, which points at a commit. Checking out a commit hash directly (rather than a branch name) points HEAD at that commit itself — any new commits you make aren't on any branch and become unreachable (and eventually garbage-collected) the moment you check out something else, unless you create a branch from there first.
›What's the difference between git branch -d and git branch -D?
-d deletes a local branch, but refuses if it has commits not merged into its upstream or the current branch — a
safety check. -D is shorthand for --delete --force: deletes unconditionally, discarding any unmerged commits on
that branch with no warning.
›What does git cherry-pick do, and when would you use it?
Applies the changes from a specific commit elsewhere in history onto your current branch as a new commit. Common for pulling a single hotfix from one branch onto another without merging or rebasing the whole branch.
›How do you resolve a merge conflict?
Git marks conflicting sections in the affected files with <<<<<<<, =======, >>>>>>> markers showing both
versions. Edit the file to the correct final content, remove the markers, git add the resolved file, then
git commit (for a merge) or git rebase --continue (for a rebase) to finish.
›What's the difference between git push --force and --force-with-lease?
Both overwrite the remote branch's history. --force does it unconditionally. --force-with-lease first checks
that the remote branch still points where you last saw it — if someone else pushed in the meantime, it refuses
instead of silently discarding their commits.