The team breaks production

Three months in, Arjun's startup hired two more developers — Deepa and Vikram. Now three people were pushing code to the same place. Things got chaotic fast.

On a Tuesday afternoon, Deepa was working on the payment page. Vikram was fixing a bug on the homepage. Arjun was adding a new feature to the dashboard. All three pushed to the same code at the same time.

The result was a Frankenstein website — half payment page, half broken homepage, with dashboard code jammed in the middle. Users couldn't log in. The CEO called. It was not a good afternoon.

Enter: branches

A branch is like a parallel universe for your code. You split off from the main codebase, do your work in isolation, test it thoroughly, and only merge it back when it's ready.

Think of it like this: the main road (called `main` or `master`) is the live website. Every developer builds their feature on a side road. When the side road is finished and tested, you merge it back onto the main road.

```bash

See all branches

git branch

Create a new branch and switch to it

git checkout -b feature/payment-redesign

Do your work... commit as normal

git add .

git commit -m "Redesign payment form layout"

Switch back to main

git checkout main

Merge your branch into main

git merge feature/payment-redesign

```

Pull Requests — the team review system

When using GitHub (the cloud home for Git), you don't merge directly. You open a Pull Request (PR). This says: "Hey team, I've finished this branch. Can someone review it before we merge?"

This is how professional teams work. No code goes to production without at least one other person reviewing it. It catches bugs, shares knowledge, and prevents the 3am disaster.

Deepa, Vikram, and Arjun adopted a simple rule: every feature gets its own branch. Every branch gets a pull request. Every pull request gets reviewed before merging. Production disasters dropped by 80%.

Merge conflicts — the unavoidable fight

Sometimes two people change the same line of code. Git doesn't know which version to keep, so it stops and asks you to decide. This is called a merge conflict.

```

<<<<<<< HEAD (your version)

const price = 999;

=======

const price = 1299;

>>>>>>> feature/pricing-update (their version)

```

Git is saying: "Both of you changed this line. You figure it out." You manually pick the right version, delete the conflict markers, and commit. Not fun, but manageable if branches are kept short and merged often.

The workflow that saved Arjun's team

```

main branch ──────────────────────────────────►

                    ↑ merge when ready

feature/payment ─────────────────────►

feature/homepage ──────►

feature/dashboard ────────────►

```

Each developer works independently. Each feature is self-contained. The main branch is always stable and deployable.

Arjun's new rule: Short branches, frequent merges. A branch that lives for more than 3 days is a branch that will cause pain.