A branch is just a movable label on a commit. Once you see that, branching, merging and conflicts become much less scary. Includes the exact commands for each step.

Many people use Git for months and still feel nervous when it is time to merge. The word “branch” suggests something heavy, like making a full copy of your project. It is not. A branch in Git is tiny, and creating one takes a split second.

By the end you will be able to:

  • Explain what a branch is using the simplest possible picture.
  • Create a branch, commit to it, and merge it back.
  • Read and fix a merge conflict without guessing.
  • Know when rebase is a reasonable alternative.

A branch is just a label

Git stores your project as a chain of commits, each one pointing to the one before it. A branch is nothing more than a name that points at one commit. When you make a new commit, the name moves forward to it.

That is why branching is instant. Git does not copy any files. It adds a new label.

main keeps going on its own line. The feature branch splits off and grows separately.

Create a branch and work on it

Say you want to add a login page without disturbing the working code on main. Make a branch, switch to it, and commit as normal:

terminal
git switch main
git pull
git switch -c feature/login-page

# edit files, then:
git add .
git commit -m "Add login form"
git push -u origin feature/login-page

git switch -c means “create this branch and move onto it”. To see where you are, run git status or git branch. The branch with a star is your current one.

Merge it back

When the work is finished and reviewed, you bring it back into main with a merge. Switch to the branch you want to receive the changes, then merge the other one in:

terminal
git switch main
git pull
git merge feature/login-page
git push
A merge ties both histories together with a new commit that has two parents.

If main has not moved since you branched, Git simply slides the label forward. This is called a fast-forward and there is no merge commit at all.

Merge conflicts, step by step

A conflict happens when two branches changed the same lines of the same file and Git cannot decide which one wins. It is not an error in your work. It is Git asking a question only a human can answer.

Git pauses the merge and marks the file like this:

login.js
<<<<<<< HEAD
const title = "Sign in";
=======
const title = "Log in to DeveloperJar";
>>>>>>> feature/login-page

Everything between <<<<<<< and ======= is your current branch. Everything between ======= and >>>>>>> is the incoming branch. Decide what the final line should be, delete the three marker lines, and save.

  1. Run git status to see which files are in conflict.
  2. Open each one, pick or combine the right lines, and remove the markers.
  3. Run git add on every file you fixed.
  4. Run git commit to finish the merge.
  5. Run your tests. A conflict fixed badly still compiles sometimes.

Merge or rebase?

You will hear people argue about this. Both bring changes together. They differ in the history they leave behind.

MergeRebase
What it doesJoins two histories with a merge commitReplays your commits on top of the latest main
History looks likeBranchy, but true to what happenedOne straight line
Rewrites commits?NoYes, they get new IDs
Safe on shared branches?YesNo. Only rebase work that is just yours

A friendly rule: merge when in doubt, and only rebase a branch that nobody else has pulled. Your team may also have a preferred style, so check before you pick.

Habits that keep branching painless

  • Keep branches short lived. The longer they live, the bigger the conflicts.
  • Pull from main into your branch often so you meet conflicts in small pieces.
  • Name branches by purpose: fix/null-user, feature/export-csv.
  • Delete branches after they are merged: git branch -d feature/login-page.