All 75 Git quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 21 subtopics, so you can revise one part at a time. Choose Try Git quiz above to take a scored run and review the questions you got wrong.
What does git add file.txt move, and from where to where?
A.From the working directory into the staging area (the index)
B.From the working directory straight into the repository, so after git add a new commit exists
C.From the staging area back into the working directory to discard the change
D.From the local machine up to the remote server, effectively half of git push
Answer: A
Git has three areas: working directory (the file you are editing), staging area/index (what will go into the next commit), repository (commit history). git add moves changes from the first area to the second. git commit moves them from the second to the third.
B.fetch downloads the whole repository from scratch, pull only the delta
C.The two are identical, pull is just an abbreviation of fetch
D.fetch only downloads and updates the tracking branches; pull = fetch plus an integration step
Answer: D
fetch only syncs information from the remote, updating origin/main — the code you are working on is untouched. pull does exactly that and then also merges into the current branch, so it can produce conflicts right away. If you want to look before deciding, fetch is safer.
You add .env to .gitignore, but the file was committed earlier. After editing .gitignore, does Git stop tracking it?
A.No — .gitignore only affects files that are not yet tracked
B.Yes, but you must run git gc to clean up first
C.No, and there is no way out other than deleting the repository entirely
D.Yes — Git rescans the whole repository and untracks every file matching the pattern
Answer: A
No. .gitignore only stops untracked files from being staged. A file that was already committed is still tracked. Remove it with git rm --cached .env then commit — that deletes it from the index but keeps the file on disk.
A.It undoes the most recent commit and returns the changes to the working directory
B.It edits the old commit's content directly, keeping the same hash
C.It adds a new commit that overrides the previous one, leaving two commits in history
D.It replaces the most recent commit with a new one containing the old content plus what is currently staged
Answer: D
Amend merges the staged changes into the latest commit and lets you edit the message, producing a NEW commit that replaces the old one. The hash changes. Because the hash changes, it is only safe to use when that commit has not been pushed yet.
A.The "version 2" content — a commit always reads the newest file on disk
B.Both versions, Git stores two variants inside the same commit
C.The "version 1" content — the commit takes its content from the staging area
D.Git errors out and refuses to commit because the file changed after being added
Answer: C
The commit contains "version 1". git add snapshots the file content at the moment you run it. Later edits stay in the working directory and are not committed. git status will then list the file under BOTH staged and not staged.
C.A queue holding the commits not yet pushed to the remote
D.A full copy of the whole project directory as of the moment the branch was created
Answer: A
A branch is a ref, usually named refs/heads/<name>, pointing to a commit. New commits just advance the pointer. Creating/deleting branches is very cheap since it only manipulates a ref, but switching branches can still take time if Git has to update many files in the working directory.
You need to know who changed line 42 of a file and in which commit. Which command?
A.git fetch <file> — it downloads the history of that one file
B.git status <file> — it shows the file's edit history
C.git diff <file> — it lists everyone who ever touched the file
D.git blame <file>
Answer: D
git blame <file> attributes each line to the commit that last modified it, with author and date. To dig deeper: git log -L 42,42:<file> gives the full change history of that single line.
main has had no new commits since you branched feature. What does git merge feature from main produce?
A.It always creates a merge commit with two parents
B.A fast-forward: Git moves the main pointer up to feature's last commit
C.It errors out because the branches have no difference to merge
D.It automatically deletes the feature branch after merging
Answer: B
Fast-forward — the main pointer just moves forward to the last commit of feature. No merge commit, linear history. To always have a merge commit that clearly marks the boundary of a feature, use git merge --no-ff feature.
You edited a file by mistake and want it back to the last committed version. Which command?
A.git restore <file> — discard the unstaged changes to that one file
B.git revert <file> — undo the changes to a file
C.git reset --hard — the only way to discard changes
D.git clean <file> — clean the change back to a pristine state
Answer: A
git restore <file> returns the file to the staged version (or the latest commit if nothing was staged). If you already ran git add, run git restore --staged <file> to reset the index to HEAD, then git restore <file> to discard working directory changes; or use git restore --source=HEAD --staged --worktree <file>. Note: discarded changes are gone for good — Git never stored them.
A.Tags are created automatically on every merge into main
B.A tag stores the entire source at that moment, a branch only stores a reference
C.A tag is a FIXED pointer to a commit; a branch is a MOVING pointer
D.Tags exist only on the remote, not locally
Answer: C
A tag is pinned to a fixed commit — used to mark releases. A branch moves with new commits. One thing often forgotten: git push does NOT push tags; you need git push --tags or git push origin <tag-name>.
The current branch — it is a reference that points to another reference. In detached state it points directly at a commit. New commits are always attached wherever it currently points.
A.The full content of every file as of that commit
B.That commit's information along with the changes it introduced
C.The list of branches containing that commit
D.The list of every commit from that one to the present
Answer: B
It shows the commit's metadata — author, time, message — along with the changes it introduced. It accepts branch names, tag names, and relative revisions, not just hashes.
A.A complete list of the files modified in the commit
B.The name of the person who requested the change
C.How long the change took to complete
D.Why the change was made, since the "what" is already in the diff
Answer: D
Why the change was made. What changed is visible in the diff. What cannot be inferred from the code is the motivation — the problem being solved, the alternatives considered, and why this approach was chosen.
A.The list of the most recent commits on the branch
B.Staged files, modified but unstaged files, and untracked files
C.The list of branches and which one you are on
D.The line-by-line differences within each file
Answer: B
It reports the current branch, files staged, files modified but not staged, and untracked files. This is the command to run before every commit to know exactly what is about to be recorded.
B.The account used to authenticate with the server
C.The name of the main branch on the server
D.A mandatory keyword of the push command
Answer: A
It is a short name for a remote repository address — just a label standing in for the full path. The name is user-chosen; clone defaults it to origin, but it can be changed and you can add as many remotes as you like.
A.One works locally while the other requires a network
B.One is for small projects and the other for large ones
C.One creates a main branch and the other does not
D.One creates an empty repository, the other downloads a copy
Answer: D
Init creates an empty repository in the current directory, with no commits and no remote. Clone downloads the full history of an existing repository and automatically configures a remote pointing back to the source.
You committed but did not push. Can a teammate see the change?
A.Only once you have opened a pull request
B.Yes, because commits are synchronized automatically
C.Yes, if both people are working on the same branch
D.No — the commit lives only on your machine
Answer: D
No. Git is distributed: each machine holds its own copy of the history, and a commit is only written to the local copy. Only after pushing does the commit reach the server and become available for others to fetch.
What is git log --oneline --graph --all useful for?
A.Finding commits by author name
B.Comparing two branches against each other
C.Viewing the content of each commit's changes
D.Seeing the branch structure and where branches split and merged
Answer: D
It draws the branch structure as a graph, one short line per commit, and shows every branch rather than only the current one. It is the fastest way to see where a branch forked from and where it has been merged back in.
A.The operating system's command cannot delete a tracked file
B.The Git command deletes the file and stages the deletion too
C.The Git command removes the file from the entire history
D.The two commands produce exactly the same result
Answer: B
Both delete the file from disk, but the Git command also stages the deletion. Deleting with an OS command leaves the deletion only in the working directory; an extra step is needed before it can be committed.
A.The merged branch has more commits than the target branch
B.The two branches diverged too long ago
C.Two branches modified any file in common
D.Two branches modified the same region of a file
Answer: D
When two branches modify the same region of a file in two different ways. If each side edits a different region, Git can merge automatically; only when the regions overlap does it have no basis to choose and hands it back to the user.
A.--soft keeps the changes staged; --mixed keeps them in the working directory; --hard discards them
B.--soft goes back one commit, --mixed two, --hard the entire branch
C.--hard is the safest because it asks for confirmation before deleting
D.All three are identical, differing only in the message printed
Answer: A
All three move the branch pointer back; they differ in how many areas they affect. --soft: commit only (changes stay staged). --mixed: commit + staging (changes stay in the working directory). --hard: all three — uncommitted changes are lost.
A bad commit has been pushed to the shared main branch. How should it be undone?
A.git revert <hash> — create a NEW commit that undoes the bad commit's changes
B.git reset --hard <previous hash> followed by git push --force
C.Delete the main branch on the remote and push it again from your local machine
D.git commit --amend to fix the bad commit and then push normally
Answer: A
git revert <hash>. It creates a new commit with the inverse of the bad commit, keeping the entire history intact. Others just git pull as usual. reset + force push on a shared branch is what to avoid: it makes history diverge for everyone who has already pulled.
What is the core difference between git rebase main (on feature) and git merge main?
A.Rebase replays each of feature's commits on top of main's latest commit
B.Rebase is faster than merge because it does not download anything from the remote
C.Rebase can only be used while the branches have not diverged
D.Rebase resolves conflicts automatically while merge makes you handle them manually
Answer: A
Rebase lifts the feature commits and replays them on top of main, creating new commits with new hashes → flat history, no merge commit. Merge keeps the original commits and adds a merge commit → history keeps the exact branching trace but has more forks.
Which statements about rebase are correct? (select all that apply)
A.git rebase -i HEAD~3 lets you squash, edit messages, reorder or drop commits among the last 3
B.Rebase squashes all of a branch's commits into exactly one
C.If a conflict arises mid-rebase, resolve it, git add, then git rebase --continue
D.Do not rebase commits already pushed to a shared branch
Answer: A, C, D
Rebase replays commits so hashes change — so never rebase something others are using. Interactive rebase (-i) is the tool for cleaning up history before opening a pull request. On a conflict, git add then --continue, or --abort to go back to the original state.
You are mid-edit and must switch branches urgently to fix a bug. What does git stash do for you?
A.It creates a hidden commit on the current branch that git log does not show
B.It pushes the uncommitted changes to the remote as a backup
C.It tucks the uncommitted changes into a temporary shelf, leaving the working directory clean
D.It locks the branch so nobody else can push while you are working
Answer: C
git stash puts uncommitted changes into a temporary stack and cleans the working directory. git stash pop takes them out and removes them from the stack; git stash apply takes them out but keeps them. By default stash does NOT include untracked files — you need -u.
A bug-fix commit sits on develop and must go to release alone, without the other commits. What do you use?
A.git merge <hash> — merge works for individual commits too
B.git stash on one branch and pop on the other
C.git checkout <hash> -- . then commit — the standard way to take one commit
D.git cherry-pick <hash> — apply just that commit's changes onto the current branch
Answer: D
git cherry-pick <hash>. It computes the diff that commit introduced and applies it on the current branch as a new commit — same content, different hash. This is the standard tool for backporting a patch to a release branch.
A.Edit the file to the content you want, git add to mark it resolved, then git commit
B.Just edit the file then git commit, no git add needed since Git notices the markers are gone
C.Running git merge --continue is enough, without touching the file
D.Delete the file and check it out again from main
Answer: A
Three steps: fix the file the way you want and remove all <<<<<<<=======>>>>>>> markers; git add <file> to tell Git it's done; git commit to create the merge commit. To cancel midway, git merge --abort.
Why prefer git push --force-with-lease over git push --force?
A.--force-with-lease is faster because it pushes only the delta
B.It checks that the remote is still exactly as it was when you last fetched
C.The two flags are identical, --force is just the short name
D.--force-with-lease merges automatically instead of overwriting
Answer: B
--force overwrites unconditionally. --force-with-lease only overwrites if the remote is still exactly as it was at your last fetch — if someone has pushed since, it stops. It's a safety net for when two people work on the same branch.
You create a new branch, run git push, and Git reports fatal: The current branch feature has no upstream branch. Why?
A.Because the branch has no commits yet so there is nothing to push
B.Because you lack write access to the repository
C.The local branch is not yet linked to any branch on the remote
D.Because the branch name contains invalid characters
Answer: C
The new local branch has no counterpart on the remote yet. git push -u origin feature both pushes it and sets up the tracking link; after that, plain git push and git pull know the target. -u is short for --set-upstream.
Which statements about .gitignore are correct? (select all that apply)
A.git check-ignore -v <file> tells you exactly which line in which file is causing a file to be ignored
B.Ignore rules apply only to files that are NOT yet tracked; a committed file stays tracked until git rm --cached
C./dist ignores only the dist directory at the repository root, while dist/ ignores any directory named dist at any level
D.Adding a secret file to .gitignore also removes its content from the commits already in history
Answer: A, B, C
.gitignore only blocks files that aren't tracked yet. The position of the / determines the pattern's scope. git check-ignore -v is the troubleshooting tool when it's unclear which rule applies. And it does nothing to clean up secrets already in history.
A.Only the diffs between successive versions of a file
B.blob (file content), tree (directory), commit, and tag
C.A relational database with a table for files and a table for commits
D.Full copies of the working directory for each commit
Answer: B
Four kinds: a blob for file contents, a tree pointing to them, a commit pointing to a root tree, and an annotated tag. Each object is identified by the hash of its own content.
A.The commit's position in the current branch's history
B.Only the content of the files changed in that commit
C.The file tree, parent commit, author, committer, time, and message
D.A random number generated when the commit is created
Answer: C
From the hash of the file tree, the hashes of the parent commits, author and committer information, the timestamp, and the message. Because parent commits are included, amending an old commit changes the hash of every commit after it.
What does deleting a branch in Git actually delete?
A.Only the pointer; the commits remain until garbage collection
B.The files created on that branch, from the working directory
C.Every commit belonging solely to that branch, immediately
D.Both the local branch and its counterpart on the remote
Answer: A
It only deletes the pointer — a file containing a hash. The commits remain in the repository and are recoverable via the reflog, until the cleanup process reclaims objects that nothing references anymore.
How do git diff, git diff --staged and git diff HEAD differ?
A.They produce the same output, differing only in display format
B.They differ in whether new files are shown
C.Working vs staged, staged vs HEAD, working vs HEAD
D.The first compares against the remote, the other two within the local repository
Answer: C
Plain git diff compares the working directory with the staging area. Adding --staged compares the staging area with the current commit. Naming a commit compares the working directory with that commit — that is, all uncommitted changes.
C.The commits that are on feature but not yet on main
D.The commits that are on main but not yet on feature
Answer: C
Commits reachable from the right branch that are not yet in the left branch. This is how you check what your branch actually adds before opening a pull request.
After a whole-codebase reformat commit, git blame points at it on every line. What is the fix?
A.Record that commit's hash in .git-blame-ignore-revs so blame skips it
B.Revert the formatting commit and reformat file by file
C.Use the ignore-whitespace flag when running blame
D.Remove that commit from the history by rewriting it
Answer: A
Write that commit's hash into an ignore list file, then configure Git to read it. Blame then looks through the reformat commit and points at the commit that actually wrote the line.
In git rebase -i, how do the squash and fixup commands differ?
A.squash only works with two adjacent commits
B.fixup keeps the original commit while squash deletes it
C.Both fold into the previous commit; fixup drops the message
D.squash folds upward while fixup folds downward
Answer: C
Both fold a commit into the one directly above it. The difference is that the first opens an editor so you can combine the two messages, while the second discards the folded commit's message entirely — handy for cleaning up trivial fixup commits.
How does merging with -X ours differ from the ours merge strategy?
A.The ours strategy keeps both sides while the -X flag keeps only one
B.The -X flag is for rebase while the strategy is for merge
C.They are entirely equivalent, just written differently
D.The -X flag favors ours on conflicts; ours drops the other branch
Answer: D
The option only decides which side wins on the conflicting lines; non-conflicting changes from both sides are still kept. The strategy of the same name throws away the other branch's content entirely, creating just a merge commit to record it.
What does git cherry-pick -x add over an ordinary cherry-pick?
A.It allows cherry-picking several commits at once
B.It keeps the original hash instead of creating a new one
C.It records the original commit's hash in the new commit's message
D.It automatically deletes the original commit after a successful copy
Answer: C
It records the original commit's hash in the new commit's message. Useful because the copy has a different hash from the original, so without that note you can't trace where it came from later.
A.To fully replace git checkout, which has been removed
B.To restore files from the remote without fetching
C.To allow working on several branches at once
D.To split the two roles that were conflated in git checkout
Answer: D
To separate two roles that were crammed into one old command: switching branches, and restoring file contents. One command doing both made it very easy for newcomers to accidentally overwrite unsaved changes.
What does git clean -fd do and why is it dangerous?
A.It deletes local branches already merged into the main branch
B.It deletes commits that have not been pushed to the remote
C.It discards uncommitted changes to tracked files
D.It deletes untracked files and directories — Git cannot bring them back
Answer: D
It deletes untracked files and directories in the working directory. Dangerous because those files were never in the repo, so Git has no copy to restore — unlike every other undo operation.
B.30 days, and it is synced to the remote along with the commits
C.90 days by default, and it exists only locally
D.Only for the current session
Answer: C
By default ninety days for entries still reachable and thirty days for entries nothing points to. More importantly: it exists only locally — it isn't pushed to the remote and isn't present in other clones.
A.Having several branches open in different directories, sharing one repository
B.Synchronizing two different repositories with the same history
C.Storing several versions of the same file in one directory
D.Splitting a large repository into several smaller ones
Answer: A
It checks out multiple branches into separate directories on disk, all sharing one repository. No need to stash or commit WIP to switch branches, and no disk cost like duplicating the whole repo.
What does git fetch --prune add over a plain fetch?
A.It downloads only the branches tracked locally
B.It deletes local branches already merged into the main branch
C.It deletes remote-tracking branches pointing at branches removed on the remote
D.It repacks the repository to shrink it after downloading
Answer: C
It deletes tracking refs pointing to branches already removed on the remote. Without it, the local branch list accumulates dozens of refs to branches deleted after merge requests from months ago.
The usual levels are system-wide, per-user, and per-repo. The narrowest scope wins — repo config overrides user config, which overrides system config. There is an additional worktree level when the feature is enabled.
A.Declaring per-pattern file rules: line endings, binary, diff, LFS
B.Declaring which files to ignore when committing
C.Declaring each person's access to each directory
D.Declaring repository metadata such as author and licence
Answer: A
It declares pattern-based rules: how to handle line endings, marking files as binary, choosing a custom diff driver, and routing large files to a separate storage mechanism. Unlike local config, this file is committed, so it applies uniformly across the team.
What is the most notable difference between cloning over SSH and over HTTPS?
A.HTTPS does not encrypt data in transit
B.Only SSH supports pushing, HTTPS is read-only
C.The authentication method: an SSH key versus a token stored in a helper
D.A significant data transfer speed difference between the protocols
Answer: C
Authentication. The first protocol uses a public/private key pair. The second uses an access token stored by a credential manager — and code hosting platforms have dropped password authentication entirely.
A.When the repository has many branches to follow in parallel
B.When you need to rebase a long branch onto the main branch
C.CI builds — you only need the latest code, not the history
D.Daily work on a personal machine, to save disk space
Answer: C
For CI machines: you only need the code at the latest revision to build and test, with no history. It skips all history, so it is much faster to download — on a large repo, the difference can be minutes per run.
A.Files are compressed more aggressively before being stored in the repository
B.The repository stores only a pointer; the content lives on a separate server
C.Only the newest commit's file is kept, older versions are deleted
D.Files are split into chunks and scattered across storage
Answer: B
The repo stores only a small pointer file of a few hundred bytes holding the content hash, while the actual content lives on a separate server and is downloaded at checkout. That keeps history from bloating with binary file sizes.
A.That the commit's content has been reviewed and approved
B.That the commit contains no security vulnerabilities
C.That the commit really was created by whoever holds the key
D.That the commit cannot be modified after creation
Answer: C
That the commit really was created by the holder of the key. This matters because the author field in a commit is just free text — anyone can configure someone else's name and email and commit under their identity.
What do Conventional Commits specify, and what benefit do they bring?
A.Branch naming rules by type of work
B.A message format with a machine-readable type prefix
C.The maximum number of commits per pull request
D.The list of people who must review each type of change
Answer: B
A format with a prefix that states the type of change, plus an optional scope and description. The benefit is that it is machine-readable — tooling can generate a changelog and infer the version bump under semantic versioning.
What is the core difference between trunk-based development and Git Flow?
A.It uses no branches; everyone commits straight to the trunk
B.Branches live very briefly and merge into the trunk daily
C.It only suits projects that do not ship versioned releases
D.It requires a separate release branch per feature
Answer: B
Short-lived branches merge straight into the main branch, usually within a day. The other uses long-lived parallel branches for development, features, releases, and hotfixes. Long-lived branches diverge, so merging late causes large conflicts.
Merge commit, squash merge, or rebase merge — which for a pull request?
A.Always rebase because a linear history is always easier to read
B.It depends on the trade-off: keeping the detail, a tidy history, or linear with no lost commits
C.Always squash because a one-line-per-feature history is best
D.Always use a merge commit because it preserves the most information
Answer: B
There is no single right answer. A merge commit keeps full detail and the PR boundary. Squash gives a clean history, one commit per feature. Rebase gives a linear history while still keeping each commit. Most important is that the whole team is consistent.
What rules do protected branches on code hosting platforms typically enable?
A.Limiting how many people may clone the repository
B.Blocking direct pushes and requiring review plus green CI before merging
C.Capping the maximum size of each commit
D.Automatically formatting the code before each merge
Answer: B
Ban direct pushes, require a pull request, require a certain number of approvals, and require automated checks to pass. If you rely only on personal discipline, sooner or later someone will push directly when in a hurry.
Contributing to an open source project through a fork requires which remote setup?
A.No remote at all; the platform syncs the fork with the original automatically
B.A single remote pointing at the original repository
C.Two remotes: origin for your fork and upstream for the original repository
D.One remote for the fork, and re-clone the original when you need updates
Answer: C
Two remotes: one pointing at your fork to push to, and one pointing at the original repo to fetch new changes from. Without the second, your fork drifts out of date and every PR hits conflicts.
Why are small pull requests usually better than large ones?
A.CI runs faster when fewer files change
B.Code-hosting platforms cap the size of a pull request
C.Git merges faster with fewer changed lines
D.Reviewers can read carefully so they catch more problems
Answer: D
Because reviewers actually read them. Code review research shows defect-detection quality drops sharply past a few hundred lines — with changes of thousands of lines, most reviewers just skim and hit approve.
What is the core difference between a submodule and a subtree?
A.A submodule copies the content; a subtree only pins a hash
B.A submodule only pins a hash; a subtree copies the content into the parent repository
C.Submodules only work with public repositories
D.Both copy the content, differing only in command syntax
Answer: B
The first mechanism just pins a hash pointing to another repo; the content isn't in the parent repo. The second copies the content into the parent repo as real commits. So people cloning the repo with the second approach don't have to do any extra step.
How does an annotated tag differ from a lightweight tag?
A.An annotated tag is its own object with an author, message, and the ability to be signed
B.Annotated tags only work on commits while lightweight tags work on any object
C.Annotated tags move automatically when new commits arrive
D.Lightweight tags are pushed automatically while annotated ones must be pushed separately
Answer: A
An annotated tag is a separate object carrying author, date, message, and can be signed. A lightweight tag is just a reference pointing to a commit, carrying no information. For releases you should always use the annotated kind.
What steps does a tag-based release process typically involve?
A.Create a new branch for each release and merge it into the main branch
B.Mark the commit with a version file and commit that file
C.Build on a personal machine and upload the result to a registry by hand
D.Put a semver tag on a tested commit; CI picks up the tag and builds
Answer: D
Tag a commit that has passed tests following semantic versioning, push the tag, and let CI catch that event to build and release. Tags are immutable, so a release can always be traced back to the exact commit that produced it.
A.Put the hooks on a separate branch and merge it when needed
B.Commit the scripts into the repository and point core.hooksPath at that directory
C.Declare the hooks in a committed configuration file in the repository
D.Git syncs hooks automatically when the repository is cloned
Answer: B
Put the scripts in a committed directory, then point the hooks path setting at that directory. The default hooks directory lives inside Git's management directory, so it is never committed and isn't shared automatically.
A growing repository makes Git commands slow. How to improve it?
A.Switch to cloning over SSH instead of HTTPS
B.Enable git maintenance, fsmonitor, and the commit-graph
C.Turn off compression so Git does not have to decompress on read
D.Delete old branches to reduce the number of references
Answer: B
Enable scheduled maintenance tasks, enable the file system monitor, and enable the commit graph. These three target three different bottlenecks: object packing, scanning the working directory, and walking history.
How does git pull --rebase differ in outcome from a default pull?
A.It creates no merge commit, so the history stays linear
B.It fetches faster because it skips the merge step
C.It only fetches without applying anything to the branch
D.It resolves any conflicts that arise automatically
Answer: A
It does not create a merge commit: local commits are replayed on top of the fetched commits, so history becomes a straight line. The default approach merges the two branches and produces a merge commit each time.
How does git merge --no-ff feature differ from a default merge?
A.It always creates a merge commit, even when one is unnecessary
B.It squashes all the branch's commits into one
C.It only merges when there is no conflict
D.It deletes the source branch once the merge is done
Answer: A
It always creates a merge commit, even when the target branch has no new commits and Git could just fast-forward the pointer. This keeps a trace in history that a group of commits belongs to the same feature.
How does git stash pop differ from git stash apply?
A.One applies to the current branch, the other to the original one
B.One can handle conflicts and the other cannot
C.One removes the stash entry after applying, the other keeps it
D.One preserves the staging area and the other does not
Answer: C
Both apply the stashed content to the current branch, but one command removes that entry from the stash list after applying while the other keeps it. Keeping it is safer when you're not sure the apply targets the right branch.
What are git commit --fixup <hash> and autosquash rebase for?
A.Folding a fix into the right earlier commit automatically
B.Squashing all the branch's commits into one
C.Amending the most recent commit
D.Undoing a commit already pushed to a shared server
Answer: A
It creates a commit pre-marked as a fix for an older commit. When you run an interactive rebase in autosquash mode, Git moves that commit into the right position and folds it in — no need to find and reorder the list by hand.
You staged a file by mistake. How do you unstage it?
A.git clean -f — removes files from the directory
B.git rm --cached <file> — stops tracking the file
C.git restore --staged <file> — the content is preserved
D.git checkout <file> — returns the file to the committed version
Answer: C
Use the restore command with the option that only affects the staging area. It removes the file from the staging area but leaves the changes in the working directory, so no work is lost.
A push is rejected — non-fast-forward. What causes this?
A.The branch on the server is protected
B.Your commit is too large
C.You lack write permission on that branch
D.The server has commits your machine does not
Answer: D
The branch on the server has commits your machine doesn't have — usually because someone else pushed while you were working. Force-pushing would lose those commits, so Git rejects it and requires you to fetch and integrate first.
A mixed Windows and macOS team sees whole files marked changed. Why?
A.The two systems use different line-ending characters
B.File permissions differ between the two systems
C.The file's character encoding changed when it was saved
D.The file's modification time is off by a timezone
Answer: A
Different line endings: Windows uses two characters at the end of each line, while macOS and Linux use one. When the file is opened and saved on the other system, every line is treated as changed even though the content is the same.
A tag deleted locally still exists on the server. Why?
A.The tag is protected so it cannot be deleted
B.A local deletion does not propagate to the server
C.A tag can only be deleted after deleting the branch containing it
D.The tag is recreated automatically on the next fetch
Answer: B
Because tags don't sync automatically: deleting locally only affects the local copy. You have to explicitly push the deletion to the server. The same applies to creation — a new tag isn't pushed to the server when you push commits.
Mid-conflict, you want to return to the pre-merge state. What do you use?
A.git revert HEAD — undo the most recent commit
B.git reset --hard HEAD — discard every change
C.git checkout . — return the files to their old versions
D.git merge --abort — return to the pre-merge state
Answer: D
Use the command that aborts the merge. It restores both the branch and the working directory to exactly the state before the merge started, including any pre-existing uncommitted changes.
You need every commit by one person over the past month. How?
A.Dump the whole log and filter it with a text search tool
B.Look at it in the hosting platform's web interface
C.Filter the log by author and by date range
D.Use the command that traces the author of each line
Answer: C
Use the log command with an author filter and a start date. Filters combine with each other, and adding a compact format gives the list you need right away.
What does git describe --tags return and what is it for?
A.The tag created most recently in time
B.A detailed description of the nearest tag
C.A list of every tag in the repository
D.The nearest tag plus how many commits have passed since
Answer: D
It returns the most recent tag in history along with the number of commits since that tag and an abbreviated hash. This string uniquely identifies a commit and is often used as a build version number.
You committed with a personal email instead of the work one. How to fix?
A.Add that email to your account on the hosting platform
B.Create a new commit noting the correct information
C.Change the configuration and then rewrite the old commits
D.Just change the configuration and Git will update them
Answer: C
Author info lives in the commit itself, so changing config only affects later commits. To fix an old commit you must rewrite history — acceptable if it hasn't been pushed or the branch is only yours.
A conflict occurs in an image file. How does Git handle it?
A.Git keeps both versions under different names
B.Git inserts conflict markers inside the file
C.Git automatically picks the larger version
D.It cannot be merged; you must choose one version
Answer: D
Git merges by text lines, so it cannot merge binary files. It reports a conflict and the user must keep one of the two versions — the current branch's or the incoming branch's.
C.Only the first commit of each branch ever created
D.Only the commits that are not merge commits
Answer: B
It only lists commits on the main line: each merge commit counts as a single entry, and all commits inside the merged branch are skipped. The result is a list of features that landed on the branch, not every individual change.
