Branches: working without fear
A branch is a separate line of work. It lets you build a new feature or try an idea without disturbing the working version of the project.
Picture the main project as a straight road called main. Everything on main is supposed to work. Now you want to add "Pay with UPI" to your app — but it's half-built and would break things. So you take a side road: a branch. You build on the branch, and main stays safe and working the whole time. When your feature is ready and tested, you merge the side road back into main.
Why branches are wonderful
- You can experiment freely. If the idea fails, you throw the branch away and
mainis untouched. - Five teammates can each work on their own branch at the same time without stepping on each other.
- The working version (
main) always stays stable, ready to demo to your professor or ship to customers.
The everyday commands
See your branches (the current one has a *):
git branch
Create a new branch and switch to it:
git switch -c feat/upi-payments
feat/upi-payments is just a name. Teams often use prefixes like feat/ for features and fix/ for bug fixes, so the purpose is obvious at a glance.
Now every commit you make lands on feat/upi-payments, not on main. Do your work, commit as usual.
Switch back to main any time:
git switch main
When you switch, your files change to match that branch. Switch to main and the half-built UPI code disappears from view (it's safe on the other branch); switch back and it returns.
A picture of it
main: A───B───C
\
feat/upi-payments: D───E
main has commits A, B, C. You branched off after C and added D and E on your feature branch. The two lines share history up to C, then go their own ways. Later, merging brings D and E into main.
Naming branches on a team
A common convention at Indian startups and open-source projects alike:
main— the stable, always-working branch.feat/gst-invoices— a new feature.fix/login-crash— a bug fix.priya/experiment— someone's personal scratch branch.
Golden rule: don't build directly on
main. Make a branch, do your work there, and bring it back through a pull request (a later page). This is how professional teams keep the main version trustworthy.