Git Mastery: Branching, Rebasing & GitHub Workflows

Git is the distributed version control system that underpins almost every modern software team's workflow. Unlike older centralized systems (CVS, SVN), every clone of a Git repository is a full copy of the project's history — there is no single point of failure, and nearly every operation (branching, committing, diffing, browsing history) happens instantly on your local machine, offline.

This guide covers Git the way it's actually used on a production team: the object model that makes branching cheap, the day-to-day commands for branching, merging, and rebasing, how to resolve a real merge conflict under time pressure, the GitHub workflows (fork-and-PR vs. trunk-based with protected branches) teams build around it, and the habits — signed commits, disciplined .gitignoreuse, never rewriting shared history — that keep a team's history trustworthy instead of a source of dread.

Who this is for

• Engineers who know git add/commit/push but freeze at a rebase conflict.
• Anyone about to work on a shared feature branch with a team for the first time.
• Developers preparing for Git-heavy technical interviews.

You should have the following before working through the commands in this guide:

Git Architecture: the object model

Everything Git tracks is stored as one of four object types in the .git/objects database, each addressed by the SHA-1 (or SHA-256, on newer repos) hash of its content:

Because objects are addressed by content hash, identical file content anywhere in the repository — across commits, across branches — is stored exactly once. A commit doesn't store a diff; it stores a full snapshot (a tree), and Git computes diffs on demand by comparing trees. This is why git log -p can be slow on huge repos but git checkout between commits is fast.

The commit graph is a DAG

Commits form a directed acyclic graph (DAG): each commit points backward to its parent(s). A normal commit has one parent; a merge commit has two (or more). This graph structure is what makes operations like git log --graph, git merge-base, and three-way merges possible — Git can always find the common ancestor of any two commits by walking the graph.

A branch is just a pointer

This is the single most important mental model in Git: a branch is not a copy of the code. It is a 41-byte text file in .git/refs/heads/ containing the SHA of one commit. git branch feature-x creates a new pointer at the current commit — an O(1) operation regardless of repo size. Committing on a branch simply moves that pointer forward to the new commit. HEAD is itself a pointer — almost always a symbolic pointer to the branch you have checked out (refs/heads/main, for example), which is how Git knows which branch to advance when you commit.

Git data moves through four distinct areas as you work. Understanding these boundaries is what makes commands like git add, git commit, and git restore --staged click:

• Working directory — the actual files on disk you edit. Git compares these against the index to compute git status and git diff.
• Staging area (the index) — a snapshot-in-progress. git add copies working-directory changes here; this is what the next commit will contain.
• Local repository — the committed history in .git, private to your machine until pushed.
• Remote repository — a copy hosted elsewhere (GitHub, GitLab) thatgit push/git fetch/git pull synchronize with.

Install Git for your platform, then set your identity before making any commits:

sudo apt update
sudo apt install git -y
git --version

# Identity used on every commit you make
git config --global user.name "Ranjith R"
git config --global user.email "you@example.com"

# Sane defaults
git config --global init.defaultBranch main
git config --global core.editor "vim"
git config --global pull.rebase false

# Confirm everything
git config --list

Repository: init vs. clone

git init creates a brand-new, empty repository (a fresh .git directory) in the current folder — used when starting a project from scratch. git clonecopies an existing remote repository's full history to your machine and automatically wires up origin as the remote name.

# Start a brand-new project
mkdir my-app && cd my-app
git init

# Copy an existing project, including all history
git clone git@github.com:acme/my-app.git
git clone https://github.com/acme/my-app.git

# Clone only recent history (faster for huge repos)
git clone --depth 1 git@github.com:acme/my-app.git

.git internals, briefly

Everything Git needs lives inside the .git directory — delete it and the folder is just plain files with no history. Key pieces:

.gitignore and remotes

node_modules/
.env
.env.local
dist/
*.log
.DS_Store

# View, add, and change remotes
git remote -v
git remote add origin git@github.com:acme/my-app.git
git remote set-url origin git@github.com:acme/my-app-renamed.git

# Useful per-repo aliases
git config alias.st status
git config alias.lg "log --oneline --graph --decorate --all"

Branch

git branch creates or lists pointers; git switch (or the older checkout) moves HEAD to point at one.

git branch                       # list local branches
git branch feature/checkout-flow # create a branch, stay where you are
git switch feature/checkout-flow # move HEAD to that branch
git switch -c feature/new-thing  # create + switch in one step
git checkout -b feature/new-thing # older equivalent of switch -c
git branch -d feature/checkout-flow   # delete (safe, blocks if unmerged)
git branch -D feature/checkout-flow   # delete (force)
git branch -m old-name new-name       # rename

Merge: fast-forward vs. three-way

If the target branch hasn't diverged (no new commits since the feature branch was created), Git performs a fast-forward — it just moves the pointer forward, no new commit created. If both branches have diverged, Git creates a three-way merge commit with two parents, using the common ancestor to compute what changed on each side.

git switch main
git merge feature/checkout-flow          # fast-forward if possible
git merge --no-ff feature/checkout-flow  # always create a merge commit
git merge --abort                        # bail out of a conflicted merge

Rebase

Rebase replays your branch's commits one by one onto a new base commit, producing linear history instead of a merge commit. Interactive rebase additionally lets you reorder, squash, reword, or drop commits before they land.

git switch feature/checkout-flow
git rebase main                     # replay this branch's commits onto main
git rebase -i HEAD~5                # interactively edit the last 5 commits
git rebase --onto main old-base feature/x  # replay a range onto a new base
git rebase --continue               # after resolving a conflict mid-rebase
git rebase --abort                  # bail out, restore original branch state

Cherry-pick

Apply one specific commit from another branch onto your current branch:

git cherry-pick a1b2c3d          # apply a single commit here
git cherry-pick a1b2c3d..f9e8d7c # apply a range (exclusive of first)
git cherry-pick --continue       # after resolving a conflict
git cherry-pick --abort

Stash

Shelve uncommitted work temporarily without committing it, e.g. to switch branches:

git stash push -m "wip: payment retry logic"
git stash list
git stash show -p stash@{0}
git stash pop            # re-apply and remove from the stash list
git stash apply          # re-apply but keep it in the stash list
git stash drop stash@{0}
git stash -u              # include untracked files

Reset: --soft, --mixed, --hard

git reset --soft HEAD~1   # undo last commit, keep changes staged
git reset HEAD~1          # (--mixed) undo commit + staging, keep edits
git reset --hard HEAD~1   # discard the commit and all its changes entirely
git reset HEAD~1 -- file.txt   # unstage a single file

Revert

Unlike reset, git revertdoesn't rewrite history — it creates a new committhat undoes a previous one. This makes it the safe choice for undoing something that's already been pushed and shared.

git revert a1b2c3d          # create a commit undoing a1b2c3d
git revert --no-commit a1b2c3d..HEAD  # revert a range, stage without committing yet

Tag

A lightweight tag is just a named pointer to a commit. An annotated tag is a full Git object with its own message, tagger, date, and optional GPG signature — use annotated tags for releases.

git tag v1.2.0                              # lightweight
git tag -a v1.2.0 -m "Release 1.2.0"        # annotated
git tag -s v1.2.0 -m "Release 1.2.0"        # annotated + GPG-signed
git push origin v1.2.0                       # push a single tag
git push origin --tags                       # push all tags
git tag -d v1.2.0 && git push origin :refs/tags/v1.2.0  # delete local + remote

A full feature branch lifecycle, from creation to a merged pull request:

Scenario: two engineers both edited src/lib/pricing.ts — one on feature/discount-codes, one already merged to main. Rebasing the feature branch produces a conflict.

• Write commit messages in the imperative mood ("add", not "added") with a short summary line and a blank line before any body detail.
• Commit small, logically complete units of work — it makes review, git bisect, and reverts precise instead of all-or-nothing.
• Pull with rebase (git pull --rebase) on your own feature branches to avoid noisy merge-of-merge commits in history.
• Never rewrite history on a branch others have already pulled — see the golden rule of rebasing.
• Keep main always deployable; do all work on short-lived feature branches merged via reviewed pull requests.
• Tag every release with an annotated tag so git describe and changelogs have a stable reference point.

• Sign your commits — git config --global commit.gpgsign true with a GPG or SSH signing key gives GitHub a verified badge and proves authorship.
• Protect the main branch — require pull requests, passing status checks, and at least one approving review before merge; disallow direct pushes and force-pushes on GitHub's branch protection rules.
• Never commit secrets — API keys, .env files, and credentials belong in a secrets manager, not source control; scan history with tools like gitleaks or trufflehog before it ships.
• Maintain .gitignore discipline — commit a sensible .gitignore from day one; a secret committed once still exists in history even after a later commit deletes it.
• Use a credential helper, not plaintext tokens — git config --global credential.helper (or an OS keychain) stores credentials securely; never paste a personal access token into a remote URL that gets committed anywhere.

Git's entire feature set follows from one idea: content-addressed objects (blobs, trees, commits) linked into a DAG, with branches as cheap, movable pointers into that graph. Once that clicks, merge, rebase, cherry-pick, reset, and revert all read as different ways of moving pointers and replaying or combining snapshots rather than separate tricks to memorize. Layer a GitHub workflow — protected main, required reviews, feature branches — on top, and the same primitives scale from a solo project to a large team without the history turning into chaos.

• Official Git documentation and the free Pro Git book — git-scm.com
• GitHub Docs — pull requests, Actions, branch protection — docs.github.com
• Interactive branching visualizer — learngitbranching.js.org
• Atlassian's Git tutorials (merge vs. rebase, workflows) — atlassian.com/git
• Oh Shit, Git!?! — plain-English fixes for common mistakes — ohshitgit.com