Making Commits on a Branch

You've learned how to create branches using git branch <branch-name> and how to switch your working focus to a different branch using git switch <branch-name> (or the older git checkout <branch-name>). Remember, switching branches changes which commit the special HEAD pointer refers to, and it updates the files in your working directory to match the snapshot of that commit.

So, what happens when you make changes after switching to a new branch? The process is exactly the same standard Git workflow you learned in Chapter 2: you modify files, stage those changes using git add, and then record a snapshot using git commit.

The significant point here is context. When you run git commit, Git creates a new commit object whose parent is the commit that HEAD was pointing to before the commit. Since HEAD now points to the tip of your current branch, the new commit extends the history of only that branch. Other branches remain completely unaware and unaffected by these new commits until you decide to merge them (which we'll cover soon).

Think of it like this: creating and switching to a new branch creates a parallel timeline for your project. Commits made on this new branch add events to its specific timeline, leaving the original timeline (like the main branch) untouched.

Let's visualize this. Imagine you start with a couple of commits on your main branch. Then, you create a new branch called feature and switch to it.

Initially, both main and the new feature branch point to the same commit (C1). HEAD points to feature because that's the branch you switched to.

Now, if you make a change, add it, and commit it while on the feature branch:

# (Assuming you are on the 'feature' branch)
# Edit a file, for example, add content to 'feature_details.txt'
echo "Working on the new feature" > feature_details.txt
git add feature_details.txt
git commit -m "Start developing feature X"

Git creates a new commit (let's call it C2) whose parent is C1. The feature branch pointer is moved forward to point to this new commit C2. The main branch pointer does not move.

The feature branch has advanced to commit C2, while main remains at C1. HEAD still follows feature.

If you were to switch back to the main branch (git switch main) and make a different commit (say, C3, fixing a bug), that commit would be added after C1 on the main branch's timeline, completely independent of C2 on the feature branch.

git switch main
# Switched to branch 'main'
# Edit a different file, e.g., fix something in 'main_code.py'
echo "print('bug fixed!')" > main_code.py
git add main_code.py
git commit -m "Fix critical bug on main"
# Now HEAD points to main, which points to C3

The history now looks like this, with two independent lines of development after C1:

Commit history has diverged. C2 is only on the feature branch, and C3 is only on the main branch. HEAD points to main.

You can always see this branching structure using git log with some helpful options:

git log --oneline --graph --all

• --oneline: Shows each commit as a single line (commit hash and message).
• --graph: Draws a text-based graph showing the branch and merge history.
• --all: Shows commits from all branches, not just the current one.

The output will visually represent the divergence, similar to the diagrams above.

This isolation is fundamental to the power of Git branches. You can work on a new feature or fix a bug on its own branch without worrying about destabilizing the main codebase or interfering with work happening on other branches. Each branch captures an independent sequence of commits based on a common starting point. Later, you'll learn how to bring these independent histories back together using git merge.