Git and Version Control

• A. To compile source code into executable programs
• B. To track changes to files over time and allow you to recover earlier versions
• C. To automatically deploy applications to production servers
• D. To encrypt files so only authorized users can read them

• A. A copy of the entire remote repository stored on your computer
• B. A snapshot of the staged changes saved to the repository history with a message
• C. A request to merge one branch into another
• D. A command that permanently deletes files from the working directory

• A. Centralized systems do not track history, while distributed systems do
• B. In a distributed system, every developer has a full copy of the repository history, while a centralized system relies on a single central server
• C. Centralized systems only work with text files, while distributed systems work with binary files
• D. Distributed systems require an internet connection for every commit, while centralized systems do not

• A. The full commit history of the project
• B. The network speed between you and the remote server
• C. The current state of the working directory and staging area, including modified and untracked files
• D. The size of the repository on disk

• A. Git cannot function without a commit message
• B. They make the project history understandable to others and to your future self when tracking down changes
• C. They automatically generate documentation for the code
• D. They reduce the file size of the repository

• A. git start
• B. git init ✓
• C. git create
• D. git new repo

Why: The command 'git init' initializes a new Git repository by creating a hidden .git directory in the current folder, which stores all version control metadata.

• A. git config --global user.name "Your Name" ✓
• B. git set name "Your Name"
• C. git user --name "Your Name"
• D. git identity add "Your Name"

Why: The 'git config --global user.name' command stores your name in your global Git configuration file, so Git uses it as the author name for all commits in all repositories on that machine.

• A. To store the full commit history of the project
• B. To list files and patterns that Git should not track ✓
• C. To define which branch is the default branch
• D. To store your remote repository credentials

Why: .gitignore is a plain text file where you list files or patterns, such as build outputs, log files, or secret keys, that Git should ignore and not add to version control.

• A. git log
• B. git status ✓
• C. git show
• D. git diff --cached

Why: 'git status' lists which files are modified, staged for commit, or untracked, giving you a snapshot of the current state of your repository.

• A. git commit, then git add, then git push
• B. git add, then git commit ✓
• C. git push, then git add, then git commit
• D. git commit, then git init, then git add

Why: You first stage a file with 'git add' to prepare it for the next snapshot, then run 'git commit' to permanently record the staged changes in the repository history.

• A. git commit
• B. git add ✓
• C. git push
• D. git stash

Why: git add stages changes, moving them from the working directory into the staging area (index) so they will be included in the next commit. git commit records staged changes, git push uploads commits to a remote, and git stash temporarily shelves changes.

• A. git log
• B. git diff
• C. git status ✓
• D. git show

Why: git status lists which files are modified, staged, or untracked. git log shows commit history, git diff shows line-level differences, and git show displays details about a specific commit or object.

• A. It determines which files are tracked by Git
• B. It describes the changes in the commit so others understand the purpose of the change ✓
• C. It encrypts the committed content
• D. It automatically merges branches

Why: A commit message documents what changed and why, helping collaborators and your future self understand the project history. It does not control tracking, encryption, or merging.

• A. git commit -a -m "message" ✓
• B. git add -all commit
• C. git stage --commit
• D. git save -m "message"

Why: The -a flag on git commit automatically stages changes to already-tracked files before committing. Note it does not include brand-new untracked files. The other options are not valid Git syntax.

• A. git rm --cached filename
• B. git reset HEAD filename ✓
• C. git checkout -- filename
• D. git delete filename

Why: git reset HEAD filename removes the file from the staging area while keeping your modifications in the working directory. git checkout -- filename would discard your changes, and git delete is not a Git command.

• A. git branch feature-login
• B. git checkout -b feature-login ✓
• C. git new feature-login
• D. git switch feature-login --create-only

Why: 'git checkout -b feature-login' creates the branch and switches to it in one step. 'git branch feature-login' creates the branch but does not switch to it.

• A. git branch ✓
• B. git show-branches
• C. git list branches
• D. git log --branches

Why: Running 'git branch' with no arguments lists all local branches and marks the current branch with an asterisk. The other options are not valid Git commands for this purpose.

• A. The commits are deleted from the source branch
• B. The commits from the source branch are combined into the current branch ✓
• C. The current branch is renamed to the source branch
• D. Nothing changes until you run git push

Why: Merging integrates the changes from the specified branch into the current branch. The source branch itself is left intact unless you delete it manually.

• A. A failure caused by a corrupted repository
• B. A situation where Git cannot automatically reconcile differing changes to the same lines of a file ✓
• C. A warning that a branch has no commits
• D. An error when pushing to a remote repository

Why: A merge conflict occurs when two branches modify the same part of a file differently, so Git cannot decide which change to keep and asks the developer to resolve it manually.

• A. git branch -D old-feature
• B. git remove branch old-feature
• C. git branch -d old-feature ✓
• D. git delete old-feature

Why: 'git branch -d' deletes the branch only if its changes are already merged into the current or upstream branch, preventing accidental loss of work. The uppercase -D flag forces deletion regardless of merge status.

• A. git pull
• B. git clone ✓
• C. git fetch
• D. git push

Why: git clone creates a full local copy of a remote repository, including its history and branches, and sets up the remote connection automatically. git pull and git fetch require an existing local repository, and git push uploads changes rather than downloading them.

• A. main
• B. origin ✓
• C. upstream
• D. master

Why: When you clone a repository, Git automatically names the source remote 'origin'. This name is a convention, not a requirement, and you can view it with git remote -v.

• A. git fetch origin
• B. git merge origin
• C. git push origin main ✓
• D. git clone origin

Why: git push sends your local commits on the specified branch to the remote repository. git fetch and git merge do not upload anything, and git clone is used only to create a new local copy of a repository.

• A. git fetch downloads remote changes without merging them into your current branch, while git pull downloads and merges them. ✓
• B. git fetch uploads changes, while git pull downloads changes.
• C. git fetch deletes local branches, while git pull creates them.
• D. There is no difference; they are aliases for the same command.

Why: git fetch updates your remote-tracking branches without changing your working files, letting you review changes first. git pull is effectively git fetch followed by git merge (or rebase), so it integrates the changes immediately.

• A. git status
• B. git log
• C. git remote -v ✓
• D. git branch -a

Why: git remote -v lists each remote's name along with its fetch and push URLs. git status shows working tree changes, git log shows commit history, and git branch lists branches, not remote URLs.

• A. To delete a branch from the remote repository
• B. To propose changes from one branch and request that they be reviewed and merged into another branch ✓
• C. To download the latest changes from a remote repository to your local machine
• D. To create a new local branch from the main branch

Why: A pull request is a way to propose changes made on a branch and ask collaborators to review them before merging into a target branch such as main. Downloading changes is done with fetch or pull, and creating branches is done with git branch or git checkout -b.

• A. git fetch origin feature-login
• B. git push origin feature-login ✓
• C. git merge feature-login
• D. git clone feature-login

Why: git push origin feature-login uploads your local feature-login branch to the remote named origin, making it available so a pull request can be opened from it. Fetch downloads changes, merge combines branches locally, and clone copies an entire repository.

• A. Deleting the pull request and opening a new one
• B. Leaving review comments and requesting changes on specific lines of code ✓
• C. Forcing a merge into the main branch
• D. Renaming the author's branch

Why: Platforms like GitHub and GitLab let reviewers attach comments to specific lines and submit a review marked as requesting changes. This keeps feedback organized and tied to the relevant code, rather than requiring a new pull request or bypassing review.

• A. Git does not allow merging without approval
• B. It helps catch bugs, share knowledge, and maintain code quality through peer review ✓
• C. It automatically deletes the old branch
• D. It reduces the size of the repository's history

Why: Requiring approval introduces peer review, which helps find bugs, spreads understanding of the codebase across the team, and enforces quality standards. Git itself does not require approval; this is a workflow or platform policy chosen by the team.

• A. Force-push it to the main branch
• B. Delete the feature branch, since its work now lives in the target branch ✓
• C. Rebase the main branch onto it
• D. Convert it into a tag

Why: Once the changes are merged, the feature branch is no longer needed, so deleting it keeps the repository tidy. The work is preserved in the target branch's history, so nothing is lost by removing the branch.

• A. git status
• B. git log ✓
• C. git diff
• D. git branch

Why: git log lists the commit history, including commit hashes, authors, dates, and messages. You need those hashes to reference a specific commit when undoing changes. git status shows the working tree state, git diff shows line-level changes, and git branch lists branches.

• A. git revert HEAD
• B. git commit --amend ✓
• C. git reset --hard HEAD~1
• D. git checkout --message

Why: git commit --amend replaces the most recent commit with a new one, letting you edit its message or add staged changes. git revert creates a new commit that undoes changes, which is unnecessary for a typo. git reset --hard would delete the commit and its changes, and git checkout has no --message option.

• A. Lines that were deleted in the commit
• B. The boundaries of conflicting sections from each branch that you must resolve manually ✓
• C. Comments automatically added by Git
• D. Lines that have been staged for commit

Why: Git inserts these markers to show the conflicting versions: content from your current branch appears between <<<<<<< and =======, and content from the incoming branch appears between ======= and >>>>>>>. You edit the file to keep the correct code, remove the markers, then stage and commit the resolution.

• A. git reset --hard
• B. git commit --amend
• C. git revert <commit-hash> ✓
• D. git rebase -i

Why: git revert creates a new commit that reverses the changes of the specified commit. Because it adds history rather than rewriting it, it is safe for shared branches. git reset and git rebase rewrite history, which can cause problems for collaborators, and git commit --amend only applies to the latest local commit.

• A. git restore <file> ✓
• B. git add <file>
• C. git merge <file>
• D. git stash drop

Why: git restore <file> discards working directory changes and restores the file to its last committed state. git add stages changes rather than discarding them, git merge combines branches rather than individual files, and git stash drop deletes a stash entry rather than reverting a file.