Branching Strategy

Key points

• A branch lets you split off from the main line (main) and make changes without affecting anyone else's work.
• Once the work is done, you "merge" it back into the main line. If both sides changed the same spot, a "conflict" can occur.
• Using branches well lets multiple features or fixes move forward safely in parallel.

What happens without branches

What would happen if everyone committed directly to a single history (main)? Someone's half-finished, still-unstable code from testing out a new feature would end up mixed straight into the whole team's history.

Then when someone wants to release "today," other people's unfinished changes are tangled in, and nobody can release with confidence.

🔑 A familiar exampleIt's like several people adding to the same document at once. If someone sends a still-in-progress draft straight to the printer while a colleague is mid-sentence, that's a problem.

What is a branch?

A branch is a mechanism for splitting the flow of history. By creating a separate working branch for a feature or fix, apart from the main "main" branch, you can experiment freely without affecting the main line.

🔑 A familiar exampleIt's similar to a "choose your own adventure" branching storyline. The main story (main) stays untouched while you try a different path (branch), and if it works out, you fold it back into the main story later.

Developing on a working branch

In real teams, it's common to create a branch per feature or fix — for example, one branch for "add login feature" and another for "fix layout bug."

No matter how many times you commit on a working branch, main is unaffected. You can record your progress in fine-grained detail without worry.

Merging: joining back into the main line

Once the work on a branch is complete, you "merge" it, folding its changes into the main line (main). After the merge finishes, the branch's change history becomes part of main too.

Just like a branching storyline, you try out several routes (branches) and merge the ones that worked out well back into the main story (main).

What is a conflict?

During a merge, if both main and the working branch changed "the same spot in the same file," Git can't automatically decide which version to keep — and flags it as a "conflict."

🔑 A familiar exampleIt's like two people trying to book the same meeting room at the same time. The system can't decide on its own, so a person has to step in and work out whose booking takes priority.

Summary

A branch is a "fork" mechanism that lets you make progress without affecting the main line, and finished work rejoins the main line through a merge. Conflicts arise when changes overlap on the same spot, so merging and syncing frequently is the key to a safe workflow.

Related topics:

• Git Basics
• Collaboration on GitHub
• What Are Version Control & Git?

🏠 Back to top