Team Workflows

🚀 Git Team Workflows: Working Together Like a Dream Team

The Big Picture: Building a Treehouse Together

Imagine you and your friends want to build the coolest treehouse ever. But here’s the thing—you can’t all hammer nails in the same spot at the same time! You need a plan so everyone can work on different parts without bumping into each other.

That’s exactly what Git team workflows do for code. They’re the rules that help teams work together without making a mess.

🌿 Feature Branch Workflow

The Idea: One Branch Per Project

Think of your main treehouse as the main branch. It’s the finished, working version everyone agrees on.

Now, suppose your friend Emma wants to add a rope ladder. Instead of hammering on the main treehouse (what if she makes a mistake?), she builds the ladder on her own separate workbench.

graph TD
    A["main branch"] --> B["Emma creates<br>feature/rope-ladder"]
    B --> C["Emma builds<br>the ladder"]
    C --> D["Ladder tested<br>& approved"]
    D --> E["Merge back<br>to main"]

How It Works

1. Create a branch for your feature
2. Work on it without affecting main
3. Test it to make sure it works
4. Merge it back when it’s ready

Example Commands

git checkout -b feature/rope-ladder
# Work on your code...
git add .
git commit -m "Add rope ladder"
git push origin feature/rope-ladder

Why this is great: Nobody’s work gets in anyone else’s way!

🌊 Gitflow Workflow

The Idea: Organized Like a Factory

Gitflow is like having a super organized factory with different assembly lines:

graph TD
    A["main"] --> B["hotfix"]
    A --> C["release"]
    D["develop"] --> E["feature/login"]
    D --> F["feature/search"]
    E --> D
    F --> D
    D --> C
    C --> A
    B --> A
    B --> D

When to Use What

• feature branch: “I’m adding a new button!”
• release branch: “We’re getting ready to launch version 2.0!”
• hotfix branch: “Oh no! Users can’t log in! Fix it NOW!”

Example

# Start a feature
git checkout develop
git checkout -b feature/search-bar

# When done, merge to develop
git checkout develop
git merge feature/search-bar

# Ready to release?
git checkout -b release/v2.0

# Ship it!
git checkout main
git merge release/v2.0

Why this is great: Perfect for big teams with scheduled releases!

🍴 Forking Workflow

The Idea: Your Own Copy of the Treehouse

Imagine there’s an amazing public treehouse in the park. You love it, but you want to add your own ideas. So you:

1. Build an exact copy in your backyard (fork)
2. Make your changes to YOUR copy
3. Show the original builders what you made
4. They decide if they want to add it to the original

graph TD
    A["Original Repo<br>Park Treehouse"] --> B["Your Fork<br>Your Copy"]
    B --> C["Make Changes"]
    C --> D["Create Pull Request"]
    D --> E{Maintainers Review}
    E -->|Approved| F["Merged to Original"]
    E -->|Needs Work| C

Example

# Fork on GitHub first, then:
git clone https://github.com/YOU/project.git
git remote add upstream https://github.com/ORIGINAL/project.git

# Make changes and push to YOUR fork
git push origin feature/my-idea

# Create pull request on GitHub

Why this is great: Perfect for open source projects where anyone can contribute!

🚂 Trunk-Based Development

The Idea: One Track, Fast Trains

Instead of many long branches, everyone works on one main track (trunk). Changes are tiny and happen super fast—like quick little trains passing through.

graph LR
    A["main"] --> B["tiny change 1"]
    B --> C["tiny change 2"]
    C --> D["tiny change 3"]
    D --> E["tiny change 4"]

The Rules

1. Branches live less than a day (or even hours!)
2. Changes are small (easy to review)
3. Merge often (no long-lived branches)
4. Use feature flags to hide unfinished work

Example

# Morning: Start small feature
git checkout -b quick-fix-button
# Make small change
git commit -m "Fix button color"
# Same day: Merge back
git checkout main
git merge quick-fix-button

Why this is great: Super fast, minimal merge conflicts, continuous delivery!

🎫 Pull Request Concept

The Idea: Asking Permission Before Adding

A Pull Request (PR) is like saying:

“Hey team! I made something cool. Can you check it before we add it to the main treehouse?”

It’s NOT just pushing code—it’s starting a conversation.

What a Good PR Includes

graph TD
    A["Push your branch"] --> B["Create Pull Request"]
    B --> C["Team gets notified"]
    C --> D["Discussion & Review"]
    D --> E{Approved?}
    E -->|Yes| F["Merge!"]
    E -->|No| G["Make changes"]
    G --> D

Example PR Description

## What I Changed
Added dark mode toggle button

## Why
Users requested it in issue #42

## How to Test
1. Click the moon icon
2. See colors change

## Screenshots
[Before] [After]

Why this is great: Everyone stays informed, bugs get caught early!

👀 Code Review Workflow

The Idea: Fresh Eyes Catch Mistakes

Even the best builders miss things. That’s why we have friends check our work before it’s final.

Code Review is Like…

Imagine you wrote a story. Before showing it to the whole class, you ask a friend to read it. They might say:

• “This sentence is confusing” ✏️
• “You spelled ‘receive’ wrong” 🔤
• “This part is really good!” ⭐

The Review Process

graph TD
    A["Author submits PR"] --> B["Reviewers assigned"]
    B --> C["Reviewers read code"]
    C --> D["Leave comments"]
    D --> E{Changes needed?}
    E -->|Yes| F["Author fixes"]
    F --> C
    E -->|No| G["Approve & Merge"]

What Reviewers Look For

1. Does it work? (Logic correctness)
2. Is it readable? (Can others understand it?)
3. Is it safe? (No security holes)
4. Is it tested? (Proof it works)
5. Does it follow our style? (Consistency)

Good Review Comments

✅ Helpful: “This loop could be simpler using .map() - want me to show you?”

❌ Not helpful: “This is wrong.”

Why this is great: Better code, shared knowledge, fewer bugs!

🔀 Resolving Diverged Branches

The Problem: Two Paths That Went Different Ways

Remember Emma’s rope ladder? Well, while she was building it, Tom also made changes to the main treehouse. Now Emma’s ladder doesn’t quite fit anymore!

This is called diverged branches.

graph TD
    A["main"] --> B["Tom's changes]
    A --> C[Emma's branch"]
    C --> D[Emma's work]
    B --> E["main has moved on!"]
    D --> F["Needs to catch up"]

Solution 1: Merge (Keep All History)

git checkout feature/rope-ladder
git merge main
# Fix conflicts if any
git commit -m "Merge main into feature"

Result: Your branch now has both your changes AND the new main changes.

Solution 2: Rebase (Clean History)

git checkout feature/rope-ladder
git rebase main
# Fix conflicts if any
git rebase --continue

Result: It’s like you started your work AFTER the latest changes.

When Conflicts Happen

Sometimes both branches changed the same part. Git will show you:

<<<<<<< HEAD
Tom's version of the code
=======
Emma's version of the code
>>>>>>> feature/rope-ladder

You pick which to keep (or combine both), then:

git add conflicted-file.txt
git commit -m "Resolve conflict"

Merge vs Rebase: Quick Guide

Why this matters: Knowing how to resolve diverged branches keeps teamwork smooth!

🎯 Quick Summary

🌟 You’ve Got This!

Team workflows might seem complicated at first, but they’re really just agreements about how to work together without stepping on each other’s toes.

Start simple:

1. Use feature branches for your work
2. Create pull requests for review
3. Review each other’s code kindly
4. Merge and celebrate! 🎉

The best workflow is the one your team actually follows. Pick one, try it, and adjust as you learn!

Happy collaborating! 🤝