Branching strategies: feature, main, release
Overview
A branching strategy is a set of rules a team follows for organizing their Git branches. The most common branches are `main`, feature branches, and release branches. Imagine a large Google Doc that 10 people are editing. Instead of everyone typing over each other, each person gets a private copy (a feature branch). When they finish, their copy is reviewed and carefully merged into the master copy (the `main` branch). - `main` — The master copy. This code is always stable and ready for users. - `feature/login` — A temporary branch created by one developer to build the login page. It branches off `main`. - `release/v1.0` — A branch created right before launch to freeze the code and fix final bugs. The rule is: **never write code directly on the `main` branch.** You always create a feature branch, do your work there, and merge it back only when it is finished and tested.
It keeps the main codebase stable. If your new feature breaks completely, the main project is safe because your broken code is isolated on your feature branch.
Where used: Git, GitHub, Team projects
Why learn this
- You will not accidentally break the code that thousands of users are relying on.
- You can work on your own features peacefully without teammates overwriting your changes.
Code walkthrough
def git_workflow_simulator():
main_branch = ['stable code']
feature_branch = main_branch.copy()
feature_branch.append('new login feature')
# feature is tested, now merge:
main_branch = feature_branch.copy()
print('Main now has:', main_branch)
git_workflow_simulator()Focus: feature_branch = main_branch.copy()
Aha moment
main_code = 'stable'
my_branch = main_code
my_branch = 'broken login'
print(main_code)Prediction: In this analogy, if you break your feature branch, does the main branch break too?
Common guess: Yes.
No, because a branch is a completely isolated copy. Breaking your feature branch leaves the main branch completely safe.
Common mistakes
- Committing directly to main: You forget to create a new branch and write all your code on `main`. If it has a bug, the live product immediately breaks.
- Keeping a feature branch alive too long: You work on a feature branch for two months without merging. By the time you try to merge, `main` has changed completely, causing massive merge conflicts.
Recall questions
- Explain the purpose of a feature branch in your own words, as if to a classmate.
- Why is it dangerous to write code directly on the 'main' branch?
Understanding checks
You are building a shopping cart. Halfway through, the boss asks you to quickly fix a typo on the homepage. Should you fix it on your shopping cart branch?
No. You should switch back to main, create a new branch just for the typo fix, merge that, and then return to your shopping cart branch.
Never write code directly on the main branch, and keep feature branches focused on one task. Mixing a typo fix with an unfinished feature means the typo won't be fixed live until the cart is fully done.
A teammate says, 'I created a release branch for version 2.0, so I will start building all the version 3.0 features on this release branch.' What is wrong with this?
Release branches are strictly for final bug fixes before launch, not for building new features.
A release branch freezes the code for a specific launch. New features should always go on new feature branches that branch off main.
Practice tasks
Isolate the feature
Given this simulation, change the code so the new feature is added to the feature branch, NOT the main branch.
Challenge
Simulate a merge
Write a Python function `merge_code(main_list, feature_list)` that takes two lists of strings. It should add all items from the feature list into the main list, and return the updated main list.
Continue learning
Next: Rebase vs merge