I85PREP
⌘ K
GitLab Git Associate study materials
GitLab Git Associate study resources

GitLab Git Associate practice questions

One question at a time. Build your GitLab Git Associate understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Git fundamentals (repositories, commits, branching, merging)

In Git, what does a commit primarily record?

  1. A byte-level diff of only the files that changed since the previous commit
  2. A list of remote branches that currently contain the commit
  3. A pointer to the working directory state including untracked files
  4. A snapshot of the tracked project tree plus metadata such as author, message, and parent commit references Correct answer.

Explanation

A Git commit is a snapshot object: it references a tree object capturing the full tracked project state, plus metadata like author, committer, timestamp, message, and zero or more parent commits. Diffs are computed later by comparing snapshots, not stored inside the commit.

Question 2Git fundamentals (repositories, commits, branching, merging)

A developer runs `git switch -c feature/login` while on `main`. What is the resulting state?

  1. A new empty branch is created with no commits until the first commit is made
  2. A new branch `feature/login` is created and checked out at the same commit as `main` Correct answer.
  3. `main` is renamed to `feature/login` and the old name is deleted
  4. `feature/login` is created on the remote and fetched locally

Explanation

`git switch -c` creates a new local branch pointing at the current HEAD commit and immediately checks it out, leaving the working tree unchanged. The original branch remains untouched and both refs initially point to the same commit.

Question 3Git fundamentals (repositories, commits, branching, merging)

Which command shows the commit history of the current branch as a graph with all branches displayed?

  1. git diff --stat HEAD
  2. git show-ref --heads
  3. git log --graph --oneline --all Correct answer.
  4. git status --branch

Explanation

`git log` walks commit history, and `--graph` renders an ASCII topology while `--all` includes every ref rather than just HEAD. `--oneline` compacts each entry to a single line for readability.

Question 4Git fundamentals (repositories, commits, branching, merging)

What is the role of the staging area (index) in the Git workflow?

  1. It holds the proposed content for the next commit, letting you select which changes to include Correct answer.
  2. It automatically stores every file modification so nothing can be lost
  3. It records merge conflict resolutions permanently before any commit is made
  4. It is a remote cache that mirrors the last fetched state of the default branch

Explanation

The index is a prepared tree that the next commit will record. Staging lets you craft a commit from a subset of working tree changes, which is why `git add` exists separately from `git commit`.

Question 5Git fundamentals (repositories, commits, branching, merging)

Which statement correctly describes a fast-forward merge?

  1. Git rewrites the merged branch's commits onto the target branch before advancing
  2. The merged branch is deleted automatically as part of the merge
  3. The target branch pointer simply advances to the merged branch's tip because no divergent commits exist Correct answer.
  4. A merge commit is always created with two parents to preserve branch topology

Explanation

When the target branch is an ancestor of the branch being merged, Git can move the pointer forward without creating a merge commit. This is the default behavior unless `--no-ff` is specified.

Question 6Git fundamentals (repositories, commits, branching, merging)

What does `git clone` set up in addition to copying the repository objects?

  1. A remote named `origin` pointing at the source URL and a local tracking branch for the default branch Correct answer.
  2. A scheduled fetch that keeps the clone synchronized automatically
  3. A mirror of every remote branch as local writable branches
  4. A bare repository with no working tree in the target directory

Explanation

Cloning copies objects and refs, then configures `origin` as the default remote and creates a local branch tracking the remote default branch. Remote branches appear as read-only remote-tracking refs, not local branches.

Question 7Git fundamentals (repositories, commits, branching, merging)

Which command appends a new commit to the current branch that reverts the changes introduced by an earlier commit, without rewriting history?

  1. git revert <commit> Correct answer.
  2. git checkout <commit>
  3. git reset --hard <commit>
  4. git rebase --onto <commit>

Explanation

`git revert` creates a new commit whose tree undoes the target commit's changes, preserving the existing history. This makes it safe for commits that have already been shared with others.

Question 8Git fundamentals (repositories, commits, branching, merging)

What is the practical difference between `git fetch` and `git pull`?

  1. `fetch` integrates changes into the current branch; `pull` only downloads objects
  2. `fetch` works only with bare repositories; `pull` works only with non-bare repositories
  3. `fetch` rewrites local commits; `pull` never modifies local history
  4. `fetch` downloads objects and updates remote-tracking refs; `pull` additionally integrates them into the current branch Correct answer.

Explanation

`git pull` is essentially `git fetch` followed by a merge or rebase, depending on configuration. Using `fetch` alone lets you inspect incoming changes before deciding how to integrate them.

Question 9Git fundamentals (repositories, commits, branching, merging)

During a merge, Git reports conflicts in `app/config.yml`. Which file content does the working tree contain at that moment?

  1. An empty file until the conflict is resolved
  2. The version from the branch being merged in, without markers
  3. The version from the branch that was checked out before the merge
  4. The file with conflict markers delimiting the two competing versions Correct answer.

Explanation

For content conflicts Git writes both sides into the file separated by `<<<<<<<`, `=======`, and `>>>>>>>` markers. The developer edits the file to the desired result, stages it, and completes the merge.

Question 10Git fundamentals (repositories, commits, branching, merging)

A developer wants to combine the last three commits on a feature branch into one before pushing. Which command starts that process?

  1. git merge --squash HEAD~3
  2. git rebase -i HEAD~3 Correct answer.
  3. git cherry-pick HEAD~3
  4. git reset --soft HEAD~3

Explanation

An interactive rebase over the last three commits lets you mark them as `squash` or `fixup` to combine them into a single commit. This rewrites the branch history, which is acceptable before the commits are shared.

Question 11Git fundamentals (repositories, commits, branching, merging)

What does `git branch -d feature` refuse to do in its default form?

  1. Delete a branch whose commits are not yet merged into the current branch or its upstream Correct answer.
  2. Delete a branch that is currently checked out in another worktree
  3. Delete a branch that has an upstream configured
  4. Delete a branch that exists on the remote

Explanation

`git branch -d` performs a safety check and declines to delete branches containing commits not reachable from the current HEAD or upstream. `-D` forces deletion when you intentionally want to discard those commits.

Question 12Git fundamentals (repositories, commits, branching, merging)

Which command stages modifications and deletions of already-tracked files but does not stage newly created untracked files?

  1. git add -N
  2. git add -u Correct answer.
  3. git add .
  4. git add -A

Explanation

`git add -u` updates the index only for paths already tracked, capturing modifications and deletions. New untracked files are left alone, unlike `-A` or `.` in modern Git.

Question 13Git fundamentals (repositories, commits, branching, merging)

A commit was made on `main` by mistake and should instead live on a new branch, with `main` restored to its previous state. Which sequence accomplishes this while keeping the commit?

  1. git reset --hard HEAD~1 && git branch fix
  2. git branch fix && git reset --hard HEAD~1 Correct answer.
  3. git revert HEAD && git branch fix
  4. git checkout HEAD~1 && git branch fix

Explanation

Creating the branch first captures the mistaken commit under a new ref, so the subsequent hard reset of `main` cannot orphan it. Reversing the order would leave the commit unreachable except through reflog.

Question 14Git fundamentals (repositories, commits, branching, merging)

What does `git merge --no-ff feature` guarantee compared with the default merge?

  1. A merge commit with two parents is created even when a fast-forward would be possible Correct answer.
  2. The feature branch's commits are replayed onto the target branch
  3. Conflicts are resolved automatically using the last common ancestor
  4. The feature branch is rebased and then deleted

Explanation

`--no-ff` forces a true merge commit so the branch topology remains visible in history. This is common for feature branches where preserving the merge point is valuable for later analysis.

Question 15Git fundamentals (repositories, commits, branching, merging)

A developer wants to see which commits exist on `feature` but not on `main`. Which command answers this directly?

  1. git log main..feature Correct answer.
  2. git diff main feature
  3. git branch --merged main
  4. git log feature..main

Explanation

The `A..B` range syntax lists commits reachable from B but not from A, so `main..feature` shows exactly the feature-only commits. It is a commit set operation, not a content diff.

Question 16Git fundamentals (repositories, commits, branching, merging)

What does `git commit --amend` do to the most recent commit?

  1. Replaces it with a new commit object using the current index and optional new message Correct answer.
  2. Moves the previous commit onto the branch's upstream tip
  3. Creates a follow-up commit that reverts the previous message only
  4. Adds a second parent commit referencing the previous version

Explanation

Amend builds a new commit from the current index and the original commit's parent, then moves the branch pointer to it. The original commit becomes unreachable and its hash changes, so amending shared commits requires coordination.

Question 17Git fundamentals (repositories, commits, branching, merging)

Which statement best describes a detached HEAD state?

  1. HEAD points to a remote-tracking ref instead of a local branch
  2. HEAD points directly to a commit rather than to a branch, so new commits are not attached to any branch Correct answer.
  3. HEAD is missing because the repository is corrupted
  4. HEAD points to a branch that has no upstream configured

Explanation

Detached HEAD occurs when you check out a commit, tag, or remote ref directly. Commits made there are reachable only through HEAD and the reflog until you create a branch to keep them.

Question 18Git fundamentals (repositories, commits, branching, merging)

A file was renamed and its content edited in the working tree. What does `git status` typically report before staging?

  1. A deletion of the old path and an untracked new path, unless rename detection applies after staging Correct answer.
  2. A merge conflict on the old path
  3. Nothing, because Git tracks renames automatically in the working tree
  4. A single rename entry with the edits already staged

Explanation

Git does not track renames as first-class operations; they are inferred by similarity when comparing trees. Before staging, status usually shows the old path deleted and the new path untracked; after staging both, it may display a rename.

Question 19Git fundamentals (repositories, commits, branching, merging)

What is the effect of `git reset --soft HEAD~1`?

  1. The index is reset to HEAD while the working tree keeps modifications
  2. The branch pointer moves back one commit while the index and working tree keep the changes staged Correct answer.
  3. The branch pointer moves back one commit and all changes are discarded from index and working tree
  4. The commit is removed from history and the working tree is cleaned of untracked files

Explanation

`--soft` moves only the branch ref, leaving the index and working tree untouched, so the undone commit's changes remain staged. This is useful for recombining commits before recommitting.

Question 20Git fundamentals (repositories, commits, branching, merging)

Which command lists local branches along with the upstream branch each one tracks?

  1. git branch -vv Correct answer.
  2. git log --decorate
  3. git branch -a
  4. git remote show

Explanation

`git branch -vv` prints each local branch with its commit, upstream ref, and ahead/behind counts. This makes it the standard way to audit tracking configuration locally.

Question 21Git fundamentals (repositories, commits, branching, merging)

A merge conflict occurs in `README.md`. After editing the file to the desired content, which command completes the merge?

  1. git merge --abort
  2. git add README.md && git commit Correct answer.
  3. git commit --amend
  4. git checkout --theirs README.md

Explanation

Staging the resolved file marks the conflict as resolved, and committing finalizes the merge with the recorded parents. During a merge, `git commit` uses the prepared merge message.

Question 22Git fundamentals (repositories, commits, branching, merging)

What does `git cherry-pick abc123` do?

  1. Applies the change introduced by commit `abc123` as a new commit on the current branch Correct answer.
  2. Reverts commit `abc123` on the branch where it originally lives
  3. Moves branch `abc123` to the current HEAD
  4. Merges the entire branch containing `abc123` into the current branch

Explanation

Cherry-pick computes the patch of the target commit relative to its parent and replays it onto HEAD as a new commit with a different hash. It is useful for selectively porting a fix between branches.

Question 23Git fundamentals (repositories, commits, branching, merging)

Two developers push to the same branch; the second push is rejected as non-fast-forward. What is the safest way to integrate the remote work before pushing again?

  1. git push --force origin <branch>
  2. git fetch origin && git rebase origin/<branch>, then push Correct answer.
  3. git commit --amend && git push
  4. git reset --hard origin/<branch>

Explanation

Fetching first brings the new remote commits locally, and rebasing replays your local commits on top of them so the push becomes a fast-forward. This preserves the remote commits and avoids overwriting others' work.

Question 24Git fundamentals (repositories, commits, branching, merging)

A commit was accidentally dropped by a hard reset. Which approach is most reliable for recovering it?

  1. Run `git log --all --source` to find the commit in the branch history
  2. Run `git fsck --lost-found` and merge the dangling commit into the default branch
  3. Check `git stash list` for the commit and apply the most recent stash
  4. Inspect `git reflog` to find the lost commit's hash, then create a branch or reset to it Correct answer.

Explanation

The reflog records where HEAD and branch refs have pointed, including commits abandoned by reset. Once you identify the hash, you can attach a branch to it and restore the work.

Question 25Git fundamentals (repositories, commits, branching, merging)

A repository uses a merge commit history. A developer rebases a long-lived shared branch and force-pushes. What is the main risk to collaborators?

  1. Git automatically converts the rebase into a merge on the remote to protect history
  2. Their local branches diverge from the rewritten remote, causing duplicate commits and confusing merges when they pull Correct answer.
  3. The rebase changes only commit messages, so collaborators are unaffected
  4. The remote repository loses all objects that were not fetched by the developer

Explanation

Rebasing rewrites commit hashes, so anyone who already has the old commits will see divergent histories. Their subsequent pull may reintroduce old commits or produce duplicate changes unless they reset onto the rewritten branch.

Question 26Git fundamentals (repositories, commits, branching, merging)

In a Git repository, what does a commit object primarily record?

  1. A snapshot of the tracked tree plus parent commit references, author, and message Correct answer.
  2. A pointer to the remote branch the commit was pushed to
  3. A list of unstaged working tree changes at commit time
  4. A delta patch against the previous commit's file contents

Explanation

A commit stores a reference to a tree object representing the project snapshot, zero or more parent commits, and metadata such as author, committer, and message. Git does not store per-file deltas in the commit itself; deltas are computed later during packing. Unstaged changes and remote tracking information are not part of the commit object.

Question 27Git fundamentals (repositories, commits, branching, merging)

A developer runs `git switch -c hotfix` while on `main`. What is the resulting state?

  1. `hotfix` is created but the working tree remains on `main`
  2. A new branch `hotfix` is created and checked out at the same commit as `main` Correct answer.
  3. `main` is renamed to `hotfix` and the old name is deleted
  4. A new empty branch is created with no commits until the first commit is made

Explanation

`git switch -c` creates the branch at the current HEAD commit and immediately checks it out, so both branches point at the same commit until new commits diverge them. The original branch is untouched. Branches in Git are pointers, so the new branch is never empty in the sense of lacking history.

Question 28Git fundamentals (repositories, commits, branching, merging)

Which command shows the commit history of the current branch including a graph of merges across all local branches?

  1. git reflog expire
  2. git diff --stat
  3. git log --graph --oneline --all Correct answer.
  4. git status --short

Explanation

`git log` accepts formatting and traversal options; `--graph` draws the commit topology, `--oneline` compresses each entry, and `--all` includes every ref rather than just HEAD. The other commands report working tree state, diff summaries, or maintain reflog entries, none of which display branch topology.

Question 29Git fundamentals (repositories, commits, branching, merging)

What is the index (also called the staging area) in a Git repository?

  1. A log of every command executed in the repository
  2. A directory of remote-tracking branches cached from the server
  3. A binary file that records the proposed content of the next commit Correct answer.
  4. A backup copy of the working tree taken before each checkout

Explanation

The index, typically `.git/index`, holds the tree that `git commit` will record, which is why staging is described as building the next snapshot. It is distinct from remote-tracking refs, from the reflog of HEAD movements, and from any working tree backup. Understanding this separation explains why unstaged edits are excluded from a commit.

Question 30Git fundamentals (repositories, commits, branching, merging)

Which command creates a lightweight tag named `v1.0` on the current commit?

  1. git commit -m v1.0
  2. git tag v1.0 Correct answer.
  3. git tag -a v1.0
  4. git branch v1.0

Explanation

`git tag v1.0` without flags creates a lightweight tag, which is simply a ref pointing at a commit. The `-a` flag would instead create an annotated tag object with its own message and tagger metadata. Creating a branch or a commit produces entirely different objects.

Question 31Git fundamentals (repositories, commits, branching, merging)

A developer wants to discard unstaged modifications to `notes.txt` and restore it to the last committed version. Which command does this?

  1. git restore notes.txt Correct answer.
  2. git restore --staged notes.txt
  3. git add notes.txt
  4. git rm notes.txt

Explanation

`git restore <path>` copies content from the index back into the working tree, discarding unstaged edits. The `--staged` variant instead resets the index entry, and `git add` moves changes in the opposite direction. `git rm` removes the file from tracking and disk.

Question 32Git fundamentals (repositories, commits, branching, merging)

What does `git diff` with no arguments compare by default?

  1. The working tree against the index Correct answer.
  2. The current branch against its upstream
  3. The index against the last commit
  4. The last two commits on the current branch

Explanation

Plain `git diff` shows unstaged changes, meaning differences between the working tree and the index. To compare the index with HEAD you use `git diff --staged`, and to compare branches you must name them. This default is why newly staged files vanish from plain `git diff` output.

Question 33Git fundamentals (repositories, commits, branching, merging)

Which file in a repository defines patterns for paths that Git should intentionally leave untracked?

  1. .gitconfig
  2. .gitmodules
  3. .gitattributes
  4. .gitignore Correct answer.

Explanation

`.gitignore` lists path patterns that Git excludes from untracked status and from wildcard adds. `.gitattributes` controls attributes such as line-ending normalization and diff drivers, while `.gitmodules` records submodule URLs. Repository-local configuration lives in `.git/config`, not `.gitconfig` at the root.

Question 34Git fundamentals (repositories, commits, branching, merging)

A developer has staged `report.md` and then edits it again without staging. What does `git commit` record for that file?

  1. Nothing, because the file has both staged and unstaged changes
  2. The working tree version, including the later unstaged edits
  3. A merge of the staged and unstaged versions
  4. The staged version, excluding the later unstaged edits Correct answer.

Explanation

A commit records exactly the tree held in the index, so edits made after staging are not included until they are staged again. The file still appears as modified in `git status` after the commit. Git never silently merges staged and unstaged content into one commit.

Question 35Git fundamentals (repositories, commits, branching, merging)

A developer wants to move the branch pointer and index back one commit while keeping all changes in the working tree. Which command does this?

  1. git reset --hard HEAD~1
  2. git reset --mixed HEAD~1 Correct answer.
  3. git revert HEAD~1
  4. git reset --soft HEAD~1

Explanation

`--mixed` is the default reset mode: it moves HEAD and resets the index to the target commit but leaves the working tree untouched, so the differences appear as unstaged changes. `--soft` keeps the index as well, while `--hard` overwrites the working tree. `git revert` creates a new commit instead of moving the branch.

Question 36Git fundamentals (repositories, commits, branching, merging)

A repository contains a merge commit `M` with parents `A` and `B`. What does `git log --first-parent` show along that line?

  1. Only the commit `M` itself
  2. The commits of both parents interleaved by date
  3. Only commits that have exactly one parent
  4. The history following parent `A` at each merge, skipping commits reachable only through `B` Correct answer.

Explanation

`--first-parent` follows the first parent recorded on each merge commit, which is the branch that was merged into. This yields the mainline history and hides commits that entered only through side branches. It does not filter by parent count or sort by date.

Question 37Git fundamentals (repositories, commits, branching, merging)

What does `git merge-base feature main` return?

  1. The commit that will be created by merging the two branches
  2. The newest commit reachable from either branch
  3. The commit where `feature` was created, always
  4. The best common ancestor commit of the two branches Correct answer.

Explanation

`git merge-base` computes the best common ancestor, the commit from which the two histories diverged, which is exactly what a three-way merge uses. It is not necessarily the creation point of the branch if the branch was later rebased or if commits were shared. It never returns a future merge commit.

Question 38Git fundamentals (repositories, commits, branching, merging)

A developer wants to apply only commit `abc123` from another branch onto the current branch. Which command does this?

  1. git cherry-pick abc123 Correct answer.
  2. git merge abc123
  3. git rebase abc123
  4. git checkout abc123

Explanation

`git cherry-pick` replays the changes introduced by the named commit as a new commit on the current branch. `git merge` and `git rebase` take branch names and integrate whole histories, and `git checkout` only moves HEAD or restores files without creating a commit.

Question 39Git fundamentals (repositories, commits, branching, merging)

Which command deletes the remote-tracking reference `origin/old-feature` without affecting the branch on the server?

  1. git branch -d old-feature
  2. git push origin --delete old-feature
  3. git branch -dr origin/old-feature Correct answer.
  4. git remote remove origin

Explanation

`git branch -d -r` (or `-dr`) removes a remote-tracking ref locally; the next fetch recreates it if the branch still exists on the remote. `git push --delete` removes the branch on the server, and `git branch -d` targets a local branch. Removing the remote drops all its tracking refs and configuration.

Question 40Git fundamentals (repositories, commits, branching, merging)

What does `git fetch --prune` do that a plain `git fetch` does not?

  1. It deletes local branches that have been merged into the upstream
  2. It deletes local remote-tracking refs whose branches no longer exist on the remote Correct answer.
  3. It fetches only the tags and skips branch refs
  4. It discards uncommitted changes before fetching

Explanation

Pruning removes stale remote-tracking refs such as `origin/topic` after the branch is deleted on the server. It never touches local branches, working tree content, or the set of refspecs fetched. This keeps `git branch -r` output aligned with the server.

Question 41Git fundamentals (repositories, commits, branching, merging)

A team uses Git Flow-style topic branches. A developer runs `git rebase main` on their local `feature` branch and then `git push`. Why might the push be rejected?

  1. The rebase converted the branch into a tag
  2. The rebase rewrote the feature commits, so the remote branch is no longer an ancestor of the local one Correct answer.
  3. The rebase deleted the remote-tracking branch
  4. The rebase changed the branch name on the remote

Explanation

Rebasing creates new commits with new hashes, so the local branch no longer contains the commits currently on the remote branch, and a fast-forward push is impossible. Git rejects the push until the developer reconciles histories, typically with `--force-with-lease` on a personal branch. Rebasing does not alter refs on the server by itself.

Question 42Git fundamentals (repositories, commits, branching, merging)

What does `git log --oneline --decorate` add to the default output?

  1. Ref names such as `HEAD -> main` and tags shown next to the commits they point to Correct answer.
  2. A unified diff for each commit
  3. The list of files changed in each commit
  4. The author's email for every commit

Explanation

`--decorate` annotates commits with the refs that point at them, which makes it easy to see where branches, tags, and HEAD sit. It does not change the diff or file listing, and author email is controlled separately by format options such as `--format`.

Question 43Git fundamentals (repositories, commits, branching, merging)

A developer wants to see the commit that introduced the line `timeout: 30` in `config.yml`. Which command is designed for this?

  1. git blame config.yml
  2. git log -S 'timeout: 30' -- config.yml Correct answer.
  3. git show config.yml
  4. git diff config.yml

Explanation

The pickaxe option `-S` searches history for commits that changed the number of occurrences of a string, which pinpoints the introducing commit. `git blame` shows the last commit per line rather than the search result, and `git diff` or `git show` inspect content without searching history.

Question 44Git fundamentals (repositories, commits, branching, merging)

A merge conflict occurs during `git merge topic`. After resolving the files and staging them, what does `git commit` do with no arguments?

  1. It fails because a merge message must be supplied explicitly
  2. It aborts the merge and restores the pre-merge state
  3. It concludes the merge using the prepared merge message and records both parents Correct answer.
  4. It creates a commit with only the current branch as parent

Explanation

Once all conflicts are resolved and staged, `git commit` finalizes the in-progress merge, recording a commit with two parents and the default merge message. Aborting requires `git merge --abort`, and the two-parent structure is intrinsic to a merge commit rather than something that must be typed.

Question 45Git fundamentals (repositories, commits, branching, merging)

Which command shows which branch each local branch tracks and whether it is ahead or behind?

  1. git branch -a
  2. git remote show
  3. git branch --merged
  4. git branch -vv Correct answer.

Explanation

`git branch -vv` prints each local branch with its upstream and ahead/behind counts. `git branch -a` merely lists local and remote-tracking branches, and `--merged` filters branches already merged into HEAD. `git remote show` without a remote name is incomplete and reports remote configuration rather than per-branch status.

Question 46Git fundamentals (repositories, commits, branching, merging)

A commit exists only in the reflog after a hard reset. Why is `git reflog` useful for recovery?

  1. It automatically restores the branch to its last good state
  2. It stores copies of all deleted files on disk
  3. It pushes the lost commit to the remote for safekeeping
  4. It records previous positions of HEAD and branch tips, so the lost commit hash can be found and re-referenced Correct answer.

Explanation

The reflog is an append-only log of ref updates, so a hard reset leaves an entry for the prior tip whose hash can be recovered and given a new branch. It does not contain file contents itself, nor does it restore anything automatically. Recovery still requires an explicit command such as `git branch rescue <hash>`.

Question 47Git fundamentals (repositories, commits, branching, merging)

A developer runs `git rebase -i HEAD~3` and marks the middle commit as `squash`. What results after the rebase completes?

  1. The marked commit is deleted along with its changes
  2. The marked commit's changes are combined into the preceding commit, and a combined message is edited Correct answer.
  3. The marked commit becomes a merge commit with two parents
  4. The marked commit is moved to the end of the branch

Explanation

`squash` folds the commit into the one before it and opens an editor to combine messages, preserving the changes. Dropping a commit requires the `drop` action. Interactive rebase reorders or combines commits linearly and never creates merge commits.

Question 48Git fundamentals (repositories, commits, branching, merging)

Two commits with identical trees and messages exist on divergent branches. What determines whether Git treats them as the same commit?

  1. The commit hash, which incorporates parents, tree, author, committer, and message Correct answer.
  2. The commit message text alone
  3. The tree hash alone
  4. The branch name the commit is reachable from

Explanation

A commit's identity is its SHA hash, computed over the tree, parent hashes, author and committer identities with timestamps, and the message. Identical trees and messages on different parents therefore produce different hashes. Branch names are refs and play no part in the hash.

Question 49Git fundamentals (repositories, commits, branching, merging)

A developer wants to find commits reachable from `feature` but not from `main`, excluding commits already cherry-picked. Which approach matches the semantics of `git cherry`?

  1. Compare patch IDs so commits whose changes already exist upstream are marked with `-` Correct answer.
  2. Compare the number of files changed in each commit
  3. Compare branch names to see which remote they came from
  4. Compare only author dates to decide which commits are new

Explanation

`git cherry` compares each commit's patch ID against the upstream history and marks those already present with `-` and those absent with `+`. This detects cherry-picked equivalents that have different hashes. Dates, branch names, and file counts are not used for this determination.

Question 50Git fundamentals (repositories, commits, branching, merging)

A repository has `core.autocrlf` set inconsistently across team members. What is the most likely consequence for commits?

  1. Line endings may be rewritten on checkout and commit, producing noisy diffs and merge conflicts Correct answer.
  2. Branch creation will fail until the setting is unified
  3. Commits will be rejected because the hashes cannot be computed
  4. Tags will no longer point at the intended commits

Explanation

`core.autocrlf` converts line endings between the working tree and the repository, so differing settings cause files to appear modified and can create conflicts over invisible characters. Hashing, branching, and tagging are unaffected by this setting. A `.gitattributes` file with explicit `text` rules is the usual fix.