Trunk-based development in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main goal of trunk-based development?

Choose the best description of the main goal of trunk-based development in Git workflows.

A To keep all developers working on a single shared branch to avoid long-lived feature branches.

B To create multiple long-lived branches for each feature to isolate development.

C To merge code only once a month to reduce integration conflicts.

D To use forks instead of branches for all development work.

💡 Hint

Think about how trunk-based development helps reduce integration problems.

Trunk-based development encourages developers to work on a single shared branch (usually 'main' or 'trunk') to integrate changes frequently. This reduces merge conflicts and keeps the codebase stable.

💻 Command Output

intermediate

What is the output of this Git command sequence?

Given the following commands executed in order, what will be the output of the final git log --oneline?

Git

git checkout -b feature
# make some commits
# commit A
# commit B
git checkout main
git merge feature --no-ff
git log --oneline --first-parent -3

A Shows an error because the feature branch was not pushed.

B Shows only the commits from the feature branch before merging.

C Shows the last 3 commits on main including the merge commit.

D Shows the last 3 commits from the feature branch only.

💡 Hint

Consider what --first-parent does in git log.

The --first-parent option shows commits only from the main branch's history, including the merge commit. After merging feature into main with --no-ff, the merge commit appears on main.

🔀 Workflow

advanced

Identify the correct sequence for a trunk-based development workflow

Which option shows the correct sequence of steps for a developer using trunk-based development?

A Commit directly to trunk without any branching or review.

B Create a short-lived branch, commit changes, merge back to trunk quickly, delete branch.

C Create a long-lived feature branch, commit changes over weeks, merge to trunk after completion.

D Fork the repository, commit changes, and never merge back to trunk.

💡 Hint

Think about how trunk-based development handles branches and integration speed.

Trunk-based development encourages short-lived branches that are merged back quickly to keep the trunk updated and reduce integration conflicts.

❓ Troubleshoot

advanced

Why might frequent merges in trunk-based development cause conflicts?

In trunk-based development, developers merge frequently to the trunk. What is a common cause of merge conflicts in this workflow?

A Using long-lived branches that never merge back.

B Merging only after all features are complete.

C Not committing any changes before merging.

D Multiple developers editing the same lines of code simultaneously.

💡 Hint

Think about what happens when two people change the same part of a file.

Merge conflicts happen when multiple developers edit the same lines of code and try to merge their changes. Frequent merges help catch these conflicts early.

✅ Best Practice

expert

Which practice best supports trunk-based development in a CI/CD pipeline?

Choose the best practice that supports trunk-based development to keep the main branch stable and deployable.

A Run automated tests and code quality checks on every commit to trunk before merging.

B Only run tests once a week on the main branch to save resources.

C Allow developers to merge to trunk without any testing to speed up delivery.

D Use manual testing only after deployment to production.

💡 Hint

Think about how automation helps maintain code quality in fast workflows.

Automated tests and quality checks on every commit ensure that the trunk remains stable and deployable, which is essential for trunk-based development and continuous delivery.

Practice

1. What is the main idea behind trunk-based development?

easy

A. Developing mostly on one main branch to avoid big merge conflicts

B. Creating many long-lived branches for each feature

C. Working only on local branches without pushing to remote

D. Merging branches only once a month

Solution

1. Step 1: Understand trunk-based development concept

   It focuses on working mainly on one main branch, often called trunk or main.

2. Step 2: Compare options with this concept

   Options A, C, and D describe practices that do not align with trunk-based development principles.

3. Final Answer:

   Developing mostly on one main branch to avoid big merge conflicts -> Option A

4. Quick Check:

   Trunk-based development = one main branch [OK]

Hint: Remember: trunk means main branch work mostly [OK]

Common Mistakes:

• Thinking trunk means many long-lived branches
• Believing merges happen rarely in trunk-based
• Confusing local-only work with trunk-based

2. Which of the following git commands is best to quickly merge a short-lived feature branch back to main in trunk-based development?

easy

A. git merge feature-branch

B. git rebase feature-branch

C. git checkout feature-branch

D. git branch -d feature-branch

Solution

1. Step 1: Identify the command to merge branches

   git merge feature-branch merges the feature branch into the current branch, usually main.

2. Step 2: Check other commands

   git rebase rewrites history, git checkout switches branches, and git branch -d deletes a branch but does not merge.

3. Final Answer:

   git merge feature-branch -> Option A

4. Quick Check:

   Merge short-lived branch = git merge [OK]

Hint: Merge feature branch with git merge [OK]

Common Mistakes:

• Using git checkout instead of merging
• Deleting branch before merging
• Confusing rebase with merge

3. Given this sequence of commands in trunk-based development:

git checkout main
git pull origin main
git checkout -b feature
# make changes
 git commit -am 'Add feature'
git checkout main
git merge feature

What is the state of the main branch after these commands?

medium

A. Main branch is unchanged and does not have feature changes

B. Main branch has the new feature changes merged in

C. Feature branch is deleted automatically

D. Main branch is behind origin/main

Solution

1. Step 1: Follow the commands step-by-step

   Start on main, update it from origin, create feature branch, commit changes, switch back to main, then merge feature into main.

2. Step 2: Understand merge effect

   After merge, main branch includes the feature changes locally.

3. Final Answer:

   Main branch has the new feature changes merged in -> Option B

4. Quick Check:

   Merge feature into main = main updated [OK]

Hint: Merge updates main branch with feature changes [OK]

Common Mistakes:

• Assuming merge deletes feature branch automatically
• Thinking main is unchanged after merge
• Forgetting to pull origin before branching

4. You tried to merge a short-lived branch into main but got a conflict error. What is the best way to fix this in trunk-based development?

medium

A. Force push main branch to overwrite remote

B. Delete the feature branch and start over

C. Resolve conflicts manually, then commit the merge

D. Ignore conflicts and continue

Solution

1. Step 1: Understand merge conflicts

   Conflicts happen when changes overlap. They must be fixed manually to keep code correct.

2. Step 2: Choose correct resolution

   Resolving conflicts manually and committing is the proper way. Deleting branch or ignoring conflicts causes problems.

3. Final Answer:

   Resolve conflicts manually, then commit the merge -> Option C

4. Quick Check:

   Fix conflicts manually = merge success [OK]

Hint: Fix conflicts manually before committing merge [OK]

Common Mistakes:

• Ignoring conflicts thinking git fixes automatically
• Deleting branch instead of resolving
• Force pushing without resolving conflicts

5. In trunk-based development, a team wants to avoid long-lived branches but still work on multiple features simultaneously. Which strategy fits best?

hard

A. Work only on main branch without any feature branches

B. Keep all features in one big branch for weeks before merging

C. Use separate repositories for each feature

D. Create short-lived feature branches, merge them quickly to main, and deploy often

Solution

1. Step 1: Understand trunk-based development goals

   It encourages short-lived branches merged quickly to main to reduce conflicts and speed releases.

2. Step 2: Evaluate options

   Create short-lived feature branches, merge them quickly to main, and deploy often matches this approach. Keep all features in one big branch for weeks before merging causes long-lived branches. Work only on main branch without any feature branches limits parallel work. Use separate repositories for each feature complicates repo management.

3. Final Answer:

   Create short-lived feature branches, merge them quickly to main, and deploy often -> Option D

4. Quick Check:

   Short-lived branches + quick merge = trunk-based best practice [OK]

Hint: Use short-lived branches merged fast to main [OK]

Common Mistakes:

• Thinking all work must be on main only
• Using long-lived branches defeats trunk-based purpose
• Splitting features into separate repos unnecessarily