Branches and Merging — Practical Guide for CS50 Students

Branches let you experiment without blowing up the main codebase. Merging is the careful reuniting after the chaos.

You already know how to create a repository (git init / clone) and make staged commits. Great — those are the building blocks. Now let us graduate to the part of version control that makes real teamwork possible: branches and merging. This is where feature development, bug fixes, and collaborative workflows actually happen in the wild.

Why branches matter (and how this connects to software engineering practices)

• Isolation. A branch is a place to try something without disturbing the mainline. Think of it as a sandbox for a feature.
• Parallel work. Multiple teammates can work simultaneously on different branches and then integrate their changes.
• History clarity. When used well, branches + merges make a commit history that tells a story about features and decisions.

This lines up with software engineering practices like code reviews, continuous integration, and modular design: branches let you apply those practices safely and repeatedly.

Basic branch commands you will use a lot

# create and switch to a branch (modern command)
git switch -c feature/cool-thing

# older common command that still appears in tutorials
git checkout -b feature/cool-thing

# list branches
git branch

# switch to main
git switch main

# delete a local branch
git branch -d feature/cool-thing

# push branch to remote
git push -u origin feature/cool-thing

# merge a branch into current branch
git merge feature/cool-thing

Micro explanation

• git switch and git checkout can both change branches; prefer git switch for clarity.
• Use descriptive names: feature/login, fix/typo, docs/readme.

A simple workflow: Feature branches (step-by-step)

1. From main: git switch -c feature/awesome
2. Code, then: git add . && git commit -m "start awesome"
3. Push: git push -u origin feature/awesome
4. Open a Pull Request (PR) on GitHub/GitLab for review
5. After reviews and CI, merge into main
6. git switch main && git pull && git branch -d feature/awesome

Why this rocks: reviewers can see just the feature changes; CI runs against the branch; merging integrates once tests pass.

Merges: fast-forward, merge commits, and --no-ff

When you merge, Git has two common behaviors:

• Fast-forward: if main has not moved since you branched, merging just moves main forward. No extra commit.
• Merge commit: if both branches advanced, Git creates a merge commit that ties histories together.

Use --no-ff to force a merge commit even when a fast-forward would be possible. This keeps the branch boundary visible in history.

# force a merge commit
git merge --no-ff feature/awesome -m "Merge feature/awesome into main"

Merge conflicts: welcome to negotiation

Conflicts happen when two changes touch the same lines. Git will stop and ask you to decide.

Example conflict markers in a file after attempting a merge:

<<<<<<< HEAD
console.log('main version');
=======
console.log('feature version');
>>>>>>> feature/awesome

How to resolve:

1. Open the file, pick or combine the versions, and remove the markers.
2. git add
3. git commit (or git merge --continue if you used a merge tool)

Helpful commands: git status (shows conflicted files), git diff (shows differences), git mergetool (launches a GUI merge helper if configured).

Pro tip: resolve conflicts in logical increments and run tests before committing the resolution.

Rebase vs Merge: choose your adventure

Rebase example to keep history tidy:

git checkout feature/awesome
git fetch origin
git rebase origin/main
# fix conflicts if any, then
git push --force-with-lease

Note: force pushing is okay for your private feature branch, but not for branches others use.

Collaboration patterns (practical options)

• Feature branch + Pull Requests: Most common in open source and class projects. Good for reviews and CI gates.
• Trunk-based development: Short-lived branches or direct commits to main with feature flags. Favored by teams with heavy CI and automated testing.
• GitFlow: More formal with release branches, hotfixes, develop branch. Useful for some release models but often overkill for small projects.

Choose a pattern that fits your team size and release cadence. For CS50 course projects, feature branches + PRs are practical and teach good habits.

Troubleshooting quick wins

• I accidentally committed on main: create a branch from that commit and push it, then reset main if needed.

  git branch feature/from-accident
  git push -u origin feature/from-accident
  # then reset main to origin/main if you need to undo local commits
  git reset --hard origin/main
  

• Lost a branch? git reflog and git log can help you find lost commits.

Key takeaways

• Branches let you work in parallel and experiment safely. Use clear names and short-lived branches for clarity.
• Merging integrates work; conflict resolution is a skill you will use often. Practice resolving conflicts calmly — it is part of teamwork.
• Rebase rewrites history; merge preserves the record. Use rebase for clean history on private branches; prefer merge for team transparency.
• Combine branching with code reviews, CI, and automated tests to follow solid software engineering practices.

Remember: branches are cheap and powerful. Create them early, push them often, and use PRs to make collaboration predictable and less dramatic than a reality TV show.

Want a one-line mantra? "Branch early, commit often, merge thoughtfully."

If you want, I can generate a short cheat sheet image or a step-by-step conflict resolution walkthrough tailored to a sample repo. Which would help you most next?