Advanced Git Mastery – First edition 2025

Once you're comfortable with the basics and intermediate Git concepts, it's time to unlock Git's full potential. This guide is packed with expert-level features, clean examples, and real-world workflows that will supercharge your version control skills and team collaboration.

1. Rebase vs Merge – What’s the Difference?

• Merge combines histories by creating a new "merge commit."

• Rebase rewrites history by moving your branch on top of another.

Example:

# Merge
git checkout feature
git merge main

# Rebase
git checkout feature
git rebase main

Use Rebase for cleaner, linear history.
Use Merge to preserve the actual branch history.

Simple Example:

Imagine you’re building a tower of blocks (main branch).

• Merge = You add a new block on top that says "merged feature."

• Rebase = You take your blocks and stack them neatly on top of the latest main tower, as if you built them there from the start.

2. Interactive Rebase (git rebase -i)

This lets you clean up commits before merging into the main branch.

Example:

git rebase -i HEAD~3

You’ll get:

pick 123abc Add login form
pick 456def Fix typo
pick 789ghi Add validation

Change to:

pick 123abc Add login form
squash 456def Fix typo
squash 789ghi Add validation

It combines multiple commits into one!

Real-Life Example: Blocks and Rebase -i

Imagine you’ve built a small tower of 3 blocks:

1. Add login form

2. Fix typo

3. Add validation

These blocks are your commits.

Now you realize:

"Hmm... all these blocks are part of one feature, the login system. I should combine them into one clean block before adding it to the main tower."

3. Cherry-Picking Specific Commits

git cherry-pick lets you copy a single commit from one branch to another, without merging the entire branch.

Real-Life Example (Building a House):

Imagine you and your friend are building different rooms of a house:

• You're working on the kitchen branch

• Your friend is working on the living-room branch

One day, your friend adds a beautiful ceiling light in their branch (it's one commit).

You think:

“Hey! That ceiling light would look great in my kitchen too!”

Instead of merging the entire living-room changes (which might include unrelated furniture), you just want that one ceiling light commit.

You Do:

git checkout kitchen
git cherry-pick a1b2c3

Where a1b2c3 is the commit ID for the ceiling light.

Now, that exact change is copied into your kitchen branch!

4. Git Hooks – Automate with Pre-commit and Post-commit

Git lets you run scripts at specific points via hooks. Example: run tests before commit.

Example:

Create a file:

touch .git/hooks/pre-commit

Edit the file and add:

#!/bin/sh
php artisan test

This tells Git: "Before every commit, run the test suite."

Make it executable

chmod +x .git/hooks/pre-commit

Now What Happens?

Every time you run:

Git will:

1. Run php artisan test

2. If tests pass → commit goes through

3. If tests fail → commit is blocked

5. Git Submodules – Managing Dependencies

Sometimes, your project depends on another repository, like a shared library or plugin, that lives in a separate Git repo.

Git submodules let you add that repo into your project while keeping it separate and version-controlled.

Real-Life Example: Building with LEGO Kits

You're building a LEGO castle. But instead of building the horse stable from scratch, you decide to buy a separate LEGO horse kit.

• Main castle = your main project (main repo)

• Horse stable kit = shared module (external repo)

• You place the horse stable inside your castle, but it’s still a separate box you can update or replace anytime.

That’s what a submodule is!

How to Use It

Step 1: Add the submodule

git submodule add https://github.com/example/lib-utils.git libs/utils

Step 2: Initialize and pull submodule

git submodule update --init

This downloads the actual code into your project.

Key Points:

• Submodules point to a specific commit of the external repo, not the latest one.

• If the original library updates, your project won’t auto-update, you choose when to update it.

• It’s still a separate Git repo, inside your repo.

6. Understanding HEAD, Index, and Working Directory

Think of Git as a 3-layer system

• Working Directory

• Index (Staging Area)

• HEAD

1. Working Directory (Your Current Work)

This is where you edit your files.

You’re writing a document in Word or coding in VS Code, this is your working area*. The changes are only on your computer for now.*

2. Index (Staging Area)

This is where you prepare changes before saving them in history.

You finish writing one section of your report and put it in a "Ready to Print" folder. It’s not printed yet, but it’s ready*.*

You run:

git add file.txt

Now that file is staged (put into the Index).

3. HEAD (Last Commit – Git History)

This is your latest saved version in Git, the last commit you made.

Your report was printed yesterday, that’s the HEAD version. If someone asks, “What did you last submit?”, you’ll give them the HEAD copy.

View the Differences:

git status

This tells you:

• What’s changed but not staged

• What’s staged but not committed

• What’s already in the HEAD (last commit)

So every time you work with Git, you’re moving files between these 3 layers:

1. Modify (Working Directory)

2. Stage with git add (Index)

3. Save with git commit (HEAD)

Final Thoughts

Git is more than just version control, it's a toolbox for collaboration, automation, and code safety. Mastering these advanced tools can drastically improve your efficiency, team collaboration, and confidence during critical development tasks.

Missed the basics? Git for Beginners
Or continue from intermediate level: Git Intermediate Guide
Or continue from advanced level Part 1: Git Advanced Guide Part 1
Or continue from advanced level Part 2: Git Advanced Guide Part 2