< _

Git Branching Explained: Feature Branch to Master

Abstract generated cover for Git Branching Explained: Feature Branch to Master.

Git branches sound more complicated than they are. A branch is just a movable pointer to a commit. That definition is accurate, but it is not always useful when you are trying to get work done. The practical version is this:

A branch gives you a separate place to make changes before they are added back to the main line of work. If your main branch is `master`, a normal workflow looks like this:

  1. Start from an up-to-date `master`
  2. Create a feature branch
  3. Make changes
  4. Commit the changes
  5. Push the branch
  6. Merge it back into `master` That is the basic loop.

The Mental Model

Think of `master` as the version of the project that should stay working. A feature branch is a temporary workspace. ```plain text master: A---B---C \ feature: D---E

Commits \`D\` and \`E\` are your work. They are not on \`master\` yet.
When the feature is ready, the branch gets merged:
```plain text
master:  A---B---C-------M
              \         /
feature:       D---E----

`M` is the merge commit, or the branch may be fast-forwarded depending on the history. The exact shape does not matter as much as the rule:

Work on a branch. Keep `master` clean.

Start From an Updated Master

Before creating a branch, switch to `master` and pull the latest changes.

git switch master
git pull

If you are working alone, this is usually simple. If other people are contributing, this step matters because you want your branch to start from the newest shared work. You can check your state with:

git status

This command is one of the best habits in Git. Run it often.

Create a Feature Branch

Create a new branch with a clear name:

git switch -c add-blog-card-layout

Good branch names are specific: ```plain text fix-login-redirect add-notion-sync-script update-homepage-images

Weak branch names are vague:
```plain text
changes
stuff
new-work
final-fix

The branch name should give future you a clue about what happened.

Make Changes and Review Them

After editing files, check what changed:

git status
git diff

`git status` tells you which files changed. `git diff` shows the actual line changes. This is where you catch accidental edits before committing. Maybe you changed a debug value, generated a build file, or edited a file you did not mean to touch. Do not skip this step.

Stage and Commit

Once the changes look right, stage them:

git add path/to/file

Or stage multiple files:

git add src/site dev-tools

Then commit:

git commit -m "Add blog card layout"

A commit should be one understandable unit of work. That does not mean every commit needs to be tiny. It means the commit should have a clear reason to exist.

Push the Branch

Push your branch to GitHub:

git push -u origin add-blog-card-layout

The `-u` connects your local branch to the remote branch. After that, future pushes can usually be:

git push

At this point, the branch exists both on your machine and on GitHub.

Merge Back to Master

There are two common ways to merge back:

  • open a pull request on GitHub
  • merge locally from the command line For a local merge:
git switch master
git pull
git merge add-blog-card-layout
git push

On GitHub, the pull request flow gives you a chance to review the diff before merging. Even on solo projects, pull requests can be useful when you want a clean review checkpoint.

Keeping Another Machine Updated

If you have the same project on another machine, the usual command is:

git pull

Run it from the project directory while on the branch you want to update. For example:

git switch master
git pull

If Git says you have local changes, stop and inspect them with:

git status

That means your local checkout has edits that Git does not want to overwrite.

Common Mistakes

Mistake 1: Working directly on master

This is fine for tiny personal changes, but it gets messy quickly. Feature branches make it easier to separate work and undo experiments.

Mistake 2: Forgetting to pull before starting

If `master` is stale, your branch starts from old code. That can create unnecessary conflicts later.

Mistake 3: Committing generated files accidentally

Build output, cache files, and local environment files usually should not be committed. Check `git status` and `git diff` before committing.

Where This Shows Up in Real Projects

Branches are useful even on a personal site. You might have one branch for article layout, another for Notion sync, and another for image handling. Each branch can be finished, tested, and merged separately. That keeps Git history easier to understand. It also makes it much easier to pull the project onto another machine without dragging along half-finished local edits.

Key Takeaways

  • A branch is a separate line of work.
  • Start branches from an updated `master`.
  • Use `git status` constantly.
  • Commit reviewed changes, not random local state.

  • Push and merge only when the branch is ready.

    Related Articles

  • Git Rebase vs Merge Explained

  • Terminal Tools I Actually Use
  • Setting Up a Mac for Development

← Back to Blog Index