Git & Version Control test (Beginner)

Sample questions

5 sample questions from the Git & Version Control test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. What is the correct process to resolve a merge or rebase conflict in Git?

   1. Run 'git merge --abort' and then 'git rebase --continue'.
   2. Edit the file, remove the conflict markers, run 'git add file', and then 'git commit' or 'git rebase --continue'.
   3. Ignore the conflict markers and run 'git commit --amend'.
   4. Run 'git checkout --ours file' and then 'git commit'.

   Answer: B. Edit the file, remove the conflict markers, run 'git add file', and then 'git commit' or 'git rebase --continue'.

   When resolving a merge or rebase conflict, the correct process involves editing the file to resolve the conflict, removing the conflict markers, staging the resolved file with 'git add', and then committing or continuing the rebase. Other options may be incorrect because they may not fully address the resolution process or may involve incorrect commands.

2. Which statement correctly describes the relationship between the Git reflog and the standard `git log`?

   1. The Git reflog only tracks changes to the working directory, not the index or HEAD.
   2. The Git reflog retains information about changes to the HEAD and staging area for a longer period than the standard log.
   3. The Git reflog is automatically cleared after a certain period, unlike the standard log.
   4. The Git reflog and standard log have identical retention policies and data storage.

   Answer: B. The Git reflog retains information about changes to the HEAD and staging area for a longer period than the standard log.

   The Git reflog is a log of all changes to the HEAD and staging area, making it useful for recovery after operations like resets or reverts. In contrast, the standard `git log` only shows the history of commits and does not track changes to the HEAD or index. Therefore, the reflog retains more information for a longer period, which is critical for recovery purposes.

3. Which Git command is used to create a new branch that tracks a remote branch, ensuring proper upstream configuration?

   1. git checkout -b
   2. git branch --track
   3. git remote add
   4. git pull --rebase

   Answer: B. git branch --track

   The `git branch --track` command is used to create a new branch that tracks a remote branch. This setup ensures that Git knows which remote branch to push to and pull from, improving performance and reducing ambiguity in branch management.

4. What is the purpose of the staging area (or index) in Git?

   1. The staging area is used to store committed history and is accessed through the repository.
   2. The staging area is the same as the working directory and contains the actual files on the disk.
   3. The staging area is a read-only area that cannot be modified by developers.
   4. The staging area (or index) is a temporary holding area for changes before they are committed.

   Answer: D. The staging area (or index) is a temporary holding area for changes before they are committed.

   The staging area (or index) is a temporary holding area for changes before they are committed. It allows developers to selectively choose which changes to include in the next commit. This is different from the working directory, which contains the actual files on the disk, and the repository, which contains the committed history.

5. What is the correct description of the rebase workflow in Git?

   1. Rebase is a fast-forward merge that moves the branch pointer without creating a new commit.
   2. Rebase creates a merge commit with two parents, combining the histories of two branches.
   3. Rebase is a command that automatically resolves conflicts and creates a new branch with merged changes.
   4. Rebase replays your commits on top of another base, creating new commits with new hashes and a linear history.

   Answer: D. Rebase replays your commits on top of another base, creating new commits with new hashes and a linear history.

   Rebase is a process where your commits are replayed on top of another base, resulting in new commits with new hashes and a linear history. This is different from merge, which combines branches and creates a merge commit. Rebase is useful for maintaining a clean, linear history, but it should not be used on shared branches because it rewrites commit history.