Trunk-based development in Git - Step-by-Step Execution

Process Flow - Trunk-based development

Start on trunk (main branch)

↓

Create short-lived feature branch

↓

Develop feature

↓

Merge back to trunk quickly

↓

Run tests on trunk

↓

Deploy from trunk

↓

Repeat for next feature

Trunk-based development means working on a single main branch, creating short-lived branches for features, merging them back quickly to keep code integrated and stable.

Execution Sample

Git

git checkout main
# create feature branch
git checkout -b feature1
# make changes
# commit changes
git checkout main
git merge feature1

This sequence shows creating a feature branch from main, making changes, then merging back to main quickly.

Process Table

Step	Action	Branch	Commit State	Result
1	Checkout main branch	main	Initial commit	On main branch
2	Create feature branch 'feature1'	feature1	Same as main	New branch created
3	Make changes and commit on feature1	feature1	One new commit	Feature work done
4	Checkout main branch	main	Initial commit	Switched back to main
5	Merge feature1 into main	main	Initial + feature commit	Feature integrated
6	Delete feature1 branch	-	-	Clean up feature branch

💡 Feature branch merged quickly back to main, keeping trunk updated and stable

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
Branch	main	main	feature1	feature1	main	main	main
Commit State	Initial commit	Initial commit	Initial commit	Initial + feature commit	Initial commit	Initial + feature commit	Initial + feature commit

Key Moments - 3 Insights

Why do we create short-lived branches instead of working directly on main?

Short-lived branches let you work on features without breaking main. Execution table step 3 shows work on feature1 branch separate from main.

What happens if we wait too long to merge back to main?

Waiting too long causes big merges and conflicts. Trunk-based development merges quickly as shown in step 5 to keep integration smooth.

Why delete the feature branch after merging?

Deleting keeps the repo clean and avoids confusion. Step 6 shows branch deletion after merge.

Visual Quiz - 3 Questions

Look at the execution table, what branch is active at step 3?

A main

B feature1

C develop

D release

💡 Hint

Check the 'Branch' column at step 3 in the execution table

At which step is the feature branch merged back into main?

A Step 5

B Step 2

C Step 4

D Step 6

💡 Hint

Look for the 'Merge feature1 into main' action in the execution table

If we skip deleting the feature branch, what changes in the execution table?

A Step 3 would show main branch

B Step 5 would change branch name

C Step 6 would be missing

D No changes at all

💡 Hint

Step 6 shows branch deletion; skipping it removes that step

Concept Snapshot

Trunk-based development uses a single main branch.
Create short-lived feature branches.
Merge features back quickly to main.
Keep main branch stable and deployable.
Delete feature branches after merge.

Full Transcript

Trunk-based development is a way to keep all work integrated on one main branch called trunk or main. Developers create short-lived branches for features, work on them, then merge back quickly to avoid conflicts. This keeps the main branch stable and ready for deployment. The process involves checking out main, branching off, committing changes, merging back, and cleaning up branches. This method reduces integration problems and speeds up 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