Module 8 Lesson 2: Feature Branch Workflow

The Feature Branch Workflow is the backbone of modern software development (and platforms like GitHub). It solves the biggest problem of the Centralized Workflow: Broken code on main.

By ensuring that no developer ever commits directly to the main branch, you guarantee that your project is always "deployable."

---

1. How it Works

Instead of working on main, every new task (feature, bugfix, experiment) gets its own branch.

The Workflow Loop:

1. Branch Out: Create a new branch from main: git switch -c feature/new-login.
2. Work: Make as many commits as you need on your branch.
3. Push Branch: Upload your branch to the server: git push -u origin feature/new-login.
4. Pull Request (PR): Open a PR on GitHub/GitLab to ask your team to review your code.
5. Merge: Once approved, the branch is merged into main.
6. Cleanup: Delete the feature branch.

graph TD
    Main["main (Stable)"] --> F1["Feature: Dark Mode"]
    Main --> F2["Feature: API Sync"]
    F1 --> Main
    F2 --> Main
    
    style Main fill:#dfd,stroke:#333
    style F1 fill:#fdd
    style F2 fill:#fdd

---

2. Why this is superior

Parallel Development

Dev A can work on the UI for three days without ever worrying about Dev B breaking their computer.

Code Reviews

Because you are using Pull Requests, your teammates can comment on your code before it enters the official project. This significantly improves code quality.

Continuous Integration (CI)

Automated tests can run on your feature branch. If your code breaks the tests, Git prevents the merge, keeping main safe.

---

3. Keeping your branch up-to-date

While you work on feature/a, main might move forward. You should periodically bring those changes into your branch to stay in sync:

git switch feature/a
git pull origin main

---

Lesson Exercise

Goal: The PR Simulation.

1. Go to your git-practice repo.
2. Create a branch feature/landing-page.
3. Add a file landing.html and commit it.
4. Imagine a teammate pushed a new file styles.css to main. (Simulate this by switching to main, creating the file, and committing).
5. Switch back to your feature/landing-page.
6. Merge main into your feature branch.
7. Verify that your feature branch now has both landing.html and styles.css.

Observation: You'll see that your feature branch is its own "Workspace" that you can carefully cultivate until it’s perfect.

---

Summary

In this lesson, we established:

• The Feature Branch Workflow isolates development.
• The main branch is kept stable and is only updated via merges.
• Pull Requests are used for code review and automated testing.
• This is the "Standard" way of working at companies like Google, Meta, and thousands of startups.

Next Lesson: Some projects need more structure (e.g., separating "Development" from "Production"). Welcome to Lesson 3: Git Flow.