Trunk-based development in Git - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the command to switch to the main branch in Git.

Git

git checkout [1]

Drag options to blanks, or click blank then click option'

Afeature

Brelease

Cmain

Ddevelop

Attempts:

3 left

💡 Hint

Common Mistakes

Using a feature branch name instead of the main branch.

Typing 'master' when the main branch is named 'main'.

The main branch is usually called main in trunk-based development. This command switches your working directory to that branch.

2fill in blank

medium

Complete the command to create a new short-lived feature branch from main.

Git

git checkout -b [1] main

Drag options to blanks, or click blank then click option'

Afeature-login

Bhotfix

Crelease-v1

Dmain

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'main' as the new branch name, which already exists.

Using long-lived branch names like 'release-v1' in trunk-based development.

In trunk-based development, feature branches are short-lived. Here, feature-login is a descriptive name for the new branch.

3fill in blank

hard

Fix the error in the command to merge the feature branch back into main.

Git

git checkout main
 git [1] feature-login

Drag options to blanks, or click blank then click option'

Apush

Bbranch

Ccommit

Dmerge

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'git commit' instead of 'git merge'.

Trying to push before merging.

To combine changes from the feature branch into main, you use git merge.

4fill in blank

hard

Fill both blanks to push the main branch and delete the feature branch locally.

Git

git [1] origin main
 git branch [2] feature-login

Drag options to blanks, or click blank then click option'

Apush

Bpull

Cdelete

D-d

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'git pull' instead of 'git push' to send changes.

Using 'git branch delete' which is invalid syntax.

First, you push the main branch to the remote with git push origin main. Then, you delete the local feature branch with git branch -d feature-login.

5fill in blank

hard

Fill all three blanks to fetch updates, rebase your feature branch on main, and then push it.

Git

git [1]
git checkout feature-login
git [2] main
git [3] origin feature-login

Drag options to blanks, or click blank then click option'

Afetch

Brebase

Cpush

Dmerge

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'git merge' instead of 'git rebase' in trunk-based development.

Pushing before rebasing, which can cause conflicts.

First, fetch updates from the remote with git fetch. Then, rebase your feature branch on main with git rebase main to keep history clean. Finally, push your rebased branch with git push origin feature-login.

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