Branches & Merging

This lesson on Branches & Merging is hands-on and example-driven. You will be able to isolate development work using feature branches and safely integrate those changes into the main codebase. You will master the core Git commands required to create, navigate, and finalize a standard branch-merge workflow.

What You'll Be Able To Do

• Create new branches from a specific commit or existing branch using the CLI.
• Navigate safely between divergent branches using git checkout without losing work.
• Execute a merge operation while correctly positioned on the target branch.
• Finalize integrated changes by staging and committing the merge result.
• Apply the standard feature integration pattern for stable development.

Detailed Concept Walkthrough

1. Branch Creation and Navigation

Branches are lightweight, movable pointers to commits, enabling parallel development. The checkout command moves the HEAD pointer to switch your working context.

• Mechanism: git checkout -b <new_branch> is a shortcut that creates the branch pointer at the current HEAD commit and immediately moves HEAD to point to the new branch.
• Execution Flow: Using git checkout <existing_branch> updates your working directory and staging area to match the state of the target branch's latest commit.
• Best Practice: Always commit or stash local changes before switching branches to avoid conflicts or losing work during the context switch.

# Create a new branch named 'feature/login_fix' and switch to it
git checkout -b feature/login_fix

# Switch back to the main development line
git checkout master

Key Takeaway: Use checkout -b to create and switch instantly; use plain checkout to navigate existing branches.

2. Standard Feature Integration Workflow

Features are developed in isolation on dedicated branches and integrated back into the main branch (master) only when complete, ensuring the main line remains stable.

• Execution Flow: After development and local commits on the feature branch, you switch to the target branch (e.g., master) to receive the changes.
• Mechanism: git merge <feature_branch> applies the changes from the source branch onto the target branch, calculating the necessary history integration.
• Best Practice: Review git status immediately after the merge to ensure all changes were integrated and to confirm the merge commit is ready to be finalized.

# 1. Switch to target
git checkout master
# 2. Execute merge
git merge feature/new_feature
# 3. Finalize merge commit
git commit -m "Integrated feature"

Key Takeaway: The workflow requires developing, switching to the target, merging, and then committing the merge result.

3. Merge Initialization Context

Git merges are directional: the branch you are currently on is the target that receives the changes from the branch specified as the argument.

• Syntax Rule: The command structure is always git merge <source_branch> executed while HEAD points to the target_branch.
• Under the Hood: Git calculates the difference between the target branch and the source branch, applying the source changes directly into the target's working directory.
• Nuance: Switching between divergent branches can temporarily update the working directory, sometimes requiring immediate staging/committing to stabilize the merge result.

# HEAD is currently on 'master' (the target)
git checkout master
# Merge 'feature_branch' (the source) into 'master'
git merge feature_branch

Key Takeaway: Always switch to the branch that should receive the changes before running the merge command.

Topics Covered in Branches & Merging

1. Navigating Existing Branches (00:27 - 01:05) — Developers use git checkout to switch between established branches, isolating changes from the main development line.
2. Creating New Branch (01:05 - 01:57) — The -b flag is used with checkout to create a new branch and immediately switch context to it.
3. Implementing Changes (02:41 - 04:09) — Changes are added locally to the current branch, preparing them for integration by modifying existing files and creating new ones.
4. Preparing Target Branch (04:09 - 04:32) — The developer switches back to the main branch because merging must be performed while on the target branch that will receive the changes.
5. Executing and Committing Merge (04:32 - 05:59) — Changes from the source branch are integrated into the target branch, and the resulting merge state is staged and committed to finalize the integration history.

Git Cheat Sheet

• git checkout <branch> — Switch HEAD pointer and working directory context

  git checkout master
  

• git checkout -b <new> — Create new branch and switch to it immediately

  git checkout -b new_branch
  

• git merge <source> — Integrate changes from source branch into current branch

  git merge feature/bugfix
  

• git status — Review current branch state and staged/unstaged changes

  git status
  

• git add . — Stage all modified and new files for the next commit

  • In practice: git add .

• git commit -m "msg" — Finalize changes or merge result into repository history

  git commit -m "Finalize merge"
  

Comparison Table

Common Pitfalls

• Mistake: Running git merge master while on a feature branch. Avoid: Always switch to the target branch (master) before merging the feature branch into it.
• Mistake: Forgetting to stage and commit after a complex merge operation. Avoid: Run git status after merging; if changes exist, git add . and git commit.
• Mistake: Trying to switch branches with uncommitted local changes. Avoid: Commit or stash all local modifications before attempting a git checkout.

FAQs

• Why do I have to switch back to master before merging? Git merges are directional; the branch you are checked out on is the target that receives the changes from the source branch specified in the command.
• What happens if I checkout an older commit hash instead of a branch name? You enter a detached HEAD state, meaning you are viewing history but any new commits won't belong to a named branch unless you explicitly create one.
• Does git checkout -b automatically commit the changes? No, it only creates the pointer and switches context; you must still stage and commit your modifications manually.