Skip to main content
PacketMentor logo
Open menu
← All topics
Automation & Programmability Foundational

Git Branches, Merge and Conflicts for Network Engineers

A branch is a parallel universe. This topic covers clone, branch, switch, merge, handling conflicts and diff: everything in Cisco's 1.8 Git objectives, in plain English with a browser lab.

Quick summary
  • A branch is a parallel line of commits. Default is 'main'. Make a new one when you want to try something risky.
  • git switch -c <name> creates and jumps into a new branch. git switch main goes back. git merge <name> brings your work in.
  • Merge conflict = Git cannot pick a winner because the same line changed on both sides. You open the file, keep what you want, remove the markers, commit.

Mental model

Think of your repository as a tree. The trunk is main. A branch is a new line that splits off from main, grows on its own, and can either be merged back in or thrown away. Nothing on main is touched while you work on a branch.

For a network engineer this matters because:

  • Try a risky playbook change without breaking what everyone else is using.
  • Work on three unrelated fixes at the same time, one branch each.
  • When a change goes bad, delete the branch; main is untouched.
  • Reviewers can look at your branch in isolation before anything hits main.

Cisco objective 1.8 (CCNAAUTO 200-901) asks you to use clone, add, remove, commit, push, pull, branch, merge, handling conflicts, and diff. The git basics topic covered add, commit, push, pull and log. This topic covers the rest: clone, branch, merge, conflicts and diff.

Getting someone else’s repo: git clone

git clone https://github.com/example/net-scripts.git

That one command downloads the whole repository (including every commit ever made) into a new folder called net-scripts. You can now cd net-scripts and start working as if you had made the repo yourself.

Clone is how you start on any shared project at work. The remote (origin) is already configured, so git push and git pull just work.

Making a branch

Create and switch to a new branch in one command:

git switch -c add-interface-check

Modern Git uses git switch. Older guides use git checkout -b add-interface-check which does exactly the same thing. The lab accepts both.

Switch between branches:

git switch main
git switch add-interface-check

See all branches:

git branch

The branch with the * in front is the one you are currently on.

Doing work on a branch

Everything is the same as working on main: edit files, git add, git commit. The difference is that your commits only exist on this branch until you merge.

echo "show interfaces status" >> commands.txt
git add commands.txt
git commit -m "add interface check"

If you git switch main right now, you will NOT see your change. The file goes back to how main has it. That is Git’s magic: branches live side by side without stepping on each other.

Merging back

When your branch work is good, bring it back to main:

git switch main
git merge add-interface-check

If main has not moved since you branched off, Git does a fast-forward merge: it just slides the main pointer up to your branch’s latest commit. No merge commit needed.

If main has moved (someone else committed), Git does a three-way merge and creates a merge commit that joins the two histories. Still automatic as long as the changes do not touch the same lines.

Delete the branch after it is merged in:

git branch -d add-interface-check

Handling merge conflicts

A merge conflict happens when the same line in the same file was changed on both branches. Git cannot pick a winner, so it stops and asks you.

The file looks like this after a conflicted merge:

server1.example.com
<<<<<<< HEAD
server2-prod.example.com
=======
server2-staging.example.com
>>>>>>> add-staging
server3.example.com

The lines between <<<<<<< HEAD and ======= are what main had. The lines between ======= and >>>>>>> add-staging are what your branch had. Decide what you want (keep one, keep both, write something new), DELETE all three marker lines, save the file, then:

git add commands.txt
git commit

The commit message prefills with a merge message. Keep it or edit it. Done.

Three rules of thumb:

  • Pull often (git pull on main before you branch) to keep conflicts small.
  • Short-lived branches have fewer conflicts than long-lived ones.
  • When in doubt, ask the person whose change is in HEAD or in the incoming branch what their intent was. Do not guess.

Seeing differences: git diff

git diff

Shows what has changed in your working directory but is not yet staged.

git diff --staged

Shows what IS staged (ready to commit) vs the last commit.

git diff HEAD~1 HEAD

Shows what the latest commit changed compared to the one before it.

git diff main add-interface-check

Shows what is different between two branches. Useful before you merge.

Lines prefixed with - were removed; lines prefixed with + were added. Context lines around each change help you orient.

Hands-on lab · 6 minute walkthrough

Branch, commit, switch, merge, delete, diff

10 scripted steps in a real terminal. Clone a repo, create a feature branch, make a commit on it, switch back to main, merge the branch in, delete it, read the log and the diff.

Zero install. No network. No GitHub account.

Open the lab →
git-branches · lab
you@laptop:~/net-scripts$ git switch -c add-interface-check
Switched to a new branch 'add-interface-check'
(add-interface-check)$ git commit -m "add interface check"
[add-interface-check 7c2e1f0] add interface check
(add-interface-check)$ git switch main
Switched to branch 'main'
(main)$ git merge add-interface-check
Fast-forward
(main)$

The #1 mistake

Working directly on main for weeks and then trying to merge. The longer a branch lives, the more conflicts it has with main, and the harder the merge gets. If main changed under you a thousand times, you now have a thousand opportunities for conflicts.

Rules that work:

  • One branch per task. Finish the task, merge, delete the branch. Hours or days, not weeks.
  • git pull on main before you branch, so you start from the latest.
  • git pull on main regularly while on your branch and git merge main into your branch (or git rebase main) to keep it current.

FAQ

What is the difference between git switch and git checkout? git switch was added in Git 2.23 (2019) specifically to make branch switching clear. git checkout is older and does both branch switching and file restoration, which confused new users. Both work; use git switch in new scripts.

What happens to my uncommitted changes when I switch branches? Git carries them with you if they do not conflict with the target branch. If they would conflict, Git refuses to switch and you have to commit, stash (git stash), or discard first.

When should I git merge main into my branch vs git rebase main? Merge is safe and preserves history exactly. Rebase makes a cleaner linear history but rewrites your branch’s commits (new hashes). On a solo branch, rebase is fine. On a shared branch, prefer merge. Teams usually have a convention; follow it.

What does HEAD mean? HEAD is a pointer to the commit you currently have checked out. On a branch, HEAD moves with every commit you make. HEAD~1 is “one commit before HEAD”, HEAD~2 is two before, and so on.

My merge got stuck. How do I abort? git merge --abort returns everything to the state before the merge started. Safe to run any time during a conflict.

Can I rename a branch? Yes. git branch -m new-name renames the current branch. Add -m old-name new-name to rename a branch you are not on.

Master this on a real network

Want this drilled into reflex?

1:1 weekly sessions, live feedback on your labs, and US interview prep: built around the CCNA Automation® exam blueprint. Free first session. No card on file until you decide.

Claim my free session →

Get the free CCNA 12-week roadmap

You're already reading up on Git Branches, Merge and Conflicts for Network Engineers. The roadmap is the order I recommend studying every CCNA topic in: with what to lab each week and where Git Branches, Merge and Conflicts for Network Engineers fits. A written personal reply, not an autoresponder. Expect it within one business day.

Personal reply from a senior network engineer. No third-party tracking. Unsubscribe any time.