Mastering Git:- Advanced Concepts

Introduction

In the previous article, we explored Git basics like creating a repository, committing changes, and pushing to a remote. If you’re familiar with those steps, you’re ready to move forward. This post is a practical journey through advanced Git concepts—presented in a real-world order and explained clearly so even beginners can follow along and start applying them with confidence.

1. Branching and Merging (Including Merge Strategies)

Start here: branching is the foundation of collaboration in Git.

Branches are like parallel versions of your project. You use them to develop features or fixes independently from the main line of work (main or master).

Create and Switch to a Branch

1

git checkout -b feature-login

You’re now on a new branch called feature-login. Make your changes and commit as usual.

Merging Back into Main

Once done, switch back to main and merge your changes:

1
2

git checkout main
git merge feature-login

Now, let’s understand how Git decides how to merge:

Fast-Forward Merge

If no one else updated main while you were working, Git just moves the branch pointer. This creates a clean, straight history.

1

git merge feature-login

You’ll see no extra commit.

True Merge Commit

If main has new commits since you branched off, Git will create a merge commit:

1

git merge feature-login

This preserves both histories and shows exactly when the feature branch was merged.

Octopus Merge

Used when merging multiple unrelated branches at once:

1

git merge bugfix docs refactor

All branches are merged if there are no conflicts. Ideal for housekeeping tasks.

“Ours” Merge Strategy

When you want to ignore the incoming branch’s changes but still record the merge:

1

git merge -s ours legacy-code

Useful when deprecating a branch while preserving its history.

2. Rebasing for a Clean History

Rebasing rewrites the base of your branch so your changes appear as if they were made on top of the latest main branch.

This helps keep history linear and clean.

How to Rebase

1
2

git checkout feature-login
git rebase main

Git replays your commits on top of main, one by one.

If a conflict happens:

  1. Git will pause and let you fix the conflict.
  2. After fixing, stage the changes:
1

git add .
  1. Continue rebasing:
1

git rebase --continue

After the rebase is complete, you may need to force-push your branch:

1

git push --force-with-lease

When to Use It

Use rebase before opening a pull request to avoid unnecessary merge commits and simplify the project history.

3. Squashing Commits (Clean Up Before Merging)

When you’re developing a feature, it’s common to make several small commits—some meaningful, others like “fix typo” or “style update.” Before merging your branch or creating a pull request, it’s a good idea to squash those commits into one or two well-structured commits. This keeps the commit history clean and easier for your team to review.

How to Squash Commits

Let’s say you’ve made 5 commits. To squash them:

1

git rebase -i HEAD~5

This opens an interactive editor showing your last 5 commits. You’ll see something like:

1
2
3
4
5

pick a1b2c3 Add login page
pick d4e5f6 Fix layout
pick g7h8i9 Add validation
pick j1k2l3 Fix typo
pick m4n5o6 Update button style

Change all but the first pick to squash (or simply s):

1
2
3
4
5

pick a1b2c3 Add login page
squash d4e5f6 Fix layout
squash g7h8i9 Add validation
squash j1k2l3 Fix typo
squash m4n5o6 Update button style

Save and close the editor. Git will prompt you to write a new commit message. You can edit or combine the messages from the squashed commits.

What to Do Next

Once saved, you’ll have a single commit. Push it using:

1

git push --force-with-lease

This ensures your remote branch reflects your cleaned-up commit history, making code review easier.

4. Git Tags for Versioning

Tags are markers you place on specific commits—usually to indicate versions or releases. They make it easy to refer to key milestones in your project.

Creating a Tag

1

git tag v1.0

This tags the current commit with v1.0. If you want to tag a previous commit:

1

git tag v1.0 <commit-hash>

Sharing Tags with Others

Tags aren’t pushed by default. To share them:

1

git push origin v1.0

Or push all tags:

1

git push --tags

When to Use Tags

Use tags for marking release points like v1.0, v2.1-beta, or release-2024-01. They’re useful when deploying or debugging a specific version.

5. Cherry-Picking Specific Changes

Sometimes, you only want one commit from another branch—not the whole thing. Cherry-picking helps you grab and apply that specific commit wherever needed.

Real Example

Let’s say your teammate fixed a bug on the hotfix branch, and you need that fix in your release branch.

1
2

git checkout release
git cherry-pick <commit-hash>

This applies the changes from that commit onto your current branch.

Handling Conflicts

If conflicts arise during the cherry-pick:

1
2

git add .
git cherry-pick --continue

After it finishes, test your branch to make sure the cherry-picked change integrates well.

6. Stashing Work in Progress

You’re mid-task when an urgent bug appears in another branch. But your current work isn’t ready to be committed. Use git stash to quickly save your changes and switch branches without losing progress.

How to Stash

1

git stash

This stores your uncommitted changes temporarily and resets your working directory.

Now you can switch branches:

1

git checkout main

Applying Stashed Work

When you’re ready to resume:

1

git stash list

Find your stash entry (e.g., stash@{0}), then apply it:

1

git stash apply stash@{0}

If you no longer need it after applying:

1

git stash drop stash@{0}

Or pop it (apply and remove in one go):

1

git stash pop

Custom Named Stash

Give your stash context:

1

git stash save "WIP: redesign navbar"

This makes it easier to recall why you stashed something.

7. Reflog for Recovery

Reflog tracks where your Git references (like HEAD or branch pointers) have been—even after operations like reset or rebase. It helps you recover lost commits that aren’t visible in the regular git log.

View the Reflog

1

git reflog

You’ll see a list of recent HEAD movements with commit hashes. Example:

1
2
3

0f1c2d1 HEAD@{0}: reset: moving to HEAD~1
a2b3c4d HEAD@{1}: commit: Fix navbar alignment
...

Recover a Lost Commit

If you accidentally reset or deleted a branch:

1

git checkout -b recovery-branch <commit-hash>

Git usually retains reflog entries for 90 days (by default).

8. Bisecting to Find Bugs

Git Bisect is a tool that uses binary search to help you find the exact commit that introduced a bug. It’s efficient when you have many commits between a known good and bad state.

Starting Bisect

1
2
3

git bisect start
git bisect bad       # Current commit has the bug
git bisect good v1.0 # v1.0 was working fine

Git now checks out a middle commit. You test your code:

  • If the bug is present:
1

git bisect bad
  • If the bug is not present:
1

git bisect good

Repeat the process. Git will continue narrowing it down.

End Bisect

Once Git identifies the problematic commit:

1

git bisect reset

Use this commit’s hash to inspect or revert the change as needed.

9. Worktrees for Parallel Work

Worktrees let you have multiple working directories from the same Git repo. This is useful when you want to check out different branches at the same time without cloning the repo again.

Create a New Worktree

1

git worktree add ../feature-login feature-login

This checks out the feature-login branch into a new directory one level above the current one.

Switch Between Worktrees

Just navigate into each folder and work independently. Changes in one don’t affect the other.

List All Worktrees

1

git worktree list

Remove a Worktree

1

git worktree remove ../feature-login

Final Thoughts

Git is powerful, but it doesn’t have to be overwhelming. By mastering these commands step-by-step and applying them in real-world scenarios, you’ll grow more confident in managing code and collaborating with others.

Next up, we’ll explore working with remotes: pushing, pulling, managing remotes, and contributing to shared projects.

Stay curious, keep experimenting—and Git better every day!