Branches: Working on New Features Safely

The Rough Notebook and the Neat Copy

Remember writing an essay for an exam or a competition? You did not write straight into your neat copy. You wrote a rough draft in a separate notebook first. You crossed out lines, tried a new opening, maybe tore out a page. When the draft was good, you copied it into the neat copy. The neat copy stayed clean the whole time.

Git branches give you that rough notebook. The main branch is the neat copy: the version of the project that works and that everyone trusts. A new branch is a separate place where you can try an idea without any risk to main.

In this lesson Asha Verma, a second-year BCA student, uses branches to build a registration form for the Utsav college fest website (college-fest-site). Her friends Ravi and Imran work on the same site, so keeping main clean matters to all three of them.

What Is a Branch?

In the lesson on history, you saw that every commit is a saved snapshot with its own ID. A branch is simply a movable label that points at one commit. That is all. It is not a copy of your files, so creating a branch is instant and uses almost no space.

When you make a new commit, the label of the branch you are on moves forward to that new commit. Git also keeps a special pointer called HEAD, which means “the branch you are on right now”.

                         main
                           |
commits:   A -----> B -----> C
                             |
            feature/registration-form

Both labels point at commit C. HEAD points at the branch you are on.

Why teams never work directly on main

• main should always work. If the fest website goes live from main, a half-finished form there could break the page the whole college sees.
• Work happens in parallel. Asha builds the form, Ravi fixes the schedule, Imran adds sponsors. Each works on a branch, so no one is blocked by another person’s unfinished work.
• Ideas can be thrown away. If an experiment fails, you delete the branch. main never knew about it.
• Review is easier. A branch holds one topic, so a teammate can check it before it joins main. You will see this in the Pull Requests lesson.

Seeing Your Branches: git branch

Open the terminal in VS Code (Ctrl + `), or Git Bash on Windows, or Terminal on Mac and Linux. The commands are the same everywhere.

# Go into the project folder
cd college-fest-site

# List all local branches (the * marks the one you are on)
git branch

You will see something like:

* main

Right now there is only one branch. The star (*) shows the branch you are on.

Creating and Switching: git switch -c

To create a branch and move onto it at the same time, use git switch -c (the -c means “create”). The new branch starts at the commit you are on now, so switch to main first if you want a fresh start.

# Create a new branch AND move onto it in one step
git switch -c feature/registration-form

# Check where you are now
git branch

You will see something like:

Switched to a new branch 'feature/registration-form'
* feature/registration-form
  main

There are two other commands you will use often:

# Create a branch but stay where you are
git branch fix/footer-links

# Move to an existing branch
git switch fix/footer-links

# Go back to main
git switch main

Older guides use git checkout. You will often read git checkout feature-x and git checkout -b feature-x. These still work, but git checkout does many different jobs, which confuses beginners. git switch was added to do just one job: changing branches.

Naming Branches Well

A good branch name tells your teammates what is inside before they even open it. Many teams use a short prefix, a slash, and a few words joined by hyphens:

• feature/registration-form for new work
• fix/footer-links for a bug fix
• docs/readme-setup for documentation changes

Use small letters and hyphens. Do not use spaces (Git does not allow them in branch names). Avoid vague names like new, test2 or asha-work.

Committing on a Branch

Committing works exactly as you already know. The only difference is that the commit goes onto the branch you are on.

# You are on feature/registration-form
git status

# Create the new page in VS Code, then save it
git add register.html
git commit -m "Add registration form page"

You will see something like this (your commit ID will differ):

On branch feature/registration-form
nothing to commit, working tree clean
[feature/registration-form a1b2c3d] Add registration form page
 1 file changed, 24 insertions(+)
 create mode 100644 register.html

Notice that the commit line now shows the branch name in square brackets. After two commits on the feature branch, the history looks like this:

main:                       A---B---C
                                     \
feature/registration-form:            D---E

main still points at C. The feature branch has moved on to E.

How Your Files Change When You Switch

This surprises almost everyone the first time. When you switch branches, Git changes the files in your folder to match the last commit of that branch.

# On the feature branch, the new file is there
ls

# Go back to main
git switch main

# The file is gone from the folder (it is safe inside Git)
ls

You will see something like:

css  images  index.html  register.html
Switched to branch 'main'
css  images  index.html

Do not panic when register.html disappears. It is safely stored in Git on the feature branch. Run git switch feature/registration-form and it comes back. If you have a file open in VS Code, the editor also updates to show that branch’s version.

One rule: commit your changes before you switch. If you have unsaved work that clashes with the other branch, Git stops you to protect it:

error: Your local changes to the following files would be overwritten by checkout:
	index.html
Please commit your changes or stash them before you switch branches.
Aborting

The fix is simple: commit your work first, then switch. (The word “stash” in that message is another way to put work aside; you will learn it in the Stash, Cherry-pick and Tags lesson.)

Deleting Branches You No Longer Need

Once a branch is merged into main (you will learn merging in the next lesson), the label is not needed any more. Its commits stay in main, so deleting it is safe and keeps your list tidy.

# Delete a branch that has already been merged into main
git branch -d feature/registration-form

# Force-delete a branch you do not want, even if it is not merged
git branch -D experiment/neon-colours

You will see something like:

Deleted branch feature/registration-form (was a1b2c3d).
error: The branch 'experiment/neon-colours' is not fully merged.

Small -d is the safe version: Git refuses if the work is not merged anywhere. Capital -D deletes anyway, so use it only when you really want to throw the work away. You cannot delete the branch you are standing on, so switch to main first.

Branches in VS Code

VS Code shows branches without any typing:

• The bottom-left corner of the window (the status bar) shows the current branch name, for example main. Click it to see a list of branches, switch to one, or choose Create new branch.
• The Source Control view (the icon with three connected circles in the left bar) shows your changes and lets you commit on the current branch.
• Recent versions of VS Code can also show a graph of commits and branches in the Source Control view. Extensions such as Git Graph do the same.

Learn the commands first, then use the buttons to save time. When something goes wrong, the terminal tells you exactly what happened.

Real-Life Example: Two Jobs at Once

On Monday Asha starts a sponsors page. On Tuesday, before it is finished, Imran messages her: “The Instagram link in the footer is broken, and posters go out tomorrow!” Without branches, Asha would have half-finished sponsor code mixed with the urgent fix. With branches, she keeps them apart:

# Monday: Asha starts the sponsors section
git switch main
git switch -c feature/sponsors
git add sponsors.html
git commit -m "Add sponsors page with logo grid"

# Tuesday: Imran reports a broken footer link. Asha leaves
# her sponsors work where it is and starts a fix from main
git switch main
git switch -c fix/footer-links
git add index.html
git commit -m "Fix Instagram link in footer"

# Back to the sponsors work, exactly where she left it
git switch feature/sponsors
git branch

The last command shows:

  fix/footer-links
* feature/sponsors
  main

Her history now has two separate lines of work, both starting from main:

                       F          fix/footer-links
                      /
main:        A---B---C
                      \
                       D---E      feature/sponsors

The footer fix can go into main today, while the sponsors page waits until it is ready. Neither one disturbs the other.

Try these changes:

1. Run git log --oneline --graph --all to see every branch drawn in the terminal.
2. Create a branch called experiment/dark-theme, change a colour, commit, then delete it with git branch -D.
3. Switch between two branches with VS Code’s status bar and watch the Explorer update.

Common Mistakes

• Working on main by accident. You make three commits and then notice the status bar says main. Fix: always check git branch or the status bar before you start. Make it a habit to run git switch -c before writing new code.
• Creating a branch from the wrong place. A new branch starts from the commit you are on. If you are on feature/sponsors and run git switch -c fix/footer-links, the fix also carries the unfinished sponsors work. Fix: run git switch main first.
• Thinking switching deleted your files. Files from another branch disappear from the folder, but they are safe in Git. Switch back and they return.
• Switching with uncommitted changes. Git may refuse, or it may carry the changes with you to the other branch, which is confusing. Fix: commit before switching.
• Using -D without thinking. Capital -D deletes unmerged work. Use small -d by default and read the error if Git refuses.

Practice Task: A Gallery Branch

The fest team wants a photo gallery page. Build it on its own branch, in your own college-fest-site project (or any project with at least one commit).

# Starting point: your college-fest-site project with at least one commit on main
cd college-fest-site
git switch main
git status

1. Make sure you are on main.
2. Create and switch to a branch called feature/gallery.
3. Create gallery.html with a simple page and commit it.
4. Make one more small change to it and commit again.
5. List your branches and view the history with git log --oneline --graph --all.
6. Switch to main and check that gallery.html is not in the folder. Switch back and see it return.
7. Create a branch called practice/test and delete it.

# 1. Make sure you start from main
cd college-fest-site
git switch main

# 2. Create the branch and move onto it
git switch -c feature/gallery

# 3. Create gallery.html in VS Code, save it, then commit
git add gallery.html
git commit -m "Add photo gallery page"

# 4. Change the heading in gallery.html, save, commit again
git add gallery.html
git commit -m "Add heading to gallery page"

# 5. See your branches and the history
git branch
git log --oneline --graph --all

# 6. Go back to main: gallery.html disappears from the folder
git switch main
ls

# 7. Come back: the file returns
git switch feature/gallery
ls

# 8. Create and delete a practice branch
git switch main
git branch practice/test
git branch -d practice/test

Key Takeaways

• A branch is a movable label on a commit, not a copy of your files, so branches are cheap and fast.
• Keep main clean and working. Do every new feature or fix on its own branch.
• git switch -c name creates a branch and moves you to it. git switch name moves to an existing one.
• Use clear names like feature/registration-form and fix/footer-links.
• Switching changes the files in your folder. Commit before you switch.
• Delete merged branches with git branch -d to keep the list tidy.