Why Trunk-based development in Git? - Purpose & Use Cases

The Big Idea

What if you could avoid painful merge conflicts and deliver updates smoothly every day?

The Scenario

Imagine a team where everyone works on their own separate copies of a project for weeks. When it's time to combine their work, they find many conflicts and broken features.

The Problem

Working separately for too long causes confusion, mistakes, and delays. Fixing conflicts later wastes time and can break the project, making everyone frustrated.

The Solution

Trunk-based development means everyone works together on one main project line, sharing small changes often. This keeps the project healthy and avoids big surprises.

Before vs After

✗ Before

git checkout -b feature-xyz
# work for weeks
# big merge conflicts later

✓ After

git checkout main
git pull
# small change
git commit -m 'update'
git push

What It Enables

It lets teams deliver updates faster and with fewer problems by staying in sync all the time.

Real Life Example

A team building a website pushes small updates daily to the main project, so new features appear quickly and bugs are caught early.

Key Takeaways

Working on one main project line avoids big merge problems.

Small, frequent updates keep the project stable and current.

Teams can deliver better software faster and with less stress.

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