Git & Version Control MCQ

Explanation

Git is a distributed version control system that tracks changes to files over time, allowing multiple people to collaborate on a project and revert to previous states if needed.

Explanation

"git init" creates a new ".git" subdirectory in the current folder, turning it into a Git repository that can begin tracking file changes.

Explanation

A Git repository contains both the project's files and a complete, versioned history of all changes (commits) made to them, stored in a hidden ".git" directory.

Explanation

"git clone <url>" downloads a complete copy of a remote repository, including all its commits, branches, and tags, to the local machine.

Explanation

"git add <file>" moves changes from the working directory to the staging area (index), marking them to be included in the next "git commit".

Explanation

"git commit -m \"message\"" saves a permanent snapshot of the staged changes to the local repository's history, identified by a unique commit hash.

Explanation

The working directory is where you see and edit your project's files; changes here are "untracked" or "modified" until staged with "git add" and committed.

Explanation

The staging area lets you build up a commit incrementally — you can stage some changes with "git add" while leaving others unstaged, giving fine-grained control over what each commit contains.

Explanation

"git status" gives an overview of your repo's current state — which branch you're on, and which files are staged, modified, or untracked.

Explanation

"git log" shows a chronological list of commits on the current branch, each with its unique hash, author, date, and commit message.

Explanation

A branch is essentially a lightweight, movable pointer to a commit, allowing development to diverge from the main line of work without affecting it until merged.

Explanation

Many platforms and Git versions now default to naming the initial branch "main" instead of the historically used "master", though both can be configured.

Explanation

"git branch <name>" creates a new branch pointer at the current commit, but does not switch to it; "git checkout -b <name>" or "git switch -c <name>" both create and switch to it in one step.

Explanation

Checking out (or switching to) a branch updates the working directory's files to match the tip of that branch and moves HEAD to point to it.

Explanation

HEAD is a pointer that usually points to the latest commit of the currently checked-out branch; it moves automatically as you make new commits or switch branches.

Explanation

"git pull" is essentially a combination of "git fetch" (downloading new data) followed by "git merge" (integrating that data into the current branch).

Explanation

"git push" sends locally committed changes to a remote repository, updating the corresponding remote branch so others can see your work.

Explanation

"origin" is the conventional name given to the remote repository a local repo was cloned from; remotes let you sync changes between local and hosted copies of a repository.

Explanation

".gitignore" specifies patterns for files/directories (like "node_modules/" or "*.log") that Git should never track or show as untracked, keeping the repository clean.

Explanation

A merge conflict arises when two branches have divergent changes to the same lines of a file, requiring a human to manually decide how to resolve the differences before the merge can complete.

Explanation

"git merge <branch>" integrates the changes from the named branch into the current branch, typically creating a merge commit that has two parent commits.

Explanation

"git fetch" is a safer way to see what changes exist on the remote without altering your current work, since it doesn't merge anything until you explicitly do so.

Explanation

Each commit is identified by a SHA-1 hash computed from its content, parent(s), author, and message, ensuring that even a tiny change produces a completely different hash.

Explanation

"git diff" displays line-by-line changes (additions and deletions) between different states, such as working directory vs. staging area, or between two commits.

Explanation

"git rm <file>" deletes the file from the working directory and stages that removal, so the deletion will be recorded in the next commit.

Explanation

"git config" sets values like "user.name" and "user.email" (used to attribute commits) and other settings, at global (per-user) or local (per-repo) scope.

Explanation

Global config (stored in ~/.gitconfig) applies as a default across all repositories for that user, while local config (stored in .git/config) overrides it for a specific repository.

Explanation

Git itself is the underlying version control tool, while GitHub, GitLab, and Bitbucket are separate hosting platforms that add web interfaces, collaboration tools, and CI/CD integrations around Git repositories.

Explanation

PRs/MRs are a feature of hosting platforms (not Git itself) that let team members review, comment on, and discuss proposed changes before they are merged into a target branch.

Explanation

"git revert" is a safe way to undo a commit's changes — instead of rewriting history, it adds a new commit that applies the inverse of the original changes.

Explanation

Tags are references that point to specific commits, commonly used to mark release points like "v1.0.0"; unlike branches, tags don't move as new commits are made.

Explanation

Untracked files exist in the working directory but Git is not yet monitoring changes to them; running "git add" begins tracking them.

Explanation

A README is typically the first file visitors see on a repository's homepage (e.g. on GitHub), providing an overview, setup instructions, and usage documentation for the project.

Explanation

Running "git branch" without arguments lists all local branches, with an asterisk (*) typically indicating the currently checked-out branch.

Explanation

"git show <commit-hash>" displays the commit's message, author, date, and the diff of changes introduced by that commit.

Explanation

A shallow clone (--depth 1) downloads only the latest snapshot of the repository without its full history, which is useful when full history isn't needed, such as in CI pipelines.

Explanation

Forking creates your own copy of someone else's repository on the hosting platform; you can freely make changes there and later propose them back to the original via a pull request.

Explanation

"git mv old_name new_name" is a convenience command equivalent to running "mv" and then "git add" for both the old (removed) and new paths, staging the rename in one step.

Explanation

Without "-m", "git commit" opens the configured text editor for writing a commit message; "-m 'message'" provides it inline, which is convenient for short, single-line messages.

Explanation

A "modified" status means Git is already tracking the file, but you've made changes since the last time it was staged or committed; running "git add" stages those changes.

Explanation

Rebasing creates a cleaner, linear history by replaying commits onto a new base, but it rewrites commit hashes — which is risky on shared/public branches since it changes history that others may have based work on.

Explanation

"git stash" is useful when you need to switch branches quickly without committing half-finished work; "git stash pop" or "git stash apply" later restores the stashed changes.

Explanation

Cherry-picking is useful for selectively applying a single commit's changes (e.g. a bugfix) to another branch without merging the entire source branch.

Explanation

Understanding these levels is critical: "--hard" is destructive and discards uncommitted work, while "--soft" is the safest, simply moving the branch pointer while keeping all changes staged.

Explanation

You enter detached HEAD by checking out a specific commit (rather than a branch); any new commits made here can be "lost" (become unreachable) unless you create a branch to retain them.

Explanation

"git blame" annotates each line of a file with the commit hash, author, and date of its most recent change, helping trace the origin of specific code.

Explanation

When no merge commit is needed (fast-forward), the branch pointer simply advances; "git merge --no-ff" can force a merge commit even when a fast-forward would otherwise be possible, preserving feature-branch context in history.

Explanation

Interactive rebase opens an editor listing commits with actions (pick, squash, edit, drop, etc.) that you can modify, commonly used to clean up commit history before merging a feature branch.

Explanation

Squashing is often done via interactive rebase ("squash" or "fixup" actions) to combine many small "work in progress" commits into one coherent commit before merging into a shared branch.

Explanation

"git remote -v" (verbose) shows the names (e.g. "origin") and corresponding URLs for fetch and push operations of all remotes configured for the repository.

Explanation

Forking is a platform feature (not a core Git command) that creates an independent, server-hosted copy you control, useful for contributing to projects you don't have write access to.

Explanation

"git push -u origin <branch>" sets up tracking, so future "git pull"/"git push" on that branch don't require specifying the remote and branch name explicitly.

Explanation

This combination is a popular way to visualize branch and merge structure directly in the terminal: "--graph" draws lines between commits, "--oneline" condenses each commit to one line, and "--all" includes all refs.

Explanation

Annotated tags (created with "git tag -a") are recommended for releases since they store extra information like the tagger and date, and can be cryptographically signed, unlike lightweight tags (created with "git tag").

Explanation

The ".git" folder is the actual repository — it contains the object database (commits, trees, blobs), refs (branches/tags), HEAD, config, and index (staging area); deleting it removes all version history.

Explanation

"git reflog" can be a lifesaver after an accidental "git reset --hard" or rebase, since it tracks recent HEAD movements and can help you find and recover commits that seem to have "disappeared".

Explanation

"git bisect start" begins a binary search: you mark known good and bad commits, and Git checks out commits in between, narrowing down the exact commit that introduced a regression.

Explanation

Force-pushing rewrites the remote history, which can cause collaborators to lose work or encounter confusing errors; "--force-with-lease" is a safer alternative that fails if the remote has changes you don't have locally.

Explanation

Different merge strategies provide flexibility for special cases — "ours" is sometimes used intentionally to "merge" a branch while discarding its actual content changes, recording history without applying them.

Explanation

Submodules let a project depend on a specific commit of another repository (e.g. a shared library), but they have a reputation for being tricky to use correctly, particularly around updating and cloning.

Explanation

Remote-tracking branches (like "origin/main") are read-only local bookmarks updated by "git fetch"/"git pull" — they reflect the remote's state at the time of the last fetch, not necessarily its current state.

Explanation

"git commit --amend" is useful for fixing a typo in the last commit message or adding a forgotten file, but it creates a new commit hash, so amending commits already pushed to a shared branch can cause issues for collaborators.

Explanation

"git clean -fd" forcibly removes untracked files and directories — useful for clearing build artifacts, but it permanently deletes files not tracked by Git, so it should be used with care (often after a "git clean -n" dry run).

Explanation

Conventional Commits is a community convention (not enforced by Git itself, though tools/hooks can enforce it) where prefixes like "feat:" (new feature) or "fix:" (bug fix) help tools automatically determine version bumps and generate release notes.

Explanation

Without "--follow", Git's history for a file typically stops at the point it was renamed, since Git doesn't explicitly store rename information — "--follow" attempts to detect renames and continue tracing history through them.

Explanation

Git hooks are local scripts triggered by specific Git events; a pre-commit hook can enforce code quality standards by running checks and preventing the commit if they fail, though hooks themselves are not version-controlled by default (tools like Husky help manage this).

Explanation

This command discards local, unstaged modifications to a file — a potentially destructive operation since those changes cannot be recovered afterward, unlike staged or committed changes.

Explanation

Plain "git diff" shows unstaged changes (working directory vs. index), while "git diff --staged" shows staged changes (index vs. HEAD) — useful for reviewing exactly what will be committed.

Explanation

When branches diverge (each has unique commits the other lacks), a simple fast-forward isn't possible — "git pull" would perform a merge (or rebase, depending on configuration) to combine the divergent histories.

Explanation

"git worktree add <path> <branch>" creates an additional working directory linked to the same repository, useful for working on multiple branches simultaneously (e.g. testing a hotfix while a feature is in progress) without stashing or cloning.

Explanation

Most repositories only have one remote ("origin"), so the two commands behave the same in that case, but "--all" becomes meaningful when multiple remotes (e.g. "origin" and "upstream") are configured.

Explanation

A normal commit has one parent (the previous commit), but a merge commit has two or more, reflecting that it combines changes from multiple branch histories into one — this is what gives merge commits their characteristic appearance in "git log --graph".

Explanation

Once an SSH key is added to your GitHub account and the remote URL uses the "git@github.com:..." SSH format, Git operations authenticate automatically using the key pair without repeatedly prompting for credentials.

Explanation

The three-dot syntax is often more useful for reviewing "what does this feature branch add" since it isolates changes unique to one side relative to their common ancestor, ignoring unrelated changes that happened on the other branch.

Explanation

This is useful when applying a stash directly would cause conflicts due to changes made since stashing — creating a fresh branch from the original commit avoids those conflicts entirely.

Explanation

The lowercase "-d" acts as a safety check, preventing accidental loss of commits that exist only on the branch being deleted; "-D" bypasses this check entirely.

Explanation

"git log" supports many filtering options, including date ranges ("--since", "--until") and author matching ("--author"), useful for auditing recent contributions from specific team members.

Explanation

Patch mode is useful for splitting a set of unrelated changes within the same file into separate, logically-focused commits, by selectively staging only some of the changed "hunks" at a time.

Explanation

Branch protection rules are a hosting-platform feature (GitHub, GitLab, etc.) layered on top of Git, used to enforce team workflows like mandatory code review before merging into important branches.

Explanation

CI/CD tools (like GitHub Actions, GitLab CI, Jenkins) integrate with Git repositories by listening for events (pushes, PRs, tags) and running defined workflows in response, automating testing and deployment.

Explanation

This object model (blobs, trees, commits, and tags) forms a content-addressable filesystem — identical file content across different commits is stored only once as the same blob, since the SHA-1 hash is based purely on content.

Explanation

Understanding this distinction clarifies operations like "git add" (updates the index to match a working directory file's blob) and "git commit" (creates a new tree/commit from the index's current state) — files in the object database are immutable once written.

Explanation

Every new commit, blob, or tree initially creates a "loose object" file; over time these accumulate, and "git gc" (often run automatically) packs them into compact packfiles for storage efficiency and faster access.

Explanation

Because rename detection is heuristic and based on content similarity (not stored explicitly), commands like "git log --follow" or "git diff -M" can sometimes miss renames if the file content changed too significantly alongside the rename.

Explanation

"--squash" is useful when you want the combined changes of a feature branch as a single commit on the target branch, with absolutely no trace of the source branch's history or that a merge occurred (no merge commit, no parent reference to the feature branch).

Explanation

Without the merge base as a reference point, Git couldn't distinguish "branch A added this line" from "branch B deleted this line" — comparing against the common ancestor lets Git apply non-overlapping changes automatically and flag only truly conflicting overlaps.

Explanation

Because rewriting history changes the SHA-1 of every affected commit (and all commits built on top of them), this is one of the most disruptive Git operations for collaborators — it should be coordinated carefully, often followed by everyone re-cloning the repository.

Explanation

This optimization avoids the filesystem overhead of having thousands of tiny individual files for repositories with many branches and tags, while still allowing newly created/updated refs to exist as loose files until the next repacking.

Explanation

This property is why Git can detect corruption (a changed object would no longer match its hash-derived filename/identifier) and why identical content (e.g. the same file in different commits) is automatically deduplicated, since it produces the same hash and is stored once.

Explanation

"--onto" gives precise control over the range of commits being replayed and their new base, which is useful in advanced workflows like removing an unwanted intermediate branch from a commit's ancestry or extracting part of a branch's history onto a fresh base.

Explanation

Because client-side hooks live in the local ".git/hooks" directory and aren't version-controlled or transferred via clone/push, server-side hooks are essential for enforcing policies that cannot be bypassed by individual developers' local configurations.

Explanation

This is a good example of how Git maintains administrative state (in ".git/worktrees/") outside of the actual checked-out directories — manual filesystem operations can leave that metadata out of sync, requiring explicit cleanup commands.

Explanation

This distinction matters when timestamps don't reflect the logical order of integration — e.g. if a long-lived branch with old commit dates is merged later, default date-based ordering might interleave its commits confusingly among more recent ones, whereas "--topo-order" keeps the graph structure coherent.

Explanation

Shallow clones are great for CI/CD where only the latest code matters and history isn't needed, but operations requiring historical context (rebase onto an old commit, full blame, certain merge scenarios) may fail or behave unexpectedly until the necessary history is fetched.

Explanation

This pinning behavior provides reproducibility (the parent project always builds against a known-good submodule state) but requires deliberate action ("cd" into the submodule, checkout/pull the desired commit, then commit the updated gitlink in the parent) to "bump" the submodule version.

Explanation

ORIG_HEAD acts as a one-step "undo" safety net for potentially history-altering operations — for example, after a problematic merge or rebase, "git reset --hard ORIG_HEAD" quickly restores the branch to its pre-operation state.

Explanation

Finding the merge base is fundamental to how Git computes diffs between diverged branches (e.g. "git diff main...feature" shows changes on "feature" since it diverged from "main", using the merge base as the starting point, rather than a direct two-way diff of the tips).

Explanation

This cascading hash-rewrite is why rebasing/amending shared history is so disruptive to collaborators — every commit after the edited one effectively becomes a "new" commit object, even though its content diff relative to its (also new) parent might be identical to before.

Explanation

This is especially useful for monorepos where a single developer might only need to work within one project's subdirectory — sparse-checkout avoids checking out potentially massive amounts of unrelated code into the working directory while preserving full history access for the included paths.

Explanation

This low cost of branching is foundational to Git-based workflows that encourage frequent branching for features, experiments, and bugfixes — a practice that would be far more cumbersome in systems where each branch represents a significant copy operation.