Trunk-based development in Git - Commands & Configuration

Introduction

Trunk-based development is a way to work on code where everyone shares one main branch called trunk or main. It helps avoid big conflicts by making small, frequent updates instead of long separate branches.

When a team wants to avoid complicated merges by integrating code daily.

When you want to keep your main branch always ready to release.

When you want to reduce bugs caused by long-lived feature branches.

When you want to encourage collaboration and quick feedback on code changes.

When you want to simplify your version control process for faster delivery.

Commands

Switch to the main branch where all changes are integrated.

Terminal

git checkout main

Expected Output

Switched to branch 'main'

Update your local main branch with the latest changes from the remote repository to avoid conflicts.

Terminal

git pull origin main

Expected Output

Already up to date.

→

--rebase - Reapply your changes on top of the updated main branch to keep history clean

Create a short-lived branch for your new feature or fix, based on the latest main branch.

Terminal

git checkout -b feature-xyz

Expected Output

Switched to a new branch 'feature-xyz'

Stage your changes to prepare them for committing.

Terminal

git add .

Expected Output

No output (command runs silently)

Save your changes locally with a clear message describing what you did.

Terminal

git commit -m "Add feature xyz with tests"

Expected Output

[feature-xyz abc1234] Add feature xyz with tests

 3 files changed, 45 insertions(+), 2 deletions(-)

Switch back to the main branch to prepare for integration.

Terminal

git checkout main

Expected Output

Switched to branch 'main'

Make sure your main branch is up to date before merging your feature branch.

Terminal

git pull origin main

Expected Output

Already up to date.

Integrate your feature branch changes into the main branch.

Terminal

git merge feature-xyz

Expected Output

Updating abc1234..def5678

Fast-forward

 file1.txt | 10 +++++-----

 file2.txt | 20 ++++++++++++++++++++

 2 files changed, 25 insertions(+), 5 deletions(-)

Send your updated main branch with the new feature to the remote repository for others to use.

Terminal

git push origin main

Expected Output

Enumerating objects: 10, done.

Counting objects: 100% (10/10), done.

Delta compression using up to 4 threads

Compressing objects: 100% (6/6), done.

Writing objects: 100% (7/7), 1.23 KiB | 1.23 MiB/s, done.

Total 7 (delta 2), reused 0 (delta 0)

To https://github.com/example/repo.git

   abc1234..def5678  main -> main

Delete your feature branch locally after merging to keep your workspace clean.

Terminal

git branch -d feature-xyz

Expected Output

Deleted branch feature-xyz (was def5678).

Key Concept

If you remember nothing else from this pattern, remember: always keep your main branch clean and integrate small changes frequently.

Common Mistakes

Working on a feature branch for too long without merging back to main.

This causes big conflicts and makes integration harder.

Make small, frequent commits and merge back to main often.

Not updating your local main branch before starting a new feature branch.

Your feature branch may be based on outdated code, causing conflicts later.

Always pull the latest main branch before creating a new feature branch.

Pushing feature branches directly to main without review or testing.

This can introduce bugs or unstable code into the main branch.

Use code review and testing before merging to main.

Summary

Switch to the main branch and update it before starting work.

Create short-lived feature branches for small changes.

Merge feature branches back into main frequently to avoid conflicts.

Push updates to the remote main branch to share with the team.

Delete feature branches after merging to keep the workspace clean.

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