# Git cheat sheet: branching, merging & rebasing

> Git branching cheat sheet: create, switch and delete branches, merge vs rebase, cherry-pick and resolving conflicts — verified against the official docs.

- Page URL: https://itinsighthub.com/git/branching/
- Markdown variant of this page: append `?format=md` to any URL on this site or send `Accept: text/markdown`.
- Full site index for AI assistants: https://itinsighthub.com/llms.txt
- Full site export: https://itinsighthub.com/llms-full.txt

# Git cheat sheet: branching, merging & rebasing

A branch is just a movable pointer to a commit, and creating one costs nothing — which is why the feature-branch workflow (one branch per task, merged back when done) is the default everywhere. `HEAD` points to the branch you are on, and switching branches moves HEAD.

The three verbs you need: **branch** to create, **switch** to move, **merge** (or **rebase**) to bring changes back together. Everything below uses `git switch`, the focused replacement for the overloaded `git checkout` that shipped in Git 2.23.

Published August 22, 2026

## Create, switch and delete

The branch commands, modern and legacy spelling

```
# List local branches (current is starred)
git branch

# Create a branch (without switching to it)
git branch feature/login

# Create AND switch to a branch — modern
git switch -c feature/login

# Create AND switch — legacy spelling (same result)
git checkout -b feature/login

# Switch to an existing branch
git switch main

# Delete a merged branch (safe) vs delete an unmerged branch (force)
git branch -d feature/login
git branch -D feature/login
```

git switch and git checkout -b are equivalent for these cases; the difference is that checkout also restores files (now the job of git restore), so splitting the two commands removes ambiguity. -d refuses to delete a branch whose commits are not merged (a safety check); -D overrides it.

## Merge vs rebase

Two ways to combine a branch — the difference is the shape of history

- **git merge :** joins the branch into the current one with a merge commit, preserving the true history and both branches' timelines
- **git merge --ff-only:** only fast-forwards (moves the pointer) and refuses to create a merge commit — keeps history linear when possible
- **git rebase main:** replays your commits on top of main's tip, rewriting them to produce a linear history with no merge commits
- **git cherry-pick :** copies a single commit from another branch onto the current one without merging the branch

The classic rule: rebase local, merge shared. Rebasing rewrites commit IDs, so it is safe for branches no one else has pulled, but rebasing a pushed branch forces everyone else to reconcile. Merge is always safe because it only adds commits. Fast-forwarding (the default when no extra commits exist on the base) simply moves the branch pointer forward with no new commit.

The feature-branch workflow, step by step

```
# Start from an up-to-date main
git switch main
git pull

# Create a branch for the work
git switch -c feature/login

# ...edit and commit several times...
git add .
git commit -m "Add login form"
git commit -am "Wire up validation"   # -a stages tracked files, -m sets the message

# Bring the feature back into main
git switch main
git merge feature/login
git push

# Clean up
git branch -d feature/login
```

## Interactive rebase and cherry-pick

Rewrite your own unpublished history

```
# Interactively rewrite the last 3 commits (pick, squash, reword, drop...)
git rebase -i HEAD~3

# Squash all commits since main into one clean commit
git rebase -i main

# Copy one specific commit from another branch
git cherry-pick a1b2c3d

# Copy a range (a..b], excluding a
git cherry-pick a1b2c3d..e4f5g6h
```

Interactive rebase opens an editor listing each commit with a command: pick (keep as-is), reword (edit the message), squash (fold into the previous commit) and drop (remove). This is how you tidy up a branch before sharing it — and another reason to rebase only unpushed work.

## Resolving conflicts

A merge conflict, then resolving it

```
# Merge stops with a conflict:
git merge feature/login
# CONFLICT (content): Merge conflict in src/app.js

# See only the conflicted files
git status

# After editing the file to keep what you want, mark it resolved:
git add src/app.js

# Finish the merge
git commit

# Abort instead, if you want to walk away:
git merge --abort
```

Conflict markers inside a conflicted file are <<<<<<< (your version), ======= (the separator) and >>>>>>> (the incoming version). Remove all three markers and keep the lines you want, then git add the file — Git treats a staged file as resolved. git merge --abort (or git rebase --abort mid-rebase) restores the pre-merge state.

## References

- [git-branch](https://git-scm.com/docs/git-branch) — the official branch reference including -d and -D.
- [git-switch](https://git-scm.com/docs/git-switch) — the focused branch-switching command introduced in Git 2.23.
- [git-rebase](https://git-scm.com/docs/git-rebase) — replaying and interactively rewriting commits.

## FAQ

**What is the difference between git merge and git rebase?**

git merge joins a branch into the current one, creating a merge commit that records both timelines — history stays exactly as it happened. git rebase re-applies your branch's commits one by one on top of the target branch, producing a straight, linear history but rewriting those commits' IDs. Merge is always safe; rebase is for tidying local, unpublished work.

**Should I rebase or merge a feature branch?**

Merge is the safe default, especially for shared or long-lived branches, because it never rewrites history. Rebase is a good choice for a short-lived, unpushed feature branch when you want a clean linear history on main. The widely used rule of thumb: rebase local work, merge shared work.

**How do I rename a branch?**

git branch -m renames the branch, or git branch -m renames the current branch. If the branch was pushed, delete the old remote branch with git push origin --delete and push the new one with git push -u origin .

**How do I abort a merge or rebase that went wrong?**

git merge --abort returns to the state before the merge started, and git rebase --abort does the same mid-rebase. Both are safe because they discard only the in-progress operation, not your existing commits.

**What does git cherry-pick do?**

It copies the changes of a single commit from another branch onto your current branch, creating a new commit with a different hash. Use it to move one fix across branches without merging the whole branch. The command is git cherry-pick .

## Related tools

- [IPv4 subnet calculator](https://itinsighthub.com/subnet-calculator/) — break any CIDR block into network, range, broadcast and usable hosts.
- [IP range to CIDR](https://itinsighthub.com/ip-range-to-cidr/) — turn an arbitrary address range into its minimal covering CIDR blocks.
- [VLSM calculator](https://itinsighthub.com/vlsm-calculator/) — split a block into right-sized subnets by host requirements.

---

© 2026 ITInsightHub · [About](https://itinsighthub.com/about/) · [Contact](https://itinsighthub.com/contact/) · [Privacy](https://itinsighthub.com/privacy/)