📖 6 min read · By ['[“DungNQ49”]']

Review Questions - Git Collaboration Workflow#

Test your understanding of Git concepts and workflows with these review questions.

Multiple Choice#

1. What is the purpose of the staging area in Git?#

  • A) To store backup copies of files

  • B) To select which changes to include in the next commit

  • C) To merge branches automatically

  • D) To resolve conflicts

Answer

B) To select which changes to include in the next commit

The staging area (index) allows you to selectively choose which changes go into your next commit, giving you fine-grained control over your commit history.

2. In Gitflow, which branch should hotfixes be merged into?#

  • A) Only main

  • B) Only develop

  • C) Both main and develop

  • D) Only the feature branch

Answer

C) Both main and develop

Hotfixes must be merged into both branches to ensure the fix is deployed to production (main) and also included in ongoing development (develop).

3. What does the --no-ff flag do when merging?#

  • A) Skips conflict resolution

  • B) Forces a merge commit even if fast-forward is possible

  • C) Deletes the source branch after merge

  • D) Merges without fetching remote changes

Answer

B) Forces a merge commit even if fast-forward is possible

The --no-ff flag creates a merge commit that preserves the history of the feature branch, making it easier to see when features were integrated.

4. Which conventional commit type indicates a breaking change?#

  • A) break:

  • B) feat!:

  • C) major:

  • D) breaking:

Answer

B) feat!:

The exclamation mark (!) after the type indicates a breaking change. You can also use a BREAKING CHANGE: footer in the commit body.

5. What command shows the difference between staged and unstaged changes?#

  • A) git status

  • B) git log

  • C) git diff

  • D) git show

Answer

C) git diff

  • git diff shows unstaged changes

  • git diff --staged shows staged changes

  • git diff HEAD shows all changes since last commit

Scenario Questions#

6. Feature Branch Conflict#

You’re working on feature/payment and need to merge it to main. However, a teammate has already merged changes to main that conflict with your code.

What steps should you take?

Answer

  1. Fetch latest changes: git fetch origin

  2. Rebase or merge main into your branch:

    git checkout feature/payment
git rebase main  # or git merge main

  3. Resolve conflicts in each file (remove conflict markers)

  4. Continue the rebase: git rebase --continue (or commit if merging)

  5. Test your code to ensure the merge didn’t break anything

  6. Push and create PR: git push origin feature/payment

7. Emergency Hotfix#

Production is down due to a critical bug in version 2.1.0. You need to deploy a fix immediately, but the develop branch has incomplete features.

Which workflow should you use?

Answer

Use the Hotfix workflow:

  1. Create hotfix branch from main:

    git checkout -b hotfix/2.1.1 main

  2. Fix the bug and commit:

    git commit -m "fix: Resolve critical production issue"

  3. Bump version and merge to main:

    git checkout main
git merge --no-ff hotfix/2.1.1
git tag -a v2.1.1 -m "Hotfix release"

  4. Merge back to develop:

    git checkout develop
git merge --no-ff hotfix/2.1.1

  5. Delete hotfix branch and deploy

8. Messy Commit History#

You have 5 commits with messages like “wip”, “fix typo”, “more changes”, “oops”, and “done”. Your team requires clean commit history before merging PRs.

How do you clean this up?

Answer

Use interactive rebase to squash commits:

git rebase -i HEAD~5

In the editor, change all but the first pick to squash:

pick abc1234 wip
squash def5678 fix typo
squash ghi9012 more changes
squash jkl3456 oops
squash mno7890 done

Then write a proper commit message:

feat: Add payment processing module

- Implement payment gateway integration
- Add validation for card details
- Handle error responses

Command Identification#

9. Match the command to its purpose:#

Command

Purpose

git stash

?

git cherry-pick <sha>

?

git reset --hard HEAD~1

?

git reflog

?
Answer

Command

Purpose

git stash

Temporarily save uncommitted changes

git cherry-pick <sha>

Apply a specific commit to current branch

git reset --hard HEAD~1

Discard the last commit and its changes

git reflog

View history of all Git operations

10. What commands would you use to:#

  1. Create a new branch and switch to it

  2. See all branches (local and remote)

  3. Delete a merged branch

  4. Rename the current branch

Answer 
# 1. Create and switch to new branch
git checkout -b new-branch
# or
git switch -c new-branch

# 2. See all branches
git branch -a

# 3. Delete a merged branch
git branch -d branch-name

# 4. Rename current branch
git branch -m new-name

Short Answer#

11. Explain the difference between git merge and git rebase#

Answer

Git Merge:

  • Creates a merge commit combining two branches

  • Preserves complete history of both branches

  • Non-destructive (doesn’t rewrite history)

  • Results in a non-linear history

Git Rebase:

  • Moves commits to begin on top of another branch

  • Creates a linear, cleaner history

  • Rewrites commit history (changes SHAs)

  • Should not be used on shared/public branches

When to use each:

  • Merge: For merging feature branches to main, preserving context

  • Rebase: For updating feature branches with latest main changes, cleaning up local commits

12. What makes a good Pull Request?#

Answer

A good Pull Request should have:

  1. Descriptive title summarizing the change

  2. Clear description explaining what, why, and how

  3. Small, focused scope (ideally < 400 lines)

  4. Passing CI/CD checks

  5. Self-review completed before requesting review

  6. Linked issues using keywords like “Closes #123”

  7. Screenshots/recordings for UI changes

  8. No merge conflicts with target branch

  9. Proper testing documented or included

13. Why should you use Conventional Commits?#

Answer

Benefits of Conventional Commits:

  1. Automatic changelog generation - Tools can parse commits to create release notes

  2. Semantic versioning - Commit types determine version bumps:

    • fix → PATCH

    • feat → MINOR

    • BREAKING CHANGE → MAJOR

  3. Clear communication - Team members understand changes at a glance

  4. Better searchability - Easy to find specific types of changes

  5. CI/CD automation - Trigger different workflows based on commit type

Self-Assessment Checklist#

Rate your confidence (1-5) on each skill:

Skill

Confidence

Creating and switching branches

⬜

Staging and committing changes

⬜

Resolving merge conflicts

⬜

Using Gitflow workflow

⬜

Writing conventional commits

⬜

Interactive rebasing

⬜

Creating effective PRs

⬜

Reviewing others’ code

⬜

Scoring:

  • 35-40: Expert level - ready to lead Git workflows

  • 25-34: Proficient - comfortable with daily Git usage

  • 15-24: Intermediate - practice more complex scenarios

  • Below 15: Beginner - review documentation and redo exercises