Git Advanced on Software Engineering Learning Paths

Git Internals

Mon, 01 Jan 0001 00:00:00 +0000

Git Internals#

Understanding how Git stores and manages data transforms you from someone who memorises commands into someone who truly understands the tool. Git is fundamentally a content-addressable filesystem with a version control interface built on top.

The .git Directory Anatomy#

When you run git init, Git creates the .git directory — the entire repository lives here:

.git/
├── HEAD # Points to the current branch ref
├── config # Repository-specific configuration
├── description # Used by GitWeb (rarely relevant)
├── hooks/ # Client-side and server-side hook scripts
├── info/ # Global exclude patterns
├── objects/ # All content (blobs, trees, commits, tags)
│ ├── info/
│ └── pack/ # Packed objects for efficiency
├── refs/ # Pointers to commit objects
│ ├── heads/ # Branch tips
│ ├── tags/ # Tag references
│ └── remotes/ # Remote-tracking branches
├── index # Staging area (binary file)
└── logs/ # Reflog history

Component	Purpose	Human-readable?
`HEAD`	Current branch pointer	Yes — contains `ref: refs/heads/main`
`objects/`	Content store (all versions of all files)	No — compressed binary
`refs/`	Named pointers to commits	Yes — contains SHA-1 hashes
`index`	Staging area snapshot	No — binary format
`logs/`	History of ref changes	Yes — one entry per line

The Four Object Types#

Git stores everything as one of four object types, each identified by a 40-character SHA-1 hash:

Rebase Workflows

Mon, 01 Jan 0001 00:00:00 +0000

Rebase Workflows#

Rebase is Git’s most powerful history-editing tool. It replays commits onto a new base, creating a linear history that’s easier to read and bisect. But with great power comes great responsibility — rewriting shared history can cause serious collaboration problems.

Rebase vs Merge#

Both integrate changes from one branch into another, but they produce different histories:

gitGraph
 commit id: "A"
 commit id: "B"
 branch feature
 commit id: "C"
 commit id: "D"
 checkout main
 commit id: "E"
 checkout feature
 commit id: "F"

After Merge (`git merge feature`)#

gitGraph
 commit id: "A"
 commit id: "B"
 branch feature
 commit id: "C"
 commit id: "D"
 checkout main
 commit id: "E"
 checkout feature
 commit id: "F"
 checkout main
 merge feature id: "M"

After Rebase (`git checkout feature && git rebase main`)#

gitGraph
 commit id: "A"
 commit id: "B"
 commit id: "E"
 commit id: "C'"
 commit id: "D'"
 commit id: "F'"

Aspect	Merge	Rebase
History shape	Non-linear (preserves branches)	Linear (straight line)
Original commits	Preserved exactly	Replaced with new commits (new SHAs)
Merge commits	Creates one	None
Conflict resolution	Once (in merge commit)	Per-commit (during replay)
Traceability	Full branch history visible	Branch topology lost
Safety for shared branches	Safe	Dangerous — rewrites history

The Golden Rule of Rebase#

Never rebase commits that have been pushed to a shared branch.

Reflog & Recovery

Mon, 01 Jan 0001 00:00:00 +0000

Reflog & Recovery#

The reflog is Git’s safety net — a local log of every position your HEAD and branch refs have pointed to. Even after a destructive operation, the reflog usually holds the key to recovery.

What the Reflog Tracks#

The reflog records every time a ref (HEAD, branch, etc.) changes value. Each entry contains:

The old and new SHA of the ref
A timestamp
The action that caused the change
A message describing what happened

# View HEAD reflog
git reflog
# or equivalently:
git reflog show HEAD

# View a specific branch's reflog
git reflog show main

# View with timestamps
git reflog --date=iso

Example output:

Advanced Branching

Mon, 01 Jan 0001 00:00:00 +0000

Advanced Branching#

Beyond basic branching, Git offers powerful tools for parallel development, automated debugging, selective commit application, and efficient handling of large repositories.

Worktrees — Parallel Development#

A worktree is an additional working directory linked to the same repository. Instead of stashing or committing WIP to switch context, you open another worktree:

# Create a new worktree for a branch
git worktree add ../project-hotfix hotfix/urgent-fix

# Create a worktree with a new branch
git worktree add -b feature/new-thing ../project-feature main

# List all worktrees
git worktree list
# /home/user/project abc1234 [main]
# /home/user/project-hotfix def5678 [hotfix/urgent-fix]
# /home/user/project-feature 9ab0123 [feature/new-thing]

# Remove a worktree (after you're done)
git worktree remove ../project-hotfix

# Prune stale worktree references
git worktree prune

Worktree Rules#

Rule	Reason
Each worktree must be on a different branch	Git can’t have two worktrees on the same ref
All worktrees share the same `.git` objects	Storage efficient — no duplicate history
Commits in one worktree are immediately visible in others	Single object store
Don’t `git checkout` into a branch used by another worktree	Fails with an error

When to Use Worktrees#

Reviewing a PR while your current branch has uncommitted work
Running a long build on one branch while developing on another
Comparing behaviour between two branches simultaneously
Hotfixes that can’t wait for your current work to finish

Bisect — Binary Search for Bugs#

git bisect performs a binary search through history to find which commit introduced a bug:

Submodules & Subtrees

Mon, 01 Jan 0001 00:00:00 +0000

Submodules & Subtrees#

When a project depends on code from another repository, Git offers two main strategies: submodules (linked pointer to an external repo) and subtrees (merged copy of an external repo). Each has distinct trade-offs for dependency management, monorepo architecture, and team workflows.

Submodules#

A submodule is a reference to a specific commit in another repository. The parent repo stores only the URL and commit SHA — not the actual files.

Hooks & Automation

Mon, 01 Jan 0001 00:00:00 +0000

Hooks & Automation#

Git hooks are scripts that run automatically at specific points in the Git workflow. They enable quality gates, enforced conventions, and automated workflows — all without requiring developers to remember manual steps.

How Hooks Work#

Hooks live in .git/hooks/ and execute at predefined trigger points. They are:

Executable scripts (any language — bash, Python, Node.js, etc.)
Named after their trigger (e.g., pre-commit, commit-msg)
Local by default — not committed to the repo (solved by frameworks like Husky)
Blocking — a non-zero exit code aborts the operation (for pre-* hooks)

# List available hook samples
ls .git/hooks/
# applypatch-msg.sample pre-commit.sample prepare-commit-msg.sample ...

# Enable a hook by removing .sample and making executable
cp .git/hooks/pre-commit.sample .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

Client-Side Hooks#

Hook Execution Timeline#

graph LR
 A[git commit] --> B[pre-commit]
 B --> C[prepare-commit-msg]
 C --> D[commit-msg]
 D --> E[post-commit]
 
 F[git push] --> G[pre-push]
 G --> H[post-push]
 
 style B fill:#e3f2fd
 style C fill:#e3f2fd
 style D fill:#e3f2fd
 style G fill:#e3f2fd

pre-commit#

Runs before the commit is created. Use for linting, formatting, and fast checks.

Collaboration at Scale

Mon, 01 Jan 0001 00:00:00 +0000

Collaboration at Scale#

When teams grow beyond a handful of developers, Git workflows become critical infrastructure. The right workflow reduces merge conflicts, accelerates delivery, and preserves code quality. The wrong one creates bottlenecks and frustration.

Git Workflows Compared#

GitFlow#

main ─────────●─────────────────●──────────── (releases)
 ╲ ╱
develop ────●───●───●───●───●─●──────────── (integration)
 ╲ ╱ ╲ ╱
feature/x ────●───● ╲ ╱
 feature/y ──●

Aspect	Details
Branches	main, develop, feature/, release/, hotfix/*
Merge style	Merge commits (no fast-forward)
Release cycle	Planned releases with release branches
Best for	Packaged software, mobile apps, versioned products
Drawback	Complex, long-lived branches, integration pain

GitHub Flow#

main ─────●──────●──────●──────●──────── (always deployable)
 ╲ ╱ ╲ ╱ ╲ ╱
feature ────●──● ●──● ●──●
 PR+CI PR+CI PR+CI

Aspect	Details
Branches	main + short-lived feature branches
Merge style	Squash or merge commit via Pull Request
Release cycle	Deploy on every merge to main
Best for	SaaS, web applications, continuous deployment
Drawback	Requires robust CI/CD and feature flags

Trunk-Based Development#

main ──●──●──●──●──●──●──●──●──●──── (everyone commits here)
 │ │ │ │
 small small small
 commits commits commits

Aspect	Details
Branches	main only (or very short-lived branches < 1 day)
Merge style	Direct commits or same-day PRs
Release cycle	Continuous; feature flags gate incomplete work
Best for	High-performing teams, CI/CD maturity, Google/Meta-style
Drawback	Requires excellent test coverage and feature flags

Ship / Show / Ask#

A nuanced model that categorizes changes by risk:

Troubleshooting

Mon, 01 Jan 0001 00:00:00 +0000

Git Troubleshooting#

Every Git user eventually encounters situations that seem catastrophic — lost commits, corrupted history, massive repositories, impossible merge conflicts. This chapter provides systematic solutions for the most common problems.

Common Problems and Solutions#

Undo Last Commit (Keep Changes)#

# Undo commit but keep changes staged
git reset --soft HEAD~1

# Undo commit and unstage changes
git reset --mixed HEAD~1 # default behavior of git reset HEAD~1

# Undo commit and DISCARD changes (destructive!)
git reset --hard HEAD~1

Recover Deleted Branch#

# Find the commit the branch pointed to
git reflog | grep "branch-name"
# or
git reflog --all | grep "branch-name"

# Recreate the branch
git branch recovered-branch abc1234

Accidentally Committed to Wrong Branch#

# Move last commit to correct branch
git branch correct-branch # create branch at current commit
git reset --hard HEAD~1 # remove commit from current branch
git checkout correct-branch # switch to correct branch

Amend Last Commit#

# Change message only
git commit --amend -m "corrected message"

# Add forgotten files to last commit
git add forgotten-file.txt
git commit --amend --no-edit

Warning: Never amend commits that have been pushed to a shared branch.

Git Advanced on Software Engineering Learning Paths

Git Internals

Git Internals#

The .git Directory Anatomy#

The Four Object Types#

Rebase Workflows

Rebase Workflows#

Rebase vs Merge#

After Merge (git merge feature)#

After Rebase (git checkout feature && git rebase main)#

The Golden Rule of Rebase#

Reflog & Recovery

Reflog & Recovery#

What the Reflog Tracks#

Advanced Branching

Advanced Branching#

Worktrees — Parallel Development#

Worktree Rules#

When to Use Worktrees#

Bisect — Binary Search for Bugs#

Submodules & Subtrees

Submodules & Subtrees#

Submodules#

Hooks & Automation

Hooks & Automation#

How Hooks Work#

Client-Side Hooks#

Hook Execution Timeline#

pre-commit#

Collaboration at Scale

Collaboration at Scale#

Git Workflows Compared#

GitFlow#

GitHub Flow#

Trunk-Based Development#

Ship / Show / Ask#

Troubleshooting

Git Troubleshooting#

Common Problems and Solutions#

Undo Last Commit (Keep Changes)#

Recover Deleted Branch#

Accidentally Committed to Wrong Branch#

Amend Last Commit#

After Merge (`git merge feature`)#

After Rebase (`git checkout feature && git rebase main`)#