Branches

You now have a project with two commits. Suppose you want to add something experimental. If you work directly on main and it goes wrong, your main line is messy. A branch lets you work on the side.

Step 1: Make a branch and switch to it

$ git switch -c shout
Switched to a new branch 'shout'
$ git branch
  main
* shout

git switch -c shout creates a branch named shout and moves you onto it (-c means "create"). git branch lists branches, and the * marks the one you are on. Nothing changed in your files yet: both labels point at the same commit.

Step 2: Commit on the branch

Create a new file shout.txt containing HELLO, GIT, then:

$ git add shout.txt
$ git commit -m "Add shout.txt"
$ git log --oneline --graph --all
* 6a9ba55 Add shout.txt
* 99b5742 Describe the repository
* 29194b2 Add hello.txt

The shout label moved forward to the new commit. The main label stayed where it was. That is the picture from Part 2. (--graph draws the commit chain with *, and --all includes every branch.)

Step 3: Go back and notice what happens

$ git switch main
Switched to branch 'main'
$ ls
hello.txt

shout.txt is gone from your folder. It is not lost. Git changed your working folder to match the main branch, which does not have that file yet. Switch back to shout and it reappears. This is the idea that surprises beginners most, and it is how branches stay separate.

Step 4: Bring the work back with a merge

You are happy with the experiment, so merge it into main. You must be on the branch that receives the work:

$ git merge shout
Updating 99b5742..6a9ba55
Fast-forward
 shout.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 shout.txt
$ ls
hello.txt  shout.txt

Fast-forward means main had no new commits of its own, so Git just moved the main label forward to the same commit. Now delete the branch label you no longer need:

$ git branch -d shout
Deleted branch shout (was 6a9ba55).

Only the label is deleted. The commits stay in main's history.