Courses Developer Fundamentals for Builders Branching, Merging, and Collaboration

Git and Professional Development Workflow

Branching, Merging, and Collaboration

Feature branches, merge vs rebase, and pull requests

13 min read · Lesson 14 of 18

Working With Others (Including Future You)

Solo developers still benefit from branching discipline. When your project grows, or when you collaborate, good Git practices prevent chaos.


Feature Branch Workflow

The most common professional workflow:

  1. Create a branch from main: git checkout -b feature/user-avatars
  2. Make commits on the feature branch.
  3. Push the branch: git push -u origin feature/user-avatars
  4. Open a Pull Request on GitHub.
  5. After review, merge into main.
  6. Delete the feature branch.

This keeps main stable. Broken code lives on branches until it's ready.


Merge vs Rebase

Merge creates a new commit that combines two branches. The history preserves both branches:

git checkout main
git merge feature/user-avatars
# Creates a merge commit with two parents

Rebase replays your branch's commits on top of the target branch, creating a linear history:

git checkout feature/user-avatars
git rebase main
# Moves your commits to the tip of main

When to use each:

  • Merge when you want to preserve the complete history of what happened and when.
  • Rebase when you want a clean, linear history. Never rebase commits that have been pushed to a shared branch.
The golden rule: never rebase commits that other people have based work on. Rebasing rewrites commit hashes, which breaks other people's branches.

Conflict Resolution

Conflicts happen when two branches modify the same lines. Git marks conflicts in the file:

<<<<<<< HEAD
$price = $item->cost * 1.1; // 10% markup
=======
$price = $item->cost * 1.15; // 15% markup
>>>>>>> feature/pricing-update

To resolve: edit the file to keep the correct code, remove the conflict markers, then git add and continue the merge or rebase.


Pull Request Best Practices

  • Small PRs — Easier to review, fewer conflicts, faster to merge.
  • Descriptive titles and descriptions — What changed and why. Link to issues.
  • Self-review first — Read your own diff before requesting review.
  • One concern per PR — Don't mix a bug fix with a feature addition.

Key Takeaways

  • Use feature branches to keep main stable.
  • Merge preserves history; rebase linearizes it. Don't rebase shared branches.
  • Conflicts are normal. Read the markers, choose the correct code, remove markers.
  • Small, focused PRs with good descriptions are the mark of a professional developer.
Ask about this lesson