Git & GitHub quiz

Ten questions at a time, drawn from 100. Every answer is explained. Nothing is saved and no account is needed.

Question 1 of 10Score 0

If you modify a file in your Working Tree and run 'git commit', why does Git not include your changes in the commit?

All Git & GitHub quiz questions and answers

If you modify a file in your Working Tree and run 'git commit', why does Git not include your changes in the commit?
- The file was not added to the Index.
- The file is currently locked by the operating system.
- The Working Tree is not part of the Git architecture.
- Git requires you to push before committing locally.
Answer: The file was not added to the Index.. Git creates commits based solely on the current state of the Index, not the Working Tree. The other options are incorrect because the file being locked has no effect on Git's logic, the Working Tree is central to Git's architecture, and pushing is unrelated to the commit process.
From lesson: Git Architecture — Working Tree, Index, Repository
What is the primary function of the Index (staging area) in the Git architecture?
- It stores a backup of every version of every file.
- It acts as a buffer to prepare the exact snapshot for the next commit.
- It synchronizes local changes with the remote server automatically.
- It serves as the main database for storing history.
Answer: It acts as a buffer to prepare the exact snapshot for the next commit.. The Index allows the user to carefully craft a commit snapshot. Storing backups, syncing with remotes, and acting as a history database are roles of the repository object database, not the staging area.
From lesson: Git Architecture — Working Tree, Index, Repository
How does the 'git checkout' command impact the three areas of Git?
- It updates the Repository and the Index simultaneously.
- It only modifies files in the Index without changing the disk.
- It updates the Working Tree and the Index to match a specific commit.
- It forces the remote server to delete files in the Working Tree.
Answer: It updates the Working Tree and the Index to match a specific commit.. When checking out a branch or commit, Git overwrites the Index and the Working Tree to align with the state saved in the repository. The other options are wrong because 'git checkout' focuses on local state, not the remote, and it must affect the Working Tree to be useful.
From lesson: Git Architecture — Working Tree, Index, Repository
After performing a 'git add' on a file, how can you revert the changes in the Index without losing the changes in your Working Tree?
- Use 'git reset HEAD <file>'.
- Use 'git rm --cached <file>'.
- Use 'git commit --amend'.
- Use 'git clean'.
Answer: Use 'git rm --cached <file>'.. 'git rm --cached' removes the file from the Index while leaving the file on disk. 'git reset' is often used but 'git rm --cached' is the explicit command for this; 'git commit --amend' affects history, and 'git clean' removes untracked files.
From lesson: Git Architecture — Working Tree, Index, Repository
Which command best describes the movement of data from the Working Tree into the Repository?
- git add followed by git commit
- git push followed by git add
- git commit followed by git push
- git checkout followed by git stage
Answer: git add followed by git commit. Data moves from the Working Tree to the Index via 'git add', then from the Index to the Repository via 'git commit'. The other sequences are logically incorrect steps for moving data into the local history database.
From lesson: Git Architecture — Working Tree, Index, Repository
A developer modifies three files, runs 'git add' on two of them, and then runs 'git commit'. What happens?
- All three modified files are committed.
- Only the two added files are committed.
- The commit fails because the third file is unstaged.
- None of the files are committed until 'git push' is called.
Answer: Only the two added files are committed.. Git only commits files that are currently in the staging area. The third file remains modified but unstaged, so it is ignored. Option 0 is wrong because Git is explicit. Option 2 is wrong because an empty stage or partial stage is allowed. Option 3 is wrong because push is for remote synchronization, not local recording.
From lesson: init, clone, add, commit, status, log
What is the primary function of 'git status' in a daily workflow?
- To sync the local repository with the remote server.
- To display the history of commits made by all team members.
- To check which files are staged, unstaged, or untracked.
- To finalize and save the current state of all files permanently.
Answer: To check which files are staged, unstaged, or untracked.. Status shows the current workspace context. Option 0 is the job of fetch/pull. Option 1 is the job of log. Option 3 describes a commit, not a status check.
From lesson: init, clone, add, commit, status, log
Why would you run 'git log' after a series of commits?
- To verify that your changes were successfully recorded in the repository history.
- To see if any files have been deleted from the working directory.
- To automatically resolve conflicts between local and remote code.
- To initialize a new repository inside a subfolder.
Answer: To verify that your changes were successfully recorded in the repository history.. Log provides a chronological list of snapshots. Option 1 is tracked by status. Option 2 is a separate process. Option 3 describes git init.
From lesson: init, clone, add, commit, status, log
What does 'git clone' perform under the hood?
- It only copies the latest version of the files to your machine.
- It downloads the entire repository history and sets up a local repository.
- It merges the remote repository into your existing local project.
- It adds the remote server as a local branch.
Answer: It downloads the entire repository history and sets up a local repository.. Git is a distributed system, so cloning downloads the full history and metadata. Option 0 is incorrect because it copies the full history, not just the current files. Option 2 implies an existing repo, which clone doesn't expect. Option 3 is conceptually incorrect regarding how remotes work.
From lesson: init, clone, add, commit, status, log
If you are in a directory and run 'git init', what is the immediate effect?
- All files in the directory are automatically committed.
- A hidden '.git' directory is created to manage repository metadata.
- The directory is automatically uploaded to a remote hosting service.
- The directory is locked until you provide a commit message.
Answer: A hidden '.git' directory is created to manage repository metadata.. Init initializes the metadata structure. Option 0 is false as nothing is tracked yet. Option 2 is false as git init is purely local. Option 3 is false as Git does not lock directories.
From lesson: init, clone, add, commit, status, log
You have modified several files and added them to the staging area, but you decide you are not ready to commit them. Which command safely removes these files from the staging area while keeping your changes intact?
- git reset --hard
- git restore --staged <file>
- git revert HEAD
- git checkout -- <file>
Answer: git restore --staged <file>. git restore --staged removes files from the index without affecting working directory changes. Option 0 deletes all work, option 2 creates a new commit, and option 3 is for discarding local changes, not unstaging.
From lesson: Undoing Changes — reset, revert, restore
Your team is collaborating on a shared repository. You realize the last commit pushed to the server contains a bug. What is the safest way to undo this commit?
- git reset --hard HEAD~1 and force push
- git revert HEAD
- git commit --amend
- git rm -r .
Answer: git revert HEAD. git revert creates a new commit that negates the changes, which is safe for shared repos. Option 0 rewrites history, causing issues for others; option 2 only modifies the last commit locally; option 3 deletes files from the index.
From lesson: Undoing Changes — reset, revert, restore
You want to completely discard all local changes to tracked files and return your project to the exact state of the last commit. Which command is most appropriate?
- git restore .
- git reset --soft HEAD
- git revert --no-commit HEAD
- git stash pop
Answer: git restore .. git restore . discards working directory changes for tracked files. Option 1 moves the HEAD but keeps files staged; option 2 creates a revert commit; option 3 restores stashed changes, potentially adding more files.
From lesson: Undoing Changes — reset, revert, restore
If you perform a 'git reset --soft HEAD~1', what happens to the changes from the last commit?
- They are deleted permanently from your computer.
- They are moved to the working directory as modified files.
- They are kept in the staging area (index) ready to be committed again.
- They are automatically pushed back to the remote repository.
Answer: They are kept in the staging area (index) ready to be committed again.. --soft moves the HEAD back one commit while keeping all changes in the staging area. Option 0 describes --hard, option 1 describes --mixed, and option 3 is impossible as reset does not interact with remote pushes.
From lesson: Undoing Changes — reset, revert, restore
When is it appropriate to use 'git reset --hard'?
- When you want to permanently abandon all uncommitted local work and sync to the HEAD commit.
- When you need to undo a push to a public shared branch.
- When you want to merge two branches together.
- When you want to undo a commit but keep the changes in your staging area.
Answer: When you want to permanently abandon all uncommitted local work and sync to the HEAD commit.. --hard is used to reset the working directory and staging area to match the HEAD commit. It is dangerous because it deletes uncommitted work. Options 1, 2, and 3 involve operations (reverting, merging, soft reset) that serve different purposes.
From lesson: Undoing Changes — reset, revert, restore
You have modified a file but have not staged it yet. What happens when you run 'git stash'?
- The file is ignored and remains in the working directory.
- The file is saved to the stash stack and reverted in the working directory.
- The command fails because the file is not staged.
- The file is automatically committed to the current branch.
Answer: The file is saved to the stash stack and reverted in the working directory.. Correct: git stash saves all tracked modifications, regardless of staging status. Option 1 is wrong because tracked files are included. Option 3 is wrong because staging is not a requirement. Option 4 is wrong because stashing creates a separate storage entry, not a commit.
From lesson: Stashing Changes — git stash
Which command should you use to see a list of all your saved stashes?
- git stash log
- git stash view
- git stash list
- git stash show
Answer: git stash list. Correct: 'git stash list' displays the stack of stashes. 'Log' and 'view' are not valid git stash subcommands. 'Show' is used to see the contents of a specific stash, not the list of all entries.
From lesson: Stashing Changes — git stash
What is the primary difference between 'git stash pop' and 'git stash apply'?
- Pop removes the stash after applying; apply keeps it in the stack.
- Apply is for staged files; pop is for unstaged files.
- Pop is faster than apply.
- Apply creates a new commit; pop does not.
Answer: Pop removes the stash after applying; apply keeps it in the stack.. Correct: Pop is a destructive operation that clears the stash entry, whereas apply retains it. The other options describe false functional differences; both work on any modifications and neither creates permanent commits.
From lesson: Stashing Changes — git stash
You have a new, untracked file that you want to include in your stash. What is the correct syntax?
- git stash --new
- git stash -u
- git stash --add-all
- git stash --include-staged
Answer: git stash -u. Correct: The -u (or --include-untracked) flag tells Git to stash files not yet tracked. The other options are either invalid commands or incorrect flags for this specific task.
From lesson: Stashing Changes — git stash
If you are working on a feature, stash it, switch to another branch, and realize you need that code back, what is the best workflow?
- Use git stash apply on the new branch.
- Use git stash checkout to move the stash to the new branch.
- Use git stash merge to combine the stash with the current branch.
- Use git stash move to transfer the stash.
Answer: Use git stash apply on the new branch.. Correct: Git stashes are global to the repository, so you can apply a stash created on one branch to any other branch. Options 2, 3, and 4 reference commands that do not exist or do not perform that specific action.
From lesson: Stashing Changes — git stash
You have modified a file but are not ready to commit. You need to switch to a different branch to work on a hotfix. What is the most efficient workflow?
- Delete the file and checkout the new branch
- Use git stash to save changes, switch branches, then git stash pop when returning
- Force switch branches using the -f flag
- Manually copy the content of the file, switch branches, and paste the code back
Answer: Use git stash to save changes, switch branches, then git stash pop when returning. Stashing temporarily shelves your work, allowing a clean switch. Deleting files or force switching can lead to data loss or conflicts, and manual copying is prone to human error.
From lesson: Creating and Switching Branches
What is the primary purpose of 'git switch -c feature-x'?
- It deletes the current branch and creates a new one
- It moves all commits from the current branch to feature-x
- It creates a new branch named 'feature-x' and immediately checks it out
- It merges the current branch into 'feature-x'
Answer: It creates a new branch named 'feature-x' and immediately checks it out. The -c flag stands for 'create'. Option 1 is incorrect as it does not delete anything; option 2 implies an impossible atomic move of commits; option 4 describes merging, not switching.
From lesson: Creating and Switching Branches
If you are on 'main' and run 'git branch dev', what is the state of your repository?
- You are now on the 'dev' branch
- You are still on the 'main' branch, but 'dev' is created pointing to your current commit
- The 'main' branch is deleted and replaced by 'dev'
- Git automatically merges 'main' into 'dev'
Answer: You are still on the 'main' branch, but 'dev' is created pointing to your current commit. The 'git branch' command only creates a label. You remain on the original branch until you explicitly checkout or switch to the new one.
From lesson: Creating and Switching Branches
When is it appropriate to use 'git branch -D' (uppercase D)?
- When you want to delete a branch that has not yet been merged into the current branch
- When you want to delete the main branch
- When you want to rename a branch permanently
- When you want to merge two branches together
Answer: When you want to delete a branch that has not yet been merged into the current branch. The uppercase -D flag forces deletion, which is necessary if Git detects unmerged work that would be lost. Lowercase -d prevents accidental deletion of unmerged work.
From lesson: Creating and Switching Branches
Why is it recommended to branch off of a clean, up-to-date main branch before starting a new feature?
- Because it is a requirement for the code to compile
- To ensure the new feature is built on the most current stable code and minimize future merge conflicts
- Because Git will automatically lock the main branch
- To force other developers to switch to your new branch
Answer: To ensure the new feature is built on the most current stable code and minimize future merge conflicts. Starting from an outdated branch creates 'configuration drift'. Options 1, 3, and 4 are unrelated to Git's architectural functionality regarding branching.
From lesson: Creating and Switching Branches
What is the primary difference between a fast-forward merge and a three-way merge?
- A fast-forward merge creates a new commit object, while a three-way merge does not.
- A fast-forward merge simply moves the branch pointer forward, while a three-way merge creates a merge commit.
- A fast-forward merge requires resolving conflicts, whereas a three-way merge avoids them.
- A fast-forward merge only works on remote repositories, while a three-way merge is local.
Answer: A fast-forward merge simply moves the branch pointer forward, while a three-way merge creates a merge commit.. A fast-forward merge moves the pointer without creating a commit; a three-way merge creates a new 'merge commit' to tie histories together. Option 0 is backwards; option 2 is incorrect because both can have conflicts; option 3 is irrelevant to location.
From lesson: Merging — Fast-forward vs Three-way
When is a fast-forward merge impossible?
- When the commit history has diverged.
- When the repository has more than two branches.
- When the file size of the changes is too large.
- When the branch being merged is empty.
Answer: When the commit history has diverged.. If the main branch has moved forward since the feature branch started, the histories have diverged, making a simple move impossible. Other options do not prevent fast-forwarding.
From lesson: Merging — Fast-forward vs Three-way
If you perform a 'git merge' on a branch that has diverged, what does Git do by default?
- It stops the process and throws an error.
- It automatically rebases the feature branch.
- It performs a three-way merge and creates a merge commit.
- It forces a fast-forward by discarding remote changes.
Answer: It performs a three-way merge and creates a merge commit.. Git defaults to a three-way merge to integrate diverging lines of history into a merge commit. It does not rebase automatically, nor does it error out or discard changes.
From lesson: Merging — Fast-forward vs Three-way
Why might a team choose to use 'git merge --no-ff' even when a fast-forward is possible?
- To increase the speed of the merge process.
- To ensure all changes are automatically rebased.
- To preserve the fact that a specific branch of work occurred.
- To prevent conflicts from ever occurring.
Answer: To preserve the fact that a specific branch of work occurred.. --no-ff creates a merge commit, which visually preserves the grouping of commits related to a feature. It does not affect speed, rebasing, or conflict prevention.
From lesson: Merging — Fast-forward vs Three-way
Which command ensures that a merge only happens if it can be done as a fast-forward?
- git merge --ff-only
- git merge --no-commit
- git merge --squash
- git merge --strategy=ours
Answer: git merge --ff-only. --ff-only explicitly prevents Git from creating a merge commit if the history has diverged. The other options are for managing commits, squashing, or handling conflicts, not for enforcing linear history.
From lesson: Merging — Fast-forward vs Three-way
What is the primary structural difference between a git merge and a git rebase?
- Merge creates a new commit that combines histories, while rebase rewrites commits to create a linear path.
- Rebase creates a merge commit, while merge prevents the creation of any extra commits.
- Merge deletes the original branch history, while rebase preserves it indefinitely.
- Rebase is used for remote repositories, while merge is strictly for local usage.
Answer: Merge creates a new commit that combines histories, while rebase rewrites commits to create a linear path.. The first option is correct because merge produces a 'merge commit' linking two histories, while rebase moves the feature branch base to the latest main commit. Option 1 is backward; 2 is false as rebase is dangerous on shared branches; 3 is incorrect as both preserve history differently.
From lesson: Rebasing — Rebase vs Merge
When is it considered a 'best practice' to perform a rebase on your local feature branch?
- Every time you want to pull the latest changes from the main branch to keep your feature branch current.
- When you have finished a large project and want to hide all individual commits into one single commit.
- Immediately after someone else has pushed changes to the same branch you are currently working on.
- Whenever you want to delete your branch and move the code to the main branch history.
Answer: Every time you want to pull the latest changes from the main branch to keep your feature branch current.. Rebasing your local feature branch onto the updated main branch keeps your history clean and linear before merging. Option 1 is better handled by 'squash', 2 causes chaos for others, and 3 is not the purpose of rebasing.
From lesson: Rebasing — Rebase vs Merge
If you are in the middle of a rebase and encounter a merge conflict, which sequence of commands is correct to resolve it?
- Edit files, git add, git commit.
- Edit files, git add, git rebase --continue.
- Edit files, git commit, git rebase --continue.
- Edit files, git rebase --continue, git add.
Answer: Edit files, git add, git rebase --continue.. During a rebase, 'git commit' is replaced by 'git rebase --continue' to allow Git to resume the process. You must add the files first to mark them as resolved. Option 0 creates a separate commit, and 2/3 are syntactically incorrect for the rebase flow.
From lesson: Rebasing — Rebase vs Merge
Why is it dangerous to rebase a branch that is being used by multiple developers?
- Because it makes the branch impossible to merge later.
- Because rebase changes the commit hashes, creating a 'diverged' history for other users who base their work on the original commits.
- Because the branch will automatically be deleted by the server.
- Because Git requires a paid license to perform a rebase on shared branches.
Answer: Because rebase changes the commit hashes, creating a 'diverged' history for other users who base their work on the original commits.. Rebasing changes the underlying commit ID (hash), making local versions of that branch for others incompatible with the 'new' version. Option 0 is false; 2 is nonsense; 3 is false as Git is open source.
From lesson: Rebasing — Rebase vs Merge
Which scenario best justifies using 'git merge' instead of 'git rebase'?
- When you want to maintain the exact history of when and how features were integrated into the project.
- When you want to make your commit log look like a single straight line.
- When you have a very large number of tiny, messy 'wip' commits that you want to hide.
- When you are working completely alone on a repository.
Answer: When you want to maintain the exact history of when and how features were integrated into the project.. Merge is preferred for preserving the historical timeline of branches. Rebasing (Option 1) is specifically used for linear histories. Option 2 describes interactive squashing, and 3 is a valid use case for rebase, not merge.
From lesson: Rebasing — Rebase vs Merge
What is the primary effect of running 'git cherry-pick <commit-hash>'?
- It moves the specified commit from one branch to another, deleting it from the original branch.
- It applies the changes introduced by the specified commit as a new commit on the current branch.
- It merges the entire branch containing the commit into the current branch.
- It resets the current branch to match the state of the specified commit.
Answer: It applies the changes introduced by the specified commit as a new commit on the current branch.. Option 2 is correct because cherry-pick replays the changes of a single commit as a new object on your current head. Option 1 is wrong because it doesn't delete the original. Option 3 is wrong because it doesn't merge the history. Option 4 is wrong because it doesn't change the branch pointer to that commit.
From lesson: Cherry-picking Commits
If a cherry-pick results in a conflict, what is the best practice to finalize the process?
- Run 'git reset --hard' and ignore the cherry-picked commit.
- Use 'git revert' to undo the cherry-pick attempt.
- Resolve the files manually, add them to the staging area, and run 'git cherry-pick --continue'.
- Force push the branch to overwrite the conflicting files.
Answer: Resolve the files manually, add them to the staging area, and run 'git cherry-pick --continue'.. Option 3 is the standard Git workflow for resolving conflicts during a cherry-pick sequence. Option 1 loses work, Option 2 is unnecessary for an uncompleted pick, and Option 4 is dangerous and does not resolve the actual code conflict.
From lesson: Cherry-picking Commits
Why does a cherry-picked commit have a different SHA-1 hash than the original commit?
- Because the commit timestamp and parent commit reference are different.
- Because Git automatically encrypts cherry-picked commits differently.
- Because the commit author is always changed to the person who ran the cherry-pick command.
- Because Git renames commits to avoid collisions in the repository.
Answer: Because the commit timestamp and parent commit reference are different.. Option 1 is correct; since the parent and timestamp change, the commit identity changes. Option 2 is false as Git uses SHA-1 hashing, not encryption. Option 3 is incorrect as the author remains the same by default. Option 4 is incorrect; hashes are generated by content and metadata, not by a naming service.
From lesson: Cherry-picking Commits
When should you prefer a standard 'git merge' over 'git cherry-pick'?
- When you want to bring in a single bug fix from a production branch.
- When you need to copy a specific commit to your local branch without merging full feature histories.
- When you want to integrate a long-running feature branch that contains multiple related commits.
- When you want to keep the commit history linear without any merge commits.
Answer: When you want to integrate a long-running feature branch that contains multiple related commits.. Option 3 is correct because merging is designed for integrating entire workstreams. Option 1 and 2 are typical use cases for cherry-picking. Option 4 describes a reason to use rebase, not necessarily merge or cherry-pick.
From lesson: Cherry-picking Commits
What happens to the original commit after you cherry-pick it?
- It is permanently moved to the new branch.
- It is marked as 'cherry-picked' in the Git log metadata.
- It remains completely unchanged in the original branch's history.
- It is converted into a patch file and deleted from the repository.
Answer: It remains completely unchanged in the original branch's history.. Option 3 is correct; Git preserves the original history. Option 1 is wrong as 'move' implies deletion, which doesn't happen. Option 2 is false as Git logs do not add metadata to the original commit. Option 4 is wrong because the original commit persists in the history.
From lesson: Cherry-picking Commits
What is the primary purpose of the conflict markers (<<<<<<<, =======, >>>>>>>) that Git inserts into files?
- To signify that the file is corrupt and must be deleted
- To identify the specific sections of code that were modified by different branches
- To inform the system which branch is currently the active HEAD
- To provide a backup of the original file before the merge attempt
Answer: To identify the specific sections of code that were modified by different branches. These markers clearly demarcate the content from the HEAD (yours) and the branch being merged (theirs). Option 0 is wrong because the file is not corrupt. Option 2 is wrong because markers don't track the HEAD status. Option 3 is wrong because they do not act as backups.
From lesson: Conflict Resolution
After you have successfully edited the conflicted files to remove all markers, what is the next step you must perform?
- Run 'git merge --continue'
- Run 'git push' to update the remote server
- Stage the resolved files using 'git add'
- Create a new branch for the resolved code
Answer: Stage the resolved files using 'git add'. Git requires you to explicitly stage the resolved files to tell it that the conflict is handled. Option 0 is not a standard Git command. Option 1 is premature as you haven't finished the merge commit. Option 3 is unnecessary and creates redundant workflow complexity.
From lesson: Conflict Resolution
What happens if you resolve a conflict and commit it, but leave one of the marker symbols (e.g., '=======') inside the file?
- Git automatically detects the symbol and removes it during the next push
- The code will likely result in a syntax error when compiled or executed
- Git will refuse to merge the branch entirely
- The file will be treated as a binary file by Git
Answer: The code will likely result in a syntax error when compiled or executed. Git does not validate code syntax; it sees the marker as part of the text, which will cause issues in your source code. Option 0 is false as Git doesn't 'auto-clean' code. Option 2 is false as the merge is already committed. Option 3 is false as Git is agnostic to file types.
From lesson: Conflict Resolution
Why is 'git merge' often preferred over 'git rebase' when dealing with complex conflicts in a shared team branch?
- Merge creates a record of the conflict resolution through a merge commit
- Rebase is incapable of handling conflicts
- Merge automatically fixes all logic errors during the resolution process
- Rebase requires significantly more RAM on the local machine
Answer: Merge creates a record of the conflict resolution through a merge commit. Merge commits provide a clear point in history showing when and how branches joined. Option 1 is false because rebase handles conflicts fine. Option 2 is false because code logic is the developer's responsibility. Option 3 is irrelevant to Git's performance.
From lesson: Conflict Resolution
When you are in the middle of a conflict resolution process and realize you made a mistake, how do you safely revert back to the state before the merge?
- Delete the local repository and clone it again
- Run 'git reset --hard HEAD'
- Run 'git merge --abort'
- Modify the .git/config file to disable conflicts
Answer: Run 'git merge --abort'. The 'git merge --abort' command is the safe, intended way to stop the process and return to the pre-merge state. Option 0 is overkill and unnecessary. Option 1 would wipe all your recent local work. Option 3 is impossible as configuration cannot disable conflict detection.
From lesson: Conflict Resolution
What is the primary difference between 'git fetch' and 'git pull'?
- Fetch updates the working directory, while pull only updates the hidden .git directory.
- Fetch downloads remote data but does not modify your working branch; pull downloads and merges in one step.
- Pull is a destructive command that deletes local commits, while fetch is safe.
- There is no difference; they are aliases for the exact same process.
Answer: Fetch downloads remote data but does not modify your working branch; pull downloads and merges in one step.. Option 2 is correct because fetch updates remote-tracking branches without touching your current files. Option 1 is backward. Option 3 is false as pull is usually non-destructive to history. Option 4 is false as they have distinct mechanical behaviors.
From lesson: Remotes — push, pull, fetch
You try to push your changes, but Git says 'non-fast-forward'. What does this mean?
- You have remote commits that you do not have locally.
- You have too many files staged for the remote server to process.
- Your local branch has diverged, and pushing would overwrite history.
- The remote repository is currently offline or read-only.
Answer: Your local branch has diverged, and pushing would overwrite history.. Option 3 is correct because Git prevents pushes that result in lost commits on the server. Option 1 describes a pull requirement. Option 2 and 4 are unrelated to the fast-forward error.
From lesson: Remotes — push, pull, fetch
Why is 'git push -u origin <branch>' preferred when creating a new branch?
- It forces the remote to accept the new branch even if there are conflicts.
- It compresses the history to make the push faster.
- It establishes a tracking relationship, allowing future 'git pull' commands without arguments.
- It immediately creates a pull request on GitHub.
Answer: It establishes a tracking relationship, allowing future 'git pull' commands without arguments.. Option 3 is correct as '-u' sets the upstream branch. Option 1 is false (push does not resolve merge conflicts). Option 2 is a misunderstanding of push mechanics. Option 4 happens on GitHub, not via the git CLI.
From lesson: Remotes — push, pull, fetch
If you perform a 'git fetch', where are the changes stored before you decide to merge them?
- In your staging area (index).
- In your working directory as untracked files.
- In remote-tracking branches like 'origin/main'.
- They are held in a temporary stash.
Answer: In remote-tracking branches like 'origin/main'.. Option 3 is correct because fetch updates the pointers in your local .git folder representing the remote state. Options 1 and 2 are incorrect because the working directory/staging area remains untouched. Option 4 is incorrect as stash is a separate storage mechanism.
From lesson: Remotes — push, pull, fetch
What happens if you run 'git pull' while you have uncommitted changes in your working directory?
- Git will automatically stash your changes, pull, and then restore them.
- Git will refuse to pull if the incoming changes conflict with your local files to prevent data loss.
- Git will overwrite your local changes with the remote version.
- The pull will automatically create a new commit for your local changes.
Answer: Git will refuse to pull if the incoming changes conflict with your local files to prevent data loss.. Option 2 is correct; Git preserves local work by preventing pulls that would cause conflicts. Option 1 is incorrect (it does not stash automatically). Option 3 is incorrect as Git defaults to safety. Option 4 is incorrect as a pull cannot commit local files it doesn't know about.
From lesson: Remotes — push, pull, fetch
What is the primary function of setting an 'upstream' branch in Git?
- To force the remote repository to copy the local file structure
- To establish a link that allows Git to know which remote branch to interact with during pulls and pushes
- To automatically merge the entire remote repository into the local directory
- To prevent other contributors from pushing to the same remote branch
Answer: To establish a link that allows Git to know which remote branch to interact with during pulls and pushes. Setting the upstream creates a direct relationship between your local branch and a remote counterpart. Option 0 is incorrect because it's about syncing, not configuring. Option 2 describes merging, not tracking. Option 3 relates to permissions, not tracking.
From lesson: Tracking Branches
Which command successfully creates a local branch and sets its upstream to a specific remote branch simultaneously?
- git branch --set-upstream-to origin/main
- git checkout -b feature-branch origin/feature-branch
- git remote add origin
- git push origin feature-branch
Answer: git checkout -b feature-branch origin/feature-branch. Using 'git checkout -b' with a remote branch automatically sets up tracking. Option 0 is for existing branches. Option 2 is for adding a remote, not a branch. Option 3 pushes code but does not necessarily set the local branch to track the remote one unless -u is used.
From lesson: Tracking Branches
If you run 'git branch -vv', what information are you primarily investigating?
- The list of all files changed in the last three commits
- The current tracking status of your local branches relative to their remote counterparts
- The list of all remote repositories configured in your project
- The timestamp of the last successful push to GitHub
Answer: The current tracking status of your local branches relative to their remote counterparts. The '-vv' flag shows verbose branch information, specifically the tracking relationship. The other options are incorrect because they relate to logs, remote management, or commit history, not tracking status.
From lesson: Tracking Branches
When you see 'Your branch is ahead of 'origin/main' by 2 commits', what does this imply?
- The remote repository has 2 new commits that you need to pull
- You have 2 commits locally that have not been pushed to the tracked remote branch
- There is a merge conflict involving 2 files in your current branch
- Your local branch has deleted 2 files that exist on the remote
Answer: You have 2 commits locally that have not been pushed to the tracked remote branch. Being 'ahead' means your local history contains commits not present on the tracked remote. Option 0 describes being 'behind'. Option 2 and 3 describe entirely different Git states related to conflicts or file status.
From lesson: Tracking Branches
Why does Git sometimes prompt you to specify a remote and branch name during a pull?
- Because the remote server is offline
- Because the local branch lacks an upstream tracking relationship
- Because you have not committed your local changes yet
- Because you are not authenticated with your GitHub account
Answer: Because the local branch lacks an upstream tracking relationship. If no tracking is defined, Git doesn't know where to pull from. Options 0, 2, and 3 describe issues with connectivity, staging/committing, or authentication, none of which trigger the specific 'specify remote' request.
From lesson: Tracking Branches
When is it technically safe to use a standard 'git push --force'?
- When you are the only person working on a feature branch
- When you want to resolve a merge conflict quickly
- When your teammate has updated the remote branch
- When you have already pushed to the main branch
Answer: When you are the only person working on a feature branch. It is safe only on private feature branches where you are the sole contributor. Other options are wrong because they involve shared branches or ignoring potential data loss from others.
From lesson: Force Push — When and Why (carefully)
What is the primary benefit of using 'git push --force-with-lease' compared to 'git push --force'?
- It makes the push faster by skipping integrity checks
- It prevents overwriting remote work that you haven't fetched yet
- It automatically merges your changes with the remote history
- It creates a backup of the remote branch before overwriting
Answer: It prevents overwriting remote work that you haven't fetched yet. The 'lease' check verifies if the remote branch has moved since you last fetched it, preventing you from accidentally deleting commits pushed by others. Other options inaccurately describe the safety mechanism.
From lesson: Force Push — When and Why (carefully)
If 'git push' is rejected with a message about non-fast-forward updates, what is the safest professional workflow?
- Immediately execute 'git push --force'
- Delete the remote branch and re-upload
- Fetch, rebase your changes on top of the remote, then push
- Rename your local branch and try pushing again
Answer: Fetch, rebase your changes on top of the remote, then push. Rebasing integrates remote changes into your history correctly. The other options involve destructive actions or do not solve the actual divergence in commit history.
From lesson: Force Push — When and Why (carefully)
Why should you avoid force pushing on a shared repository branch?
- Because it triggers an automated security audit
- Because it makes the repository size grow significantly
- Because it rewrites shared history and destroys other people's commit references
- Because it prevents GitHub from tracking pull request comments
Answer: Because it rewrites shared history and destroys other people's commit references. Force pushing changes the commit hashes, effectively removing history that others depend on. The other options are either irrelevant or technically incorrect regarding Git functionality.
From lesson: Force Push — When and Why (carefully)
You have rewritten your local commit history using an interactive rebase. To update the remote feature branch, what is the best practice?
- Use 'git push --force' only if you are certain no one else pulled the branch
- Use 'git push' and accept that it will fail until a merge occurs
- Use 'git push --force-with-lease' to safely overwrite your own prior commits
- Create a brand new branch name to avoid conflicts
Answer: Use 'git push --force-with-lease' to safely overwrite your own prior commits. This approach is safe because it enforces that only your own previous commits are overwritten if no new remote activity has occurred. The other options either create unnecessary work or expose the developer to unsafe overwriting.
From lesson: Force Push — When and Why (carefully)
When a reviewer asks for changes, what is the best practice for updating your PR?
- Delete the branch and open a completely new PR.
- Push new commits to the same branch, which updates the existing PR.
- Close the PR and ask the reviewer to manually edit your code.
- Force push changes to the main branch to overwrite the previous history.
Answer: Push new commits to the same branch, which updates the existing PR.. Pushing new commits to the existing branch is the correct way to iterate on a PR. Deleting the branch wastes the PR's history; closing it is unnecessary; force pushing to main is destructive and dangerous.
From lesson: Pull Requests and Code Review
What is the primary benefit of keeping a pull request focused on a single task?
- It hides mistakes by grouping them with correct code.
- It forces the reviewer to focus only on stylistic issues.
- It improves code quality by making the logic easier to audit and test.
- It allows you to bypass the need for automated tests.
Answer: It improves code quality by making the logic easier to audit and test.. Smaller PRs are easier to audit for logic errors. Option 1 is unethical, option 2 is not the goal of a review, and option 4 is never a valid practice.
From lesson: Pull Requests and Code Review
If your PR has merge conflicts with the target branch, what is the recommended workflow to resolve them?
- Merge the target branch into your feature branch and resolve conflicts locally.
- Wait for the project maintainer to manually fix your conflicts.
- Ignore the conflicts and hope the platform resolves them automatically.
- Delete the files that are causing the merge conflicts.
Answer: Merge the target branch into your feature branch and resolve conflicts locally.. You must pull the latest changes into your branch to resolve conflicts, ensuring your code works with the current state. Maintainers should not fix your conflicts, conflicts aren't auto-fixed, and deleting files breaks functionality.
From lesson: Pull Requests and Code Review
Why is it important to provide a detailed description in your pull request?
- To increase the character count for search engine indexing.
- To explain the context, the rationale, and how to verify the changes.
- To prevent other developers from understanding your code.
- Because it is required to automatically merge the code without reviews.
Answer: To explain the context, the rationale, and how to verify the changes.. Documentation helps reviewers understand intent, which is vital for effective code reviews. Other options are incorrect as they either hinder collaboration or provide false justifications.
From lesson: Pull Requests and Code Review
What should you do if you disagree with a reviewer's feedback?
- Ignore the feedback and merge the PR immediately.
- Report the reviewer to the repository owner.
- Start a respectful, objective discussion to explain your reasoning or clarify the approach.
- Immediately accept the feedback even if you know it introduces a bug.
Answer: Start a respectful, objective discussion to explain your reasoning or clarify the approach.. Code review is a collaborative process; discussion is expected when perspectives differ. Ignoring feedback or mindlessly accepting it is poor practice, and reporting a reviewer for feedback is unprofessional.
From lesson: Pull Requests and Code Review
When defining a workflow, why is it standard practice to place the 'actions/checkout' step before any build or test steps?
- To verify that the runner has an active internet connection to GitHub.
- To fetch the repository's source code so the runner can interact with the files.
- To automatically authenticate the user against the GitHub API.
- To set the working directory to the root of the project by default.
Answer: To fetch the repository's source code so the runner can interact with the files.. The correct answer is fetching the source code because runners start in an empty environment. Option 0 is wrong because runners don't need to check connection state. Option 2 is wrong because the default token is handled by the runner environment, not the checkout action. Option 3 is wrong because checkout does not define the working directory path.
From lesson: GitHub Actions — CI/CD Basics
What happens if a step in a GitHub Actions job fails, and 'continue-on-error' is set to false (default)?
- The subsequent steps in that job will skip, and the job status will be marked as failed.
- The workflow pauses until the user manually restarts the specific step.
- The job ignores the error and proceeds to the next step, but reports a warning.
- The runner attempts to re-execute the step up to three times automatically.
Answer: The subsequent steps in that job will skip, and the job status will be marked as failed.. The correct answer is that subsequent steps skip and the job fails, halting the pipeline. Option 1 is wrong because it does not pause automatically. Option 2 describes the 'continue-on-error' behavior. Option 3 is wrong because no automatic retry logic is built into the standard step execution.
From lesson: GitHub Actions — CI/CD Basics
Which of the following is the most secure way to handle a database password in your GitHub Actions workflow?
- Include the password as a plain text string in the YAML file.
- Store the password in a GitHub Environment Secret and call it using ${{ secrets.DB_PASS }}.
- Export the password as a shell variable in an 'echo' command within the 'run' block.
- Commit an encrypted '.env' file to the repository and decrypt it at runtime.
Answer: Store the password in a GitHub Environment Secret and call it using ${{ secrets.DB_PASS }}.. The correct answer is using GitHub Secrets. Option 0 exposes the password to everyone. Option 2 is insecure because 'echo' commands can be logged. Option 3 is a security risk if the decryption key is not managed correctly; Secrets are the intended native solution.
From lesson: GitHub Actions — CI/CD Basics
If you want a workflow to run only when a Pull Request is opened, which event configuration should you use?
- on: push
- on: pull_request: types: [opened]
- on: workflow_run: types: [created]
- on: repository_dispatch
Answer: on: pull_request: types: [opened]. The correct answer is 'pull_request' with the 'opened' type filter. Option 0 triggers on direct commits, not PR creation. Option 2 is for workflow orchestration. Option 3 is for triggering workflows via API calls, not PR events.
From lesson: GitHub Actions — CI/CD Basics
What is the primary benefit of using a 'matrix' strategy in a GitHub Actions job?
- It allows you to store multiple passwords in a single secret.
- It creates multiple instances of a job to test across different OS versions or configurations.
- It compresses all job logs into a single summary file.
- It allows the workflow to use multiple different runner platforms at the exact same time inside one step.
Answer: It creates multiple instances of a job to test across different OS versions or configurations.. The correct answer is running jobs across multiple configurations (e.g., Ubuntu, macOS, Windows). Option 0 is incorrect as secrets are simple key-value pairs. Option 2 is wrong because logs are kept separate. Option 3 is wrong because a single step can only run on one platform at a time.
From lesson: GitHub Actions — CI/CD Basics
What is the primary security benefit of requiring 'Signed commits' in branch protection rules?
- It prevents developers from pushing code that lacks a clear explanation.
- It verifies the author's identity, ensuring commits originate from a trusted, verified source.
- It automatically scans for security vulnerabilities in the source code.
- It forces the system to perform a local build before allowing the merge.
Answer: It verifies the author's identity, ensuring commits originate from a trusted, verified source.. Signed commits verify the identity of the author via GPG keys. Option 0 describes commit messages, 2 describes security scanning tools, and 3 refers to status checks.
From lesson: Branch Protection Rules
If you want to ensure that code changes are peer-reviewed before being merged, which rule is the most effective?
- Require status checks to pass before merging.
- Restrict who can push to matching branches.
- Require pull requests before merging.
- Lock branch settings.
Answer: Require pull requests before merging.. Requiring pull requests mandates a review process. Option 0 checks for build quality, 1 limits push permissions (but doesn't enforce review), and 3 is a general settings lock.
From lesson: Branch Protection Rules
What happens when 'Require branches to be up to date before merging' is enabled?
- The branch must contain all the latest security patches from GitHub.
- The pull request must be merged before the local branch can be deleted.
- The branch must be tested against the latest version of the base branch before the merge button becomes active.
- The merge button is disabled until the developer submits a second pull request.
Answer: The branch must be tested against the latest version of the base branch before the merge button becomes active.. This rule ensures the feature branch has been reconciled with the target branch's latest state. The other options describe incorrect workflows or unrelated tasks.
From lesson: Branch Protection Rules
Why would a team choose to enable 'Dismiss stale pull request approvals when new commits are pushed'?
- To force reviewers to re-evaluate code changes that may have fundamentally altered the logic of the PR.
- To save space on GitHub servers by clearing out old review comments.
- To increase the speed of the CI pipeline by ignoring previous test results.
- To prevent developers from making unnecessary small commits to the PR.
Answer: To force reviewers to re-evaluate code changes that may have fundamentally altered the logic of the PR.. New commits might invalidate previous logic reviews. Option 1 is about storage, 2 is about performance, and 3 is a behavioral restriction not controlled by this setting.
From lesson: Branch Protection Rules
A developer cannot push to a branch despite having write access to the repository. What is the most likely cause?
- The repository has reached its storage limit.
- The branch is protected, and they lack the specific 'bypass' or 'push' permissions defined in the rules.
- The developer's local Git configuration is set to 'read-only' mode.
- The repository owner has deleted the branch remotely.
Answer: The branch is protected, and they lack the specific 'bypass' or 'push' permissions defined in the rules.. Branch protection rules override general repo permissions. Option 0 is rare, 2 is not a standard Git setting, and 3 would manifest as a different error entirely.
From lesson: Branch Protection Rules
When you want to automatically close an issue via a pull request, what is the best practice?
- Mention the issue number in the PR description using a keyword like 'closes'.
- Delete the issue after you merge the pull request.
- Manually close the issue in the UI after the merge.
- Add a comment to the issue with the link to your code.
Answer: Mention the issue number in the PR description using a keyword like 'closes'.. Using 'closes #number' in the PR description allows GitHub to link and close the issue automatically upon merging. Manually closing or deleting is inefficient and misses the automation; commenting a link does not trigger status updates.
From lesson: GitHub Issues and Projects
Which of the following is the primary purpose of a GitHub Project board?
- Storing the raw source code of the repository.
- Visualizing the status and flow of work items.
- Hosting documentation files for the project.
- Managing user permissions and access levels.
Answer: Visualizing the status and flow of work items.. Project boards are for task management and workflow visualization. Storing code is for the repo, hosting documentation is for Wikis or Markdown files, and permissions are handled in repository settings.
From lesson: GitHub Issues and Projects
Why should you use Labels on GitHub Issues?
- To permanently prevent other users from commenting.
- To categorize issues by type, priority, or status for easier filtering.
- To increase the search engine optimization of your repository.
- To assign multiple developers to a task simultaneously.
Answer: To categorize issues by type, priority, or status for easier filtering.. Labels are the standard way to organize and filter issues. They do not restrict comments, affect SEO, or handle assignments, which are handled by the 'Assignees' field.
From lesson: GitHub Issues and Projects
If an issue is open, but you are waiting for more information from the reporter, what is the recommended workflow?
- Close the issue immediately to keep the board clean.
- Create a new repository to house the conversation.
- Use a label like 'needs-info' and keep the issue open to track the request.
- Ignore the issue until the user submits a new one.
Answer: Use a label like 'needs-info' and keep the issue open to track the request.. Labels like 'needs-info' help maintain transparency. Closing it kills the tracking, a new repo is overkill, and ignoring it prevents the issue from being resolved properly.
From lesson: GitHub Issues and Projects
What happens to a card in a GitHub Project when it is linked to a Pull Request that gets merged?
- The card is automatically deleted from the board.
- The card status can be configured to move automatically to a 'Done' column.
- The project board will lock all other cards from being moved.
- The pull request is automatically reverted.
Answer: The card status can be configured to move automatically to a 'Done' column.. GitHub Projects support automation workflows that trigger state changes based on PR status, such as moving to 'Done'. The card is not deleted, locking is not a feature, and it does not revert code.
From lesson: GitHub Issues and Projects
Which branch is the primary source of truth for the project's history in Gitflow?
- feature
- develop
- main
- hotfix
Answer: main. Main represents the production-ready state. Develop is for integration, feature is for individual tasks, and hotfix is for urgent patches; none of these should be considered the permanent record of production deployments like main.
From lesson: Gitflow Workflow
Why is it important to merge hotfix branches into both main and develop?
- To satisfy Git status requirements.
- To ensure the production fix is integrated into the next development cycle.
- Because Gitflow requires all branches to be merged twice.
- To trigger an automatic deployment to both environments.
Answer: To ensure the production fix is integrated into the next development cycle.. Merging into main fixes the production issue, while merging into develop ensures the fix persists in future releases. Merging only to one creates a regression risk where the fix is lost in the next development cycle.
From lesson: Gitflow Workflow
What is the recommended workflow for completing a feature branch in Gitflow?
- Merge it directly into main.
- Merge it into develop, then delete the feature branch.
- Merge it into a release branch for final testing.
- Rebase it onto main before merging.
Answer: Merge it into develop, then delete the feature branch.. Features are intended to be integrated into develop. Merging to main is premature; merge to release is non-standard; and rebasing is not a required step for feature completion in the basic Gitflow model.
From lesson: Gitflow Workflow
When is it appropriate to create a release branch?
- When a new feature is started.
- When the develop branch has reached a state of feature completeness for the next release.
- When a critical bug is discovered in production.
- Every time a developer pushes code to the remote repository.
Answer: When the develop branch has reached a state of feature completeness for the next release.. Release branches are for final prep like documentation and minor bug fixes before a release. Feature start is for features, hotfix is for production bugs, and pushing code is a daily activity, not a release trigger.
From lesson: Gitflow Workflow
In Gitflow, what is the purpose of the feature branch naming convention?
- To inform GitHub of the priority level.
- To allow the Git client to automatically merge the code.
- To maintain organization and identify the purpose of the work-in-progress.
- To satisfy the requirements for automatic deployment.
Answer: To maintain organization and identify the purpose of the work-in-progress.. Naming conventions like 'feature/' help distinguish work branches from support branches. GitHub doesn't prioritize based on names, Git clients don't auto-merge based on labels, and deployment tools do not rely on branch names for logic.
From lesson: Gitflow Workflow
What is the primary goal of Trunk-Based Development in a Git workflow?
- To enforce a strict hierarchy of repository administrators
- To minimize the duration of branch divergence from the main line
- To prevent developers from using the command line
- To ensure every single commit is deployed to production instantly
Answer: To minimize the duration of branch divergence from the main line. Trunk-based development focuses on merging small, frequent updates into the main branch to avoid long-lived branches. Other options describe bureaucratic controls, platform limitations, or CI/CD deployment strategies rather than the core Git branching philosophy.
From lesson: Trunk-Based Development
When a developer is working on a feature in a short-lived branch, what should they do before merging into main?
- Delete the remote repository and recreate it
- Rebase their branch against the current main branch to incorporate upstream changes
- Create a new branch for every file they modified
- Force push their local branch to main to ensure it overwrites history
Answer: Rebase their branch against the current main branch to incorporate upstream changes. Rebasing ensures the local branch is up-to-date with the main line, avoiding conflicts during the merge. Forcing pushes or recreating repositories breaks history and collaboration, while multiple branches for one feature defeat the purpose of trunk-based flow.
From lesson: Trunk-Based Development
How does Trunk-Based Development change the role of the Pull Request (PR) compared to long-lived branching strategies?
- PRs are eliminated and replaced by physical mail
- PRs are used only for final release candidates
- PRs become smaller and shorter-lived to facilitate rapid code review
- PRs are restricted to senior developers only
Answer: PRs become smaller and shorter-lived to facilitate rapid code review. In trunk-based development, the goal is to keep PRs small so they can be reviewed and merged quickly. Eliminating them or limiting them by seniority/release phase contradicts the goal of continuous integration.
From lesson: Trunk-Based Development
Why are 'long-lived' feature branches considered detrimental in a team environment?
- They are incompatible with the Git graphical interface
- They make it difficult to identify integration errors until late in the development cycle
- They use too much local disk space on the developer's machine
- They force the use of submodules
Answer: They make it difficult to identify integration errors until late in the development cycle. The longer a branch exists, the more it drifts from the main code base, leading to 'integration hell.' The other options are misconceptions about Git's technical constraints or features.
From lesson: Trunk-Based Development
What is the recommended approach for handling unfinished features in a trunk-based environment?
- Commit only to a hidden local file not tracked by Git
- Merge the unfinished code and hope it compiles
- Use feature flags to merge code into main while keeping the functionality disabled
- Keep the branch open for months until the feature is perfect
Answer: Use feature flags to merge code into main while keeping the functionality disabled. Feature flags allow teams to integrate code into main continuously without exposing unfinished features to users. Merging broken code is bad practice, and keeping branches open defeats the trunk-based philosophy.
From lesson: Trunk-Based Development
Which of the following commit subjects follows the Conventional Commits specification perfectly?
- feat: Add user authentication
- FEAT: add user authentication
- Add user authentication
- feat(auth) add user authentication
Answer: feat: Add user authentication. The first option uses the correct lowercase type and a colon-space separator. The second is wrong because the type must be lowercase. The third lacks the type/scope structure. The fourth is wrong because it misses the colon after the scope.
From lesson: Conventional Commits
If you modify a function's return signature causing downstream dependencies to break, how should you denote this?
- Include 'major:' in the subject line
- Add 'BREAKING CHANGE:' to the footer of the commit message
- Use the type 'breaking'
- Prefix the commit subject with '!' or 'major'
Answer: Add 'BREAKING CHANGE:' to the footer of the commit message. The specification requires a 'BREAKING CHANGE:' prefix in the footer (or a '!' before the colon in the header). Option 0 is wrong because 'major' is not a standard tag. Option 2 is wrong because 'breaking' is not a standard type. Option 3 is non-standard.
From lesson: Conventional Commits
What is the primary purpose of the 'scope' in a Conventional Commit?
- To define which programming language is being used
- To specify the sub-component or module of the repository affected
- To list all the files modified in the commit
- To describe the priority level of the commit
Answer: To specify the sub-component or module of the repository affected. The scope identifies the specific part of the codebase changed (e.g., 'fix(ui): ...'). Option 0 is wrong as the language is project-wide. Option 2 is wrong because file lists are handled by git status. Option 3 is irrelevant to the scope.
From lesson: Conventional Commits
Why is it important to follow Conventional Commits when using GitHub features like Releases?
- It makes the commit history look professional
- It allows GitHub to automatically generate changelogs and determine semantic versions
- It prevents merge conflicts in the main branch
- It enforces the use of Pull Requests
Answer: It allows GitHub to automatically generate changelogs and determine semantic versions. Automated tools parse the commit messages to group changes by type ('feat', 'fix') and determine if a patch, minor, or major version update is needed. The other options are either side effects or unrelated to the specification.
From lesson: Conventional Commits
When should you use the 'chore' type in a commit message?
- When fixing a bug that users might notice
- When adding a new feature to the product
- When performing routine tasks like updating dependencies or build scripts
- When documenting code changes
Answer: When performing routine tasks like updating dependencies or build scripts. 'chore' is for maintenance tasks that don't change the source code or affect the end-user. 'feat' is for new features. 'fix' is for bug fixes. Documentation changes should usually use the 'docs' type.
From lesson: Conventional Commits
What is the primary difference between 'git merge' and 'git rebase'?
- Merge creates a new commit, while rebase rewrites the commit history.
- Rebase preserves original commit timestamps, while merge changes them.
- Merge is for local repositories, while rebase is for remote repositories.
- Rebase creates a merge commit, while merge maintains a linear history.
Answer: Merge creates a new commit, while rebase rewrites the commit history.. Merge creates a dedicated merge commit, preserving historical structure. Rebase moves or combines a sequence of commits to a new base, creating a linear project history. The other options describe incorrect functional roles or behavior.
From lesson: Git Interview Questions
If you are in the middle of a complex rebase and encounter conflicts, what is the best way to safely abort the process and return to your original state?
- git rebase --hard
- git rebase --abort
- git reset --hard HEAD
- git checkout main
Answer: git rebase --abort. The 'git rebase --abort' command is designed specifically to revert the branch to its state before the rebase began. The other options are either invalid commands or potentially destructive actions that do not safely clean up the rebase state.
From lesson: Git Interview Questions
When should you use 'git cherry-pick'?
- When you want to permanently delete a range of commits.
- When you want to push specific commits to a new remote branch.
- When you want to apply a specific commit from one branch onto another branch.
- When you want to resolve merge conflicts automatically using the remote version.
Answer: When you want to apply a specific commit from one branch onto another branch.. Cherry-picking allows you to select specific commits from any branch and apply them to your current branch without merging the entire history. The other options describe actions performed by commands like 'rebase', 'push', or 'merge'.
From lesson: Git Interview Questions
What happens when you run 'git reset --soft HEAD~1'?
- It deletes the last commit and all changes made in that commit.
- It removes the last commit from the history, but keeps the changes in the staging area.
- It moves the branch pointer back, but keeps your working directory and staging area unchanged.
- It creates a new commit that reverts the changes introduced by the last commit.
Answer: It removes the last commit from the history, but keeps the changes in the staging area.. The '--soft' flag moves the HEAD pointer back by one commit while leaving the changes from that commit in your staging area. '--hard' would delete changes, and a revert command would create a new inverse commit.
From lesson: Git Interview Questions
Why is it considered best practice to fetch before pushing?
- It initializes the local repository with the latest configuration files.
- It ensures your local repository is aware of any remote changes, preventing non-fast-forward errors.
- It automatically merges the remote branch into your local branch to ensure they are identical.
- It is required by the Git protocol to verify the identity of the remote server.
Answer: It ensures your local repository is aware of any remote changes, preventing non-fast-forward errors.. Fetching syncs your remote tracking branches with the server. If the remote has new commits, pushing without having them locally results in a non-fast-forward error, which this practice avoids. The other options incorrectly describe automation or protocol requirements.
From lesson: Git Interview Questions

Git & GitHub quiz

Ten questions at a time, drawn from 100. Every answer is explained. Nothing is saved and no account is needed.

Question 1 of 10Score 0

If you modify a file in your Working Tree and run 'git commit', why does Git not include your changes in the commit?

All Git & GitHub quiz questions and answers

If you modify a file in your Working Tree and run 'git commit', why does Git not include your changes in the commit?

The file was not added to the Index.
The file is currently locked by the operating system.
The Working Tree is not part of the Git architecture.
Git requires you to push before committing locally.

Answer: The file was not added to the Index.. Git creates commits based solely on the current state of the Index, not the Working Tree. The other options are incorrect because the file being locked has no effect on Git's logic, the Working Tree is central to Git's architecture, and pushing is unrelated to the commit process.

From lesson: Git Architecture — Working Tree, Index, Repository

What is the primary function of the Index (staging area) in the Git architecture?

It stores a backup of every version of every file.
It acts as a buffer to prepare the exact snapshot for the next commit.
It synchronizes local changes with the remote server automatically.
It serves as the main database for storing history.

Answer: It acts as a buffer to prepare the exact snapshot for the next commit.. The Index allows the user to carefully craft a commit snapshot. Storing backups, syncing with remotes, and acting as a history database are roles of the repository object database, not the staging area.

From lesson: Git Architecture — Working Tree, Index, Repository

How does the 'git checkout' command impact the three areas of Git?

It updates the Repository and the Index simultaneously.
It only modifies files in the Index without changing the disk.
It updates the Working Tree and the Index to match a specific commit.
It forces the remote server to delete files in the Working Tree.

Answer: It updates the Working Tree and the Index to match a specific commit.. When checking out a branch or commit, Git overwrites the Index and the Working Tree to align with the state saved in the repository. The other options are wrong because 'git checkout' focuses on local state, not the remote, and it must affect the Working Tree to be useful.

From lesson: Git Architecture — Working Tree, Index, Repository

After performing a 'git add' on a file, how can you revert the changes in the Index without losing the changes in your Working Tree?

Use 'git reset HEAD <file>'.
Use 'git rm --cached <file>'.
Use 'git commit --amend'.
Use 'git clean'.

Answer: Use 'git rm --cached <file>'.. 'git rm --cached' removes the file from the Index while leaving the file on disk. 'git reset' is often used but 'git rm --cached' is the explicit command for this; 'git commit --amend' affects history, and 'git clean' removes untracked files.

From lesson: Git Architecture — Working Tree, Index, Repository

Which command best describes the movement of data from the Working Tree into the Repository?

git add followed by git commit
git push followed by git add
git commit followed by git push
git checkout followed by git stage

Answer: git add followed by git commit. Data moves from the Working Tree to the Index via 'git add', then from the Index to the Repository via 'git commit'. The other sequences are logically incorrect steps for moving data into the local history database.

From lesson: Git Architecture — Working Tree, Index, Repository

A developer modifies three files, runs 'git add' on two of them, and then runs 'git commit'. What happens?

All three modified files are committed.
Only the two added files are committed.
The commit fails because the third file is unstaged.
None of the files are committed until 'git push' is called.

Answer: Only the two added files are committed.. Git only commits files that are currently in the staging area. The third file remains modified but unstaged, so it is ignored. Option 0 is wrong because Git is explicit. Option 2 is wrong because an empty stage or partial stage is allowed. Option 3 is wrong because push is for remote synchronization, not local recording.

From lesson: init, clone, add, commit, status, log

What is the primary function of 'git status' in a daily workflow?

To sync the local repository with the remote server.
To display the history of commits made by all team members.
To check which files are staged, unstaged, or untracked.
To finalize and save the current state of all files permanently.

Answer: To check which files are staged, unstaged, or untracked.. Status shows the current workspace context. Option 0 is the job of fetch/pull. Option 1 is the job of log. Option 3 describes a commit, not a status check.

From lesson: init, clone, add, commit, status, log

Why would you run 'git log' after a series of commits?

To verify that your changes were successfully recorded in the repository history.
To see if any files have been deleted from the working directory.
To automatically resolve conflicts between local and remote code.
To initialize a new repository inside a subfolder.

Answer: To verify that your changes were successfully recorded in the repository history.. Log provides a chronological list of snapshots. Option 1 is tracked by status. Option 2 is a separate process. Option 3 describes git init.

From lesson: init, clone, add, commit, status, log

What does 'git clone' perform under the hood?

It only copies the latest version of the files to your machine.
It downloads the entire repository history and sets up a local repository.
It merges the remote repository into your existing local project.
It adds the remote server as a local branch.

Answer: It downloads the entire repository history and sets up a local repository.. Git is a distributed system, so cloning downloads the full history and metadata. Option 0 is incorrect because it copies the full history, not just the current files. Option 2 implies an existing repo, which clone doesn't expect. Option 3 is conceptually incorrect regarding how remotes work.

From lesson: init, clone, add, commit, status, log

If you are in a directory and run 'git init', what is the immediate effect?

All files in the directory are automatically committed.
A hidden '.git' directory is created to manage repository metadata.
The directory is automatically uploaded to a remote hosting service.
The directory is locked until you provide a commit message.

Answer: A hidden '.git' directory is created to manage repository metadata.. Init initializes the metadata structure. Option 0 is false as nothing is tracked yet. Option 2 is false as git init is purely local. Option 3 is false as Git does not lock directories.

From lesson: init, clone, add, commit, status, log

You have modified several files and added them to the staging area, but you decide you are not ready to commit them. Which command safely removes these files from the staging area while keeping your changes intact?

git reset --hard
git restore --staged <file>
git revert HEAD
git checkout -- <file>

Answer: git restore --staged <file>. git restore --staged removes files from the index without affecting working directory changes. Option 0 deletes all work, option 2 creates a new commit, and option 3 is for discarding local changes, not unstaging.

From lesson: Undoing Changes — reset, revert, restore

Your team is collaborating on a shared repository. You realize the last commit pushed to the server contains a bug. What is the safest way to undo this commit?

git reset --hard HEAD~1 and force push
git revert HEAD
git commit --amend
git rm -r .

Answer: git revert HEAD. git revert creates a new commit that negates the changes, which is safe for shared repos. Option 0 rewrites history, causing issues for others; option 2 only modifies the last commit locally; option 3 deletes files from the index.

From lesson: Undoing Changes — reset, revert, restore

You want to completely discard all local changes to tracked files and return your project to the exact state of the last commit. Which command is most appropriate?

git restore .
git reset --soft HEAD
git revert --no-commit HEAD
git stash pop

Answer: git restore .. git restore . discards working directory changes for tracked files. Option 1 moves the HEAD but keeps files staged; option 2 creates a revert commit; option 3 restores stashed changes, potentially adding more files.

From lesson: Undoing Changes — reset, revert, restore

If you perform a 'git reset --soft HEAD~1', what happens to the changes from the last commit?

They are deleted permanently from your computer.
They are moved to the working directory as modified files.
They are kept in the staging area (index) ready to be committed again.
They are automatically pushed back to the remote repository.

Answer: They are kept in the staging area (index) ready to be committed again.. --soft moves the HEAD back one commit while keeping all changes in the staging area. Option 0 describes --hard, option 1 describes --mixed, and option 3 is impossible as reset does not interact with remote pushes.

From lesson: Undoing Changes — reset, revert, restore

When is it appropriate to use 'git reset --hard'?

When you want to permanently abandon all uncommitted local work and sync to the HEAD commit.
When you need to undo a push to a public shared branch.
When you want to merge two branches together.
When you want to undo a commit but keep the changes in your staging area.

Answer: When you want to permanently abandon all uncommitted local work and sync to the HEAD commit.. --hard is used to reset the working directory and staging area to match the HEAD commit. It is dangerous because it deletes uncommitted work. Options 1, 2, and 3 involve operations (reverting, merging, soft reset) that serve different purposes.

From lesson: Undoing Changes — reset, revert, restore

You have modified a file but have not staged it yet. What happens when you run 'git stash'?

The file is ignored and remains in the working directory.
The file is saved to the stash stack and reverted in the working directory.
The command fails because the file is not staged.
The file is automatically committed to the current branch.

Answer: The file is saved to the stash stack and reverted in the working directory.. Correct: git stash saves all tracked modifications, regardless of staging status. Option 1 is wrong because tracked files are included. Option 3 is wrong because staging is not a requirement. Option 4 is wrong because stashing creates a separate storage entry, not a commit.

From lesson: Stashing Changes — git stash

Which command should you use to see a list of all your saved stashes?

git stash log
git stash view
git stash list
git stash show

Answer: git stash list. Correct: 'git stash list' displays the stack of stashes. 'Log' and 'view' are not valid git stash subcommands. 'Show' is used to see the contents of a specific stash, not the list of all entries.

From lesson: Stashing Changes — git stash

What is the primary difference between 'git stash pop' and 'git stash apply'?

Pop removes the stash after applying; apply keeps it in the stack.
Apply is for staged files; pop is for unstaged files.
Pop is faster than apply.
Apply creates a new commit; pop does not.

Answer: Pop removes the stash after applying; apply keeps it in the stack.. Correct: Pop is a destructive operation that clears the stash entry, whereas apply retains it. The other options describe false functional differences; both work on any modifications and neither creates permanent commits.

From lesson: Stashing Changes — git stash

You have a new, untracked file that you want to include in your stash. What is the correct syntax?

git stash --new
git stash -u
git stash --add-all
git stash --include-staged

Answer: git stash -u. Correct: The -u (or --include-untracked) flag tells Git to stash files not yet tracked. The other options are either invalid commands or incorrect flags for this specific task.

From lesson: Stashing Changes — git stash

If you are working on a feature, stash it, switch to another branch, and realize you need that code back, what is the best workflow?

Use git stash apply on the new branch.
Use git stash checkout to move the stash to the new branch.
Use git stash merge to combine the stash with the current branch.
Use git stash move to transfer the stash.

Answer: Use git stash apply on the new branch.. Correct: Git stashes are global to the repository, so you can apply a stash created on one branch to any other branch. Options 2, 3, and 4 reference commands that do not exist or do not perform that specific action.

From lesson: Stashing Changes — git stash

You have modified a file but are not ready to commit. You need to switch to a different branch to work on a hotfix. What is the most efficient workflow?

Delete the file and checkout the new branch
Use git stash to save changes, switch branches, then git stash pop when returning
Force switch branches using the -f flag
Manually copy the content of the file, switch branches, and paste the code back

Answer: Use git stash to save changes, switch branches, then git stash pop when returning. Stashing temporarily shelves your work, allowing a clean switch. Deleting files or force switching can lead to data loss or conflicts, and manual copying is prone to human error.

From lesson: Creating and Switching Branches

What is the primary purpose of 'git switch -c feature-x'?

It deletes the current branch and creates a new one
It moves all commits from the current branch to feature-x
It creates a new branch named 'feature-x' and immediately checks it out
It merges the current branch into 'feature-x'

Answer: It creates a new branch named 'feature-x' and immediately checks it out. The -c flag stands for 'create'. Option 1 is incorrect as it does not delete anything; option 2 implies an impossible atomic move of commits; option 4 describes merging, not switching.

From lesson: Creating and Switching Branches

If you are on 'main' and run 'git branch dev', what is the state of your repository?

You are now on the 'dev' branch
You are still on the 'main' branch, but 'dev' is created pointing to your current commit
The 'main' branch is deleted and replaced by 'dev'
Git automatically merges 'main' into 'dev'

Answer: You are still on the 'main' branch, but 'dev' is created pointing to your current commit. The 'git branch' command only creates a label. You remain on the original branch until you explicitly checkout or switch to the new one.

From lesson: Creating and Switching Branches

When is it appropriate to use 'git branch -D' (uppercase D)?

When you want to delete a branch that has not yet been merged into the current branch
When you want to delete the main branch
When you want to rename a branch permanently
When you want to merge two branches together

Answer: When you want to delete a branch that has not yet been merged into the current branch. The uppercase -D flag forces deletion, which is necessary if Git detects unmerged work that would be lost. Lowercase -d prevents accidental deletion of unmerged work.

From lesson: Creating and Switching Branches

Why is it recommended to branch off of a clean, up-to-date main branch before starting a new feature?

Because it is a requirement for the code to compile
To ensure the new feature is built on the most current stable code and minimize future merge conflicts
Because Git will automatically lock the main branch
To force other developers to switch to your new branch

Answer: To ensure the new feature is built on the most current stable code and minimize future merge conflicts. Starting from an outdated branch creates 'configuration drift'. Options 1, 3, and 4 are unrelated to Git's architectural functionality regarding branching.

From lesson: Creating and Switching Branches

What is the primary difference between a fast-forward merge and a three-way merge?

A fast-forward merge creates a new commit object, while a three-way merge does not.
A fast-forward merge simply moves the branch pointer forward, while a three-way merge creates a merge commit.
A fast-forward merge requires resolving conflicts, whereas a three-way merge avoids them.
A fast-forward merge only works on remote repositories, while a three-way merge is local.

Answer: A fast-forward merge simply moves the branch pointer forward, while a three-way merge creates a merge commit.. A fast-forward merge moves the pointer without creating a commit; a three-way merge creates a new 'merge commit' to tie histories together. Option 0 is backwards; option 2 is incorrect because both can have conflicts; option 3 is irrelevant to location.

From lesson: Merging — Fast-forward vs Three-way

When is a fast-forward merge impossible?

When the commit history has diverged.
When the repository has more than two branches.
When the file size of the changes is too large.
When the branch being merged is empty.

Answer: When the commit history has diverged.. If the main branch has moved forward since the feature branch started, the histories have diverged, making a simple move impossible. Other options do not prevent fast-forwarding.

From lesson: Merging — Fast-forward vs Three-way

If you perform a 'git merge' on a branch that has diverged, what does Git do by default?

It stops the process and throws an error.
It automatically rebases the feature branch.
It performs a three-way merge and creates a merge commit.
It forces a fast-forward by discarding remote changes.

Answer: It performs a three-way merge and creates a merge commit.. Git defaults to a three-way merge to integrate diverging lines of history into a merge commit. It does not rebase automatically, nor does it error out or discard changes.

From lesson: Merging — Fast-forward vs Three-way

Why might a team choose to use 'git merge --no-ff' even when a fast-forward is possible?

To increase the speed of the merge process.
To ensure all changes are automatically rebased.
To preserve the fact that a specific branch of work occurred.
To prevent conflicts from ever occurring.

Answer: To preserve the fact that a specific branch of work occurred.. --no-ff creates a merge commit, which visually preserves the grouping of commits related to a feature. It does not affect speed, rebasing, or conflict prevention.

From lesson: Merging — Fast-forward vs Three-way

Which command ensures that a merge only happens if it can be done as a fast-forward?

git merge --ff-only
git merge --no-commit
git merge --squash
git merge --strategy=ours

Answer: git merge --ff-only. --ff-only explicitly prevents Git from creating a merge commit if the history has diverged. The other options are for managing commits, squashing, or handling conflicts, not for enforcing linear history.

From lesson: Merging — Fast-forward vs Three-way

What is the primary structural difference between a git merge and a git rebase?

Merge creates a new commit that combines histories, while rebase rewrites commits to create a linear path.
Rebase creates a merge commit, while merge prevents the creation of any extra commits.
Merge deletes the original branch history, while rebase preserves it indefinitely.
Rebase is used for remote repositories, while merge is strictly for local usage.

Answer: Merge creates a new commit that combines histories, while rebase rewrites commits to create a linear path.. The first option is correct because merge produces a 'merge commit' linking two histories, while rebase moves the feature branch base to the latest main commit. Option 1 is backward; 2 is false as rebase is dangerous on shared branches; 3 is incorrect as both preserve history differently.

From lesson: Rebasing — Rebase vs Merge

When is it considered a 'best practice' to perform a rebase on your local feature branch?

Every time you want to pull the latest changes from the main branch to keep your feature branch current.
When you have finished a large project and want to hide all individual commits into one single commit.
Immediately after someone else has pushed changes to the same branch you are currently working on.
Whenever you want to delete your branch and move the code to the main branch history.

Answer: Every time you want to pull the latest changes from the main branch to keep your feature branch current.. Rebasing your local feature branch onto the updated main branch keeps your history clean and linear before merging. Option 1 is better handled by 'squash', 2 causes chaos for others, and 3 is not the purpose of rebasing.

From lesson: Rebasing — Rebase vs Merge

If you are in the middle of a rebase and encounter a merge conflict, which sequence of commands is correct to resolve it?

Edit files, git add, git commit.
Edit files, git add, git rebase --continue.
Edit files, git commit, git rebase --continue.
Edit files, git rebase --continue, git add.

Answer: Edit files, git add, git rebase --continue.. During a rebase, 'git commit' is replaced by 'git rebase --continue' to allow Git to resume the process. You must add the files first to mark them as resolved. Option 0 creates a separate commit, and 2/3 are syntactically incorrect for the rebase flow.

From lesson: Rebasing — Rebase vs Merge

Why is it dangerous to rebase a branch that is being used by multiple developers?

Because it makes the branch impossible to merge later.
Because rebase changes the commit hashes, creating a 'diverged' history for other users who base their work on the original commits.
Because the branch will automatically be deleted by the server.
Because Git requires a paid license to perform a rebase on shared branches.

Answer: Because rebase changes the commit hashes, creating a 'diverged' history for other users who base their work on the original commits.. Rebasing changes the underlying commit ID (hash), making local versions of that branch for others incompatible with the 'new' version. Option 0 is false; 2 is nonsense; 3 is false as Git is open source.

From lesson: Rebasing — Rebase vs Merge

Which scenario best justifies using 'git merge' instead of 'git rebase'?

When you want to maintain the exact history of when and how features were integrated into the project.
When you want to make your commit log look like a single straight line.
When you have a very large number of tiny, messy 'wip' commits that you want to hide.
When you are working completely alone on a repository.

Answer: When you want to maintain the exact history of when and how features were integrated into the project.. Merge is preferred for preserving the historical timeline of branches. Rebasing (Option 1) is specifically used for linear histories. Option 2 describes interactive squashing, and 3 is a valid use case for rebase, not merge.

From lesson: Rebasing — Rebase vs Merge

What is the primary effect of running 'git cherry-pick <commit-hash>'?

It moves the specified commit from one branch to another, deleting it from the original branch.
It applies the changes introduced by the specified commit as a new commit on the current branch.
It merges the entire branch containing the commit into the current branch.
It resets the current branch to match the state of the specified commit.

Answer: It applies the changes introduced by the specified commit as a new commit on the current branch.. Option 2 is correct because cherry-pick replays the changes of a single commit as a new object on your current head. Option 1 is wrong because it doesn't delete the original. Option 3 is wrong because it doesn't merge the history. Option 4 is wrong because it doesn't change the branch pointer to that commit.

From lesson: Cherry-picking Commits

If a cherry-pick results in a conflict, what is the best practice to finalize the process?

Run 'git reset --hard' and ignore the cherry-picked commit.
Use 'git revert' to undo the cherry-pick attempt.
Resolve the files manually, add them to the staging area, and run 'git cherry-pick --continue'.
Force push the branch to overwrite the conflicting files.

Answer: Resolve the files manually, add them to the staging area, and run 'git cherry-pick --continue'.. Option 3 is the standard Git workflow for resolving conflicts during a cherry-pick sequence. Option 1 loses work, Option 2 is unnecessary for an uncompleted pick, and Option 4 is dangerous and does not resolve the actual code conflict.

From lesson: Cherry-picking Commits

Why does a cherry-picked commit have a different SHA-1 hash than the original commit?

Because the commit timestamp and parent commit reference are different.
Because Git automatically encrypts cherry-picked commits differently.
Because the commit author is always changed to the person who ran the cherry-pick command.
Because Git renames commits to avoid collisions in the repository.

Answer: Because the commit timestamp and parent commit reference are different.. Option 1 is correct; since the parent and timestamp change, the commit identity changes. Option 2 is false as Git uses SHA-1 hashing, not encryption. Option 3 is incorrect as the author remains the same by default. Option 4 is incorrect; hashes are generated by content and metadata, not by a naming service.

From lesson: Cherry-picking Commits

When should you prefer a standard 'git merge' over 'git cherry-pick'?

When you want to bring in a single bug fix from a production branch.
When you need to copy a specific commit to your local branch without merging full feature histories.
When you want to integrate a long-running feature branch that contains multiple related commits.
When you want to keep the commit history linear without any merge commits.

Answer: When you want to integrate a long-running feature branch that contains multiple related commits.. Option 3 is correct because merging is designed for integrating entire workstreams. Option 1 and 2 are typical use cases for cherry-picking. Option 4 describes a reason to use rebase, not necessarily merge or cherry-pick.

From lesson: Cherry-picking Commits

What happens to the original commit after you cherry-pick it?

It is permanently moved to the new branch.
It is marked as 'cherry-picked' in the Git log metadata.
It remains completely unchanged in the original branch's history.
It is converted into a patch file and deleted from the repository.

Answer: It remains completely unchanged in the original branch's history.. Option 3 is correct; Git preserves the original history. Option 1 is wrong as 'move' implies deletion, which doesn't happen. Option 2 is false as Git logs do not add metadata to the original commit. Option 4 is wrong because the original commit persists in the history.

From lesson: Cherry-picking Commits

What is the primary purpose of the conflict markers (<<<<<<<, =======, >>>>>>>) that Git inserts into files?

To signify that the file is corrupt and must be deleted
To identify the specific sections of code that were modified by different branches
To inform the system which branch is currently the active HEAD
To provide a backup of the original file before the merge attempt

Answer: To identify the specific sections of code that were modified by different branches. These markers clearly demarcate the content from the HEAD (yours) and the branch being merged (theirs). Option 0 is wrong because the file is not corrupt. Option 2 is wrong because markers don't track the HEAD status. Option 3 is wrong because they do not act as backups.

From lesson: Conflict Resolution

After you have successfully edited the conflicted files to remove all markers, what is the next step you must perform?

Run 'git merge --continue'
Run 'git push' to update the remote server
Stage the resolved files using 'git add'
Create a new branch for the resolved code

Answer: Stage the resolved files using 'git add'. Git requires you to explicitly stage the resolved files to tell it that the conflict is handled. Option 0 is not a standard Git command. Option 1 is premature as you haven't finished the merge commit. Option 3 is unnecessary and creates redundant workflow complexity.

From lesson: Conflict Resolution

What happens if you resolve a conflict and commit it, but leave one of the marker symbols (e.g., '=======') inside the file?

Git automatically detects the symbol and removes it during the next push
The code will likely result in a syntax error when compiled or executed
Git will refuse to merge the branch entirely
The file will be treated as a binary file by Git

Answer: The code will likely result in a syntax error when compiled or executed. Git does not validate code syntax; it sees the marker as part of the text, which will cause issues in your source code. Option 0 is false as Git doesn't 'auto-clean' code. Option 2 is false as the merge is already committed. Option 3 is false as Git is agnostic to file types.

From lesson: Conflict Resolution

Why is 'git merge' often preferred over 'git rebase' when dealing with complex conflicts in a shared team branch?

Merge creates a record of the conflict resolution through a merge commit
Rebase is incapable of handling conflicts
Merge automatically fixes all logic errors during the resolution process
Rebase requires significantly more RAM on the local machine

Answer: Merge creates a record of the conflict resolution through a merge commit. Merge commits provide a clear point in history showing when and how branches joined. Option 1 is false because rebase handles conflicts fine. Option 2 is false because code logic is the developer's responsibility. Option 3 is irrelevant to Git's performance.

From lesson: Conflict Resolution

When you are in the middle of a conflict resolution process and realize you made a mistake, how do you safely revert back to the state before the merge?

Delete the local repository and clone it again
Run 'git reset --hard HEAD'
Run 'git merge --abort'
Modify the .git/config file to disable conflicts

Answer: Run 'git merge --abort'. The 'git merge --abort' command is the safe, intended way to stop the process and return to the pre-merge state. Option 0 is overkill and unnecessary. Option 1 would wipe all your recent local work. Option 3 is impossible as configuration cannot disable conflict detection.

From lesson: Conflict Resolution

What is the primary difference between 'git fetch' and 'git pull'?

Fetch updates the working directory, while pull only updates the hidden .git directory.
Fetch downloads remote data but does not modify your working branch; pull downloads and merges in one step.
Pull is a destructive command that deletes local commits, while fetch is safe.
There is no difference; they are aliases for the exact same process.

Answer: Fetch downloads remote data but does not modify your working branch; pull downloads and merges in one step.. Option 2 is correct because fetch updates remote-tracking branches without touching your current files. Option 1 is backward. Option 3 is false as pull is usually non-destructive to history. Option 4 is false as they have distinct mechanical behaviors.

From lesson: Remotes — push, pull, fetch

You try to push your changes, but Git says 'non-fast-forward'. What does this mean?

You have remote commits that you do not have locally.
You have too many files staged for the remote server to process.
Your local branch has diverged, and pushing would overwrite history.
The remote repository is currently offline or read-only.

Answer: Your local branch has diverged, and pushing would overwrite history.. Option 3 is correct because Git prevents pushes that result in lost commits on the server. Option 1 describes a pull requirement. Option 2 and 4 are unrelated to the fast-forward error.

From lesson: Remotes — push, pull, fetch

Why is 'git push -u origin <branch>' preferred when creating a new branch?

It forces the remote to accept the new branch even if there are conflicts.
It compresses the history to make the push faster.
It establishes a tracking relationship, allowing future 'git pull' commands without arguments.
It immediately creates a pull request on GitHub.

Answer: It establishes a tracking relationship, allowing future 'git pull' commands without arguments.. Option 3 is correct as '-u' sets the upstream branch. Option 1 is false (push does not resolve merge conflicts). Option 2 is a misunderstanding of push mechanics. Option 4 happens on GitHub, not via the git CLI.

From lesson: Remotes — push, pull, fetch

If you perform a 'git fetch', where are the changes stored before you decide to merge them?

In your staging area (index).
In your working directory as untracked files.
In remote-tracking branches like 'origin/main'.
They are held in a temporary stash.

Answer: In remote-tracking branches like 'origin/main'.. Option 3 is correct because fetch updates the pointers in your local .git folder representing the remote state. Options 1 and 2 are incorrect because the working directory/staging area remains untouched. Option 4 is incorrect as stash is a separate storage mechanism.

From lesson: Remotes — push, pull, fetch

What happens if you run 'git pull' while you have uncommitted changes in your working directory?

Git will automatically stash your changes, pull, and then restore them.
Git will refuse to pull if the incoming changes conflict with your local files to prevent data loss.
Git will overwrite your local changes with the remote version.
The pull will automatically create a new commit for your local changes.

Answer: Git will refuse to pull if the incoming changes conflict with your local files to prevent data loss.. Option 2 is correct; Git preserves local work by preventing pulls that would cause conflicts. Option 1 is incorrect (it does not stash automatically). Option 3 is incorrect as Git defaults to safety. Option 4 is incorrect as a pull cannot commit local files it doesn't know about.

From lesson: Remotes — push, pull, fetch

What is the primary function of setting an 'upstream' branch in Git?

To force the remote repository to copy the local file structure
To establish a link that allows Git to know which remote branch to interact with during pulls and pushes
To automatically merge the entire remote repository into the local directory
To prevent other contributors from pushing to the same remote branch

Answer: To establish a link that allows Git to know which remote branch to interact with during pulls and pushes. Setting the upstream creates a direct relationship between your local branch and a remote counterpart. Option 0 is incorrect because it's about syncing, not configuring. Option 2 describes merging, not tracking. Option 3 relates to permissions, not tracking.

From lesson: Tracking Branches

Which command successfully creates a local branch and sets its upstream to a specific remote branch simultaneously?

git branch --set-upstream-to origin/main
git checkout -b feature-branch origin/feature-branch
git remote add origin
git push origin feature-branch

Answer: git checkout -b feature-branch origin/feature-branch. Using 'git checkout -b' with a remote branch automatically sets up tracking. Option 0 is for existing branches. Option 2 is for adding a remote, not a branch. Option 3 pushes code but does not necessarily set the local branch to track the remote one unless -u is used.

From lesson: Tracking Branches

If you run 'git branch -vv', what information are you primarily investigating?

The list of all files changed in the last three commits
The current tracking status of your local branches relative to their remote counterparts
The list of all remote repositories configured in your project
The timestamp of the last successful push to GitHub

Answer: The current tracking status of your local branches relative to their remote counterparts. The '-vv' flag shows verbose branch information, specifically the tracking relationship. The other options are incorrect because they relate to logs, remote management, or commit history, not tracking status.

From lesson: Tracking Branches

When you see 'Your branch is ahead of 'origin/main' by 2 commits', what does this imply?

The remote repository has 2 new commits that you need to pull
You have 2 commits locally that have not been pushed to the tracked remote branch
There is a merge conflict involving 2 files in your current branch
Your local branch has deleted 2 files that exist on the remote

Answer: You have 2 commits locally that have not been pushed to the tracked remote branch. Being 'ahead' means your local history contains commits not present on the tracked remote. Option 0 describes being 'behind'. Option 2 and 3 describe entirely different Git states related to conflicts or file status.

From lesson: Tracking Branches

Why does Git sometimes prompt you to specify a remote and branch name during a pull?

Because the remote server is offline
Because the local branch lacks an upstream tracking relationship
Because you have not committed your local changes yet
Because you are not authenticated with your GitHub account

Answer: Because the local branch lacks an upstream tracking relationship. If no tracking is defined, Git doesn't know where to pull from. Options 0, 2, and 3 describe issues with connectivity, staging/committing, or authentication, none of which trigger the specific 'specify remote' request.

From lesson: Tracking Branches

When is it technically safe to use a standard 'git push --force'?

When you are the only person working on a feature branch
When you want to resolve a merge conflict quickly
When your teammate has updated the remote branch
When you have already pushed to the main branch

Answer: When you are the only person working on a feature branch. It is safe only on private feature branches where you are the sole contributor. Other options are wrong because they involve shared branches or ignoring potential data loss from others.

From lesson: Force Push — When and Why (carefully)

What is the primary benefit of using 'git push --force-with-lease' compared to 'git push --force'?

It makes the push faster by skipping integrity checks
It prevents overwriting remote work that you haven't fetched yet
It automatically merges your changes with the remote history
It creates a backup of the remote branch before overwriting

Answer: It prevents overwriting remote work that you haven't fetched yet. The 'lease' check verifies if the remote branch has moved since you last fetched it, preventing you from accidentally deleting commits pushed by others. Other options inaccurately describe the safety mechanism.

From lesson: Force Push — When and Why (carefully)

If 'git push' is rejected with a message about non-fast-forward updates, what is the safest professional workflow?

Immediately execute 'git push --force'
Delete the remote branch and re-upload
Fetch, rebase your changes on top of the remote, then push
Rename your local branch and try pushing again

Answer: Fetch, rebase your changes on top of the remote, then push. Rebasing integrates remote changes into your history correctly. The other options involve destructive actions or do not solve the actual divergence in commit history.

From lesson: Force Push — When and Why (carefully)

Why should you avoid force pushing on a shared repository branch?

Because it triggers an automated security audit
Because it makes the repository size grow significantly
Because it rewrites shared history and destroys other people's commit references
Because it prevents GitHub from tracking pull request comments

Answer: Because it rewrites shared history and destroys other people's commit references. Force pushing changes the commit hashes, effectively removing history that others depend on. The other options are either irrelevant or technically incorrect regarding Git functionality.

From lesson: Force Push — When and Why (carefully)

You have rewritten your local commit history using an interactive rebase. To update the remote feature branch, what is the best practice?

Use 'git push --force' only if you are certain no one else pulled the branch
Use 'git push' and accept that it will fail until a merge occurs
Use 'git push --force-with-lease' to safely overwrite your own prior commits
Create a brand new branch name to avoid conflicts

Answer: Use 'git push --force-with-lease' to safely overwrite your own prior commits. This approach is safe because it enforces that only your own previous commits are overwritten if no new remote activity has occurred. The other options either create unnecessary work or expose the developer to unsafe overwriting.

From lesson: Force Push — When and Why (carefully)

When a reviewer asks for changes, what is the best practice for updating your PR?

Delete the branch and open a completely new PR.
Push new commits to the same branch, which updates the existing PR.
Close the PR and ask the reviewer to manually edit your code.
Force push changes to the main branch to overwrite the previous history.

Answer: Push new commits to the same branch, which updates the existing PR.. Pushing new commits to the existing branch is the correct way to iterate on a PR. Deleting the branch wastes the PR's history; closing it is unnecessary; force pushing to main is destructive and dangerous.

From lesson: Pull Requests and Code Review

What is the primary benefit of keeping a pull request focused on a single task?

It hides mistakes by grouping them with correct code.
It forces the reviewer to focus only on stylistic issues.
It improves code quality by making the logic easier to audit and test.
It allows you to bypass the need for automated tests.

Answer: It improves code quality by making the logic easier to audit and test.. Smaller PRs are easier to audit for logic errors. Option 1 is unethical, option 2 is not the goal of a review, and option 4 is never a valid practice.

From lesson: Pull Requests and Code Review

If your PR has merge conflicts with the target branch, what is the recommended workflow to resolve them?

Merge the target branch into your feature branch and resolve conflicts locally.
Wait for the project maintainer to manually fix your conflicts.
Ignore the conflicts and hope the platform resolves them automatically.
Delete the files that are causing the merge conflicts.

Answer: Merge the target branch into your feature branch and resolve conflicts locally.. You must pull the latest changes into your branch to resolve conflicts, ensuring your code works with the current state. Maintainers should not fix your conflicts, conflicts aren't auto-fixed, and deleting files breaks functionality.

From lesson: Pull Requests and Code Review

Why is it important to provide a detailed description in your pull request?

To increase the character count for search engine indexing.
To explain the context, the rationale, and how to verify the changes.
To prevent other developers from understanding your code.
Because it is required to automatically merge the code without reviews.

Answer: To explain the context, the rationale, and how to verify the changes.. Documentation helps reviewers understand intent, which is vital for effective code reviews. Other options are incorrect as they either hinder collaboration or provide false justifications.

From lesson: Pull Requests and Code Review

What should you do if you disagree with a reviewer's feedback?

Ignore the feedback and merge the PR immediately.
Report the reviewer to the repository owner.
Start a respectful, objective discussion to explain your reasoning or clarify the approach.
Immediately accept the feedback even if you know it introduces a bug.

Answer: Start a respectful, objective discussion to explain your reasoning or clarify the approach.. Code review is a collaborative process; discussion is expected when perspectives differ. Ignoring feedback or mindlessly accepting it is poor practice, and reporting a reviewer for feedback is unprofessional.

From lesson: Pull Requests and Code Review

When defining a workflow, why is it standard practice to place the 'actions/checkout' step before any build or test steps?

To verify that the runner has an active internet connection to GitHub.
To fetch the repository's source code so the runner can interact with the files.
To automatically authenticate the user against the GitHub API.
To set the working directory to the root of the project by default.

Answer: To fetch the repository's source code so the runner can interact with the files.. The correct answer is fetching the source code because runners start in an empty environment. Option 0 is wrong because runners don't need to check connection state. Option 2 is wrong because the default token is handled by the runner environment, not the checkout action. Option 3 is wrong because checkout does not define the working directory path.

From lesson: GitHub Actions — CI/CD Basics

What happens if a step in a GitHub Actions job fails, and 'continue-on-error' is set to false (default)?

The subsequent steps in that job will skip, and the job status will be marked as failed.
The workflow pauses until the user manually restarts the specific step.
The job ignores the error and proceeds to the next step, but reports a warning.
The runner attempts to re-execute the step up to three times automatically.

Answer: The subsequent steps in that job will skip, and the job status will be marked as failed.. The correct answer is that subsequent steps skip and the job fails, halting the pipeline. Option 1 is wrong because it does not pause automatically. Option 2 describes the 'continue-on-error' behavior. Option 3 is wrong because no automatic retry logic is built into the standard step execution.

From lesson: GitHub Actions — CI/CD Basics

Which of the following is the most secure way to handle a database password in your GitHub Actions workflow?

Include the password as a plain text string in the YAML file.
Store the password in a GitHub Environment Secret and call it using ${{ secrets.DB_PASS }}.
Export the password as a shell variable in an 'echo' command within the 'run' block.
Commit an encrypted '.env' file to the repository and decrypt it at runtime.

Answer: Store the password in a GitHub Environment Secret and call it using ${{ secrets.DB_PASS }}.. The correct answer is using GitHub Secrets. Option 0 exposes the password to everyone. Option 2 is insecure because 'echo' commands can be logged. Option 3 is a security risk if the decryption key is not managed correctly; Secrets are the intended native solution.

From lesson: GitHub Actions — CI/CD Basics

If you want a workflow to run only when a Pull Request is opened, which event configuration should you use?

on: push
on: pull_request: types: [opened]
on: workflow_run: types: [created]
on: repository_dispatch

Answer: on: pull_request: types: [opened]. The correct answer is 'pull_request' with the 'opened' type filter. Option 0 triggers on direct commits, not PR creation. Option 2 is for workflow orchestration. Option 3 is for triggering workflows via API calls, not PR events.

From lesson: GitHub Actions — CI/CD Basics

What is the primary benefit of using a 'matrix' strategy in a GitHub Actions job?

It allows you to store multiple passwords in a single secret.
It creates multiple instances of a job to test across different OS versions or configurations.
It compresses all job logs into a single summary file.
It allows the workflow to use multiple different runner platforms at the exact same time inside one step.

Answer: It creates multiple instances of a job to test across different OS versions or configurations.. The correct answer is running jobs across multiple configurations (e.g., Ubuntu, macOS, Windows). Option 0 is incorrect as secrets are simple key-value pairs. Option 2 is wrong because logs are kept separate. Option 3 is wrong because a single step can only run on one platform at a time.

From lesson: GitHub Actions — CI/CD Basics

What is the primary security benefit of requiring 'Signed commits' in branch protection rules?

It prevents developers from pushing code that lacks a clear explanation.
It verifies the author's identity, ensuring commits originate from a trusted, verified source.
It automatically scans for security vulnerabilities in the source code.
It forces the system to perform a local build before allowing the merge.

Answer: It verifies the author's identity, ensuring commits originate from a trusted, verified source.. Signed commits verify the identity of the author via GPG keys. Option 0 describes commit messages, 2 describes security scanning tools, and 3 refers to status checks.

From lesson: Branch Protection Rules

If you want to ensure that code changes are peer-reviewed before being merged, which rule is the most effective?

Require status checks to pass before merging.
Restrict who can push to matching branches.
Require pull requests before merging.
Lock branch settings.

Answer: Require pull requests before merging.. Requiring pull requests mandates a review process. Option 0 checks for build quality, 1 limits push permissions (but doesn't enforce review), and 3 is a general settings lock.

From lesson: Branch Protection Rules

What happens when 'Require branches to be up to date before merging' is enabled?

The branch must contain all the latest security patches from GitHub.
The pull request must be merged before the local branch can be deleted.
The branch must be tested against the latest version of the base branch before the merge button becomes active.
The merge button is disabled until the developer submits a second pull request.

Answer: The branch must be tested against the latest version of the base branch before the merge button becomes active.. This rule ensures the feature branch has been reconciled with the target branch's latest state. The other options describe incorrect workflows or unrelated tasks.

From lesson: Branch Protection Rules

Why would a team choose to enable 'Dismiss stale pull request approvals when new commits are pushed'?

To force reviewers to re-evaluate code changes that may have fundamentally altered the logic of the PR.
To save space on GitHub servers by clearing out old review comments.
To increase the speed of the CI pipeline by ignoring previous test results.
To prevent developers from making unnecessary small commits to the PR.

Answer: To force reviewers to re-evaluate code changes that may have fundamentally altered the logic of the PR.. New commits might invalidate previous logic reviews. Option 1 is about storage, 2 is about performance, and 3 is a behavioral restriction not controlled by this setting.

From lesson: Branch Protection Rules

A developer cannot push to a branch despite having write access to the repository. What is the most likely cause?

The repository has reached its storage limit.
The branch is protected, and they lack the specific 'bypass' or 'push' permissions defined in the rules.
The developer's local Git configuration is set to 'read-only' mode.
The repository owner has deleted the branch remotely.

Answer: The branch is protected, and they lack the specific 'bypass' or 'push' permissions defined in the rules.. Branch protection rules override general repo permissions. Option 0 is rare, 2 is not a standard Git setting, and 3 would manifest as a different error entirely.

From lesson: Branch Protection Rules

When you want to automatically close an issue via a pull request, what is the best practice?

Mention the issue number in the PR description using a keyword like 'closes'.
Delete the issue after you merge the pull request.
Manually close the issue in the UI after the merge.
Add a comment to the issue with the link to your code.

Answer: Mention the issue number in the PR description using a keyword like 'closes'.. Using 'closes #number' in the PR description allows GitHub to link and close the issue automatically upon merging. Manually closing or deleting is inefficient and misses the automation; commenting a link does not trigger status updates.

From lesson: GitHub Issues and Projects

Which of the following is the primary purpose of a GitHub Project board?

Storing the raw source code of the repository.
Visualizing the status and flow of work items.
Hosting documentation files for the project.
Managing user permissions and access levels.

Answer: Visualizing the status and flow of work items.. Project boards are for task management and workflow visualization. Storing code is for the repo, hosting documentation is for Wikis or Markdown files, and permissions are handled in repository settings.

From lesson: GitHub Issues and Projects

Why should you use Labels on GitHub Issues?

To permanently prevent other users from commenting.
To categorize issues by type, priority, or status for easier filtering.
To increase the search engine optimization of your repository.
To assign multiple developers to a task simultaneously.

Answer: To categorize issues by type, priority, or status for easier filtering.. Labels are the standard way to organize and filter issues. They do not restrict comments, affect SEO, or handle assignments, which are handled by the 'Assignees' field.

From lesson: GitHub Issues and Projects

If an issue is open, but you are waiting for more information from the reporter, what is the recommended workflow?

Close the issue immediately to keep the board clean.
Create a new repository to house the conversation.
Use a label like 'needs-info' and keep the issue open to track the request.
Ignore the issue until the user submits a new one.

Answer: Use a label like 'needs-info' and keep the issue open to track the request.. Labels like 'needs-info' help maintain transparency. Closing it kills the tracking, a new repo is overkill, and ignoring it prevents the issue from being resolved properly.

From lesson: GitHub Issues and Projects

What happens to a card in a GitHub Project when it is linked to a Pull Request that gets merged?

The card is automatically deleted from the board.
The card status can be configured to move automatically to a 'Done' column.
The project board will lock all other cards from being moved.
The pull request is automatically reverted.

Answer: The card status can be configured to move automatically to a 'Done' column.. GitHub Projects support automation workflows that trigger state changes based on PR status, such as moving to 'Done'. The card is not deleted, locking is not a feature, and it does not revert code.

From lesson: GitHub Issues and Projects

Which branch is the primary source of truth for the project's history in Gitflow?

feature
develop
main
hotfix

Answer: main. Main represents the production-ready state. Develop is for integration, feature is for individual tasks, and hotfix is for urgent patches; none of these should be considered the permanent record of production deployments like main.

From lesson: Gitflow Workflow

Why is it important to merge hotfix branches into both main and develop?

To satisfy Git status requirements.
To ensure the production fix is integrated into the next development cycle.
Because Gitflow requires all branches to be merged twice.
To trigger an automatic deployment to both environments.

Answer: To ensure the production fix is integrated into the next development cycle.. Merging into main fixes the production issue, while merging into develop ensures the fix persists in future releases. Merging only to one creates a regression risk where the fix is lost in the next development cycle.

From lesson: Gitflow Workflow

What is the recommended workflow for completing a feature branch in Gitflow?

Merge it directly into main.
Merge it into develop, then delete the feature branch.
Merge it into a release branch for final testing.
Rebase it onto main before merging.

Answer: Merge it into develop, then delete the feature branch.. Features are intended to be integrated into develop. Merging to main is premature; merge to release is non-standard; and rebasing is not a required step for feature completion in the basic Gitflow model.

From lesson: Gitflow Workflow

When is it appropriate to create a release branch?

When a new feature is started.
When the develop branch has reached a state of feature completeness for the next release.
When a critical bug is discovered in production.
Every time a developer pushes code to the remote repository.

Answer: When the develop branch has reached a state of feature completeness for the next release.. Release branches are for final prep like documentation and minor bug fixes before a release. Feature start is for features, hotfix is for production bugs, and pushing code is a daily activity, not a release trigger.

From lesson: Gitflow Workflow

In Gitflow, what is the purpose of the feature branch naming convention?

To inform GitHub of the priority level.
To allow the Git client to automatically merge the code.
To maintain organization and identify the purpose of the work-in-progress.
To satisfy the requirements for automatic deployment.

Answer: To maintain organization and identify the purpose of the work-in-progress.. Naming conventions like 'feature/' help distinguish work branches from support branches. GitHub doesn't prioritize based on names, Git clients don't auto-merge based on labels, and deployment tools do not rely on branch names for logic.

From lesson: Gitflow Workflow

What is the primary goal of Trunk-Based Development in a Git workflow?

To enforce a strict hierarchy of repository administrators
To minimize the duration of branch divergence from the main line
To prevent developers from using the command line
To ensure every single commit is deployed to production instantly

Answer: To minimize the duration of branch divergence from the main line. Trunk-based development focuses on merging small, frequent updates into the main branch to avoid long-lived branches. Other options describe bureaucratic controls, platform limitations, or CI/CD deployment strategies rather than the core Git branching philosophy.

From lesson: Trunk-Based Development

When a developer is working on a feature in a short-lived branch, what should they do before merging into main?

Delete the remote repository and recreate it
Rebase their branch against the current main branch to incorporate upstream changes
Create a new branch for every file they modified
Force push their local branch to main to ensure it overwrites history

Answer: Rebase their branch against the current main branch to incorporate upstream changes. Rebasing ensures the local branch is up-to-date with the main line, avoiding conflicts during the merge. Forcing pushes or recreating repositories breaks history and collaboration, while multiple branches for one feature defeat the purpose of trunk-based flow.

From lesson: Trunk-Based Development

How does Trunk-Based Development change the role of the Pull Request (PR) compared to long-lived branching strategies?

PRs are eliminated and replaced by physical mail
PRs are used only for final release candidates
PRs become smaller and shorter-lived to facilitate rapid code review
PRs are restricted to senior developers only

Answer: PRs become smaller and shorter-lived to facilitate rapid code review. In trunk-based development, the goal is to keep PRs small so they can be reviewed and merged quickly. Eliminating them or limiting them by seniority/release phase contradicts the goal of continuous integration.

From lesson: Trunk-Based Development

Why are 'long-lived' feature branches considered detrimental in a team environment?

They are incompatible with the Git graphical interface
They make it difficult to identify integration errors until late in the development cycle
They use too much local disk space on the developer's machine
They force the use of submodules

Answer: They make it difficult to identify integration errors until late in the development cycle. The longer a branch exists, the more it drifts from the main code base, leading to 'integration hell.' The other options are misconceptions about Git's technical constraints or features.

From lesson: Trunk-Based Development

What is the recommended approach for handling unfinished features in a trunk-based environment?

Commit only to a hidden local file not tracked by Git
Merge the unfinished code and hope it compiles
Use feature flags to merge code into main while keeping the functionality disabled
Keep the branch open for months until the feature is perfect

Answer: Use feature flags to merge code into main while keeping the functionality disabled. Feature flags allow teams to integrate code into main continuously without exposing unfinished features to users. Merging broken code is bad practice, and keeping branches open defeats the trunk-based philosophy.

From lesson: Trunk-Based Development

Which of the following commit subjects follows the Conventional Commits specification perfectly?

feat: Add user authentication
FEAT: add user authentication
Add user authentication
feat(auth) add user authentication

Answer: feat: Add user authentication. The first option uses the correct lowercase type and a colon-space separator. The second is wrong because the type must be lowercase. The third lacks the type/scope structure. The fourth is wrong because it misses the colon after the scope.

From lesson: Conventional Commits

If you modify a function's return signature causing downstream dependencies to break, how should you denote this?

Include 'major:' in the subject line
Add 'BREAKING CHANGE:' to the footer of the commit message
Use the type 'breaking'
Prefix the commit subject with '!' or 'major'

Answer: Add 'BREAKING CHANGE:' to the footer of the commit message. The specification requires a 'BREAKING CHANGE:' prefix in the footer (or a '!' before the colon in the header). Option 0 is wrong because 'major' is not a standard tag. Option 2 is wrong because 'breaking' is not a standard type. Option 3 is non-standard.

From lesson: Conventional Commits

What is the primary purpose of the 'scope' in a Conventional Commit?

To define which programming language is being used
To specify the sub-component or module of the repository affected
To list all the files modified in the commit
To describe the priority level of the commit

Answer: To specify the sub-component or module of the repository affected. The scope identifies the specific part of the codebase changed (e.g., 'fix(ui): ...'). Option 0 is wrong as the language is project-wide. Option 2 is wrong because file lists are handled by git status. Option 3 is irrelevant to the scope.

From lesson: Conventional Commits

Why is it important to follow Conventional Commits when using GitHub features like Releases?

It makes the commit history look professional
It allows GitHub to automatically generate changelogs and determine semantic versions
It prevents merge conflicts in the main branch
It enforces the use of Pull Requests

Answer: It allows GitHub to automatically generate changelogs and determine semantic versions. Automated tools parse the commit messages to group changes by type ('feat', 'fix') and determine if a patch, minor, or major version update is needed. The other options are either side effects or unrelated to the specification.

From lesson: Conventional Commits

When should you use the 'chore' type in a commit message?

When fixing a bug that users might notice
When adding a new feature to the product
When performing routine tasks like updating dependencies or build scripts
When documenting code changes

Answer: When performing routine tasks like updating dependencies or build scripts. 'chore' is for maintenance tasks that don't change the source code or affect the end-user. 'feat' is for new features. 'fix' is for bug fixes. Documentation changes should usually use the 'docs' type.

From lesson: Conventional Commits

What is the primary difference between 'git merge' and 'git rebase'?

Merge creates a new commit, while rebase rewrites the commit history.
Rebase preserves original commit timestamps, while merge changes them.
Merge is for local repositories, while rebase is for remote repositories.
Rebase creates a merge commit, while merge maintains a linear history.

Answer: Merge creates a new commit, while rebase rewrites the commit history.. Merge creates a dedicated merge commit, preserving historical structure. Rebase moves or combines a sequence of commits to a new base, creating a linear project history. The other options describe incorrect functional roles or behavior.

From lesson: Git Interview Questions

If you are in the middle of a complex rebase and encounter conflicts, what is the best way to safely abort the process and return to your original state?

git rebase --hard
git rebase --abort
git reset --hard HEAD
git checkout main

Answer: git rebase --abort. The 'git rebase --abort' command is designed specifically to revert the branch to its state before the rebase began. The other options are either invalid commands or potentially destructive actions that do not safely clean up the rebase state.

From lesson: Git Interview Questions

When should you use 'git cherry-pick'?

When you want to permanently delete a range of commits.
When you want to push specific commits to a new remote branch.
When you want to apply a specific commit from one branch onto another branch.
When you want to resolve merge conflicts automatically using the remote version.

Answer: When you want to apply a specific commit from one branch onto another branch.. Cherry-picking allows you to select specific commits from any branch and apply them to your current branch without merging the entire history. The other options describe actions performed by commands like 'rebase', 'push', or 'merge'.

From lesson: Git Interview Questions

What happens when you run 'git reset --soft HEAD~1'?

It deletes the last commit and all changes made in that commit.
It removes the last commit from the history, but keeps the changes in the staging area.
It moves the branch pointer back, but keeps your working directory and staging area unchanged.
It creates a new commit that reverts the changes introduced by the last commit.

Answer: It removes the last commit from the history, but keeps the changes in the staging area.. The '--soft' flag moves the HEAD pointer back by one commit while leaving the changes from that commit in your staging area. '--hard' would delete changes, and a revert command would create a new inverse commit.

From lesson: Git Interview Questions

Why is it considered best practice to fetch before pushing?

It initializes the local repository with the latest configuration files.
It ensures your local repository is aware of any remote changes, preventing non-fast-forward errors.
It automatically merges the remote branch into your local branch to ensure they are identical.
It is required by the Git protocol to verify the identity of the remote server.

Answer: It ensures your local repository is aware of any remote changes, preventing non-fast-forward errors.. Fetching syncs your remote tracking branches with the server. If the remote has new commits, pushing without having them locally results in a non-fast-forward error, which this practice avoids. The other options incorrectly describe automation or protocol requirements.

From lesson: Git Interview Questions