Trunk-based development in Git - Mini Project: Build & Apply

Trunk-based Development with Git

📖 Scenario: You are working on a small team project where everyone commits their changes directly to the main branch, called main. This method is called trunk-based development. It helps keep the project simple and avoids long-lived branches.In this project, you will practice creating a new file, committing it to main, and then updating it with a new commit.

🎯 Goal: Learn how to use trunk-based development by making commits directly on the main branch using Git commands.

📋 What You'll Learn

Create a new file called feature.txt with specific content

Add the file to Git staging area

Commit the file with a clear message on the main branch

Modify the file and commit the changes again on the main branch

Show the commit log to verify the commits

💡 Why This Matters

🌍 Real World

Trunk-based development is used in many software teams to keep the codebase simple and avoid complex merges. It helps teams deliver features quickly and safely.

💼 Career

Understanding trunk-based development and Git commands is essential for software developers, DevOps engineers, and anyone working in collaborative coding environments.

1

Create a new file and initialize Git

Create a new file called feature.txt with the text Initial feature content. Then initialize a new Git repository with git init.

Git

# Create feature.txt with 'Initial feature content'
# Run 'git init' to start a new repository
# Your code here

Hint

Use echo to write text into the file. Use git init to create a new Git repository.

2

Add the file to staging area

Add the file feature.txt to the Git staging area using git add feature.txt.

Git

echo "Initial feature content" > feature.txt

git init

# Add feature.txt to staging area
# Your code here

Hint

Use git add followed by the file name to stage the file.

3

Commit the file on main branch

Commit the staged file with the message Initial commit of feature.txt using git commit -m "Initial commit of feature.txt". Ensure you are on the main branch.

Git

echo "Initial feature content" > feature.txt

git init

git add feature.txt

# Commit with message 'Initial commit of feature.txt'
# Your code here

Hint

Use git commit -m with your message in quotes to commit.

4

Modify the file and commit the update

Append the text More feature details to feature.txt. Then add and commit the changes with the message Update feature.txt with more details. Finally, show the commit log with git log --oneline.

Git

echo "Initial feature content" > feature.txt

git init

git add feature.txt

git commit -m "Initial commit of feature.txt"

# Append 'More feature details' to feature.txt
# Add and commit with message 'Update feature.txt with more details'
# Show commit log with 'git log --oneline'
# Your code here

Hint

Use >> to append text to a file. Then stage and commit the changes. Use git log --oneline to see short commit messages.

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