I Thought I Knew Git—Until I Started Using It Like a Senior Engineer

It was a Tuesday morning, and I was neck-deep in a codebase I barely recognized. I needed answers, and fast. I typed git log into my terminal, hoping for clarity. What I got instead? A firehose of meaningless hashes and timestamps.

That's when it hit me: I wasn’t using Git wrong—but I wasn’t using it like a senior engineer either.

Let me tell you a story.

📜 Chapter 1: The Ugly Truth About git log

The first time I ran git log, I felt like I had opened Pandora’s box. Yes, technically, all the information was there. But it was like trying to read a novel where every sentence was from a different chapter.

Then I stumbled across something that changed everything:

git log --graph --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%an%C(reset)%C(bold yellow)%d%C(reset) %C(dim white)- %s%C(reset)' --all

I ran it. My terminal lit up like Times Square.

Suddenly, there was structure—a tree-like visual that showed branches and merges. Names, dates, tags. I could see the story of the repo unfold.

It felt like Neo seeing the Matrix.

🔎 Chapter 2: Decoding the Past, One Commit at a Time

I needed to know why a certain bug was showing up. Time to investigate a specific commit.

I ran:

git show <commit> --stat

Boom. A clean summary. File names, line changes, everything I needed at a glance.

But sometimes, you want to go deeper. Like, “line-by-line forensic analysis” deeper:

git show <commit> -- <filepath>

This command? It felt like cracking open a sealed envelope. I wasn’t just reading history—I was understanding it.

⚔️ Chapter 3: Merge Conflicts, My Old Enemy

I had a feature branch. I was proud of it.

Then I opened a pull request—and saw the red: Merge Conflict.

Another developer had touched the same files. The battlefield was set. I had two weapons: git merge and git rebase.

Option 1: Merge

git merge origin/main

It would bring the changes in and leave a merge commit—a clear marker that said, “This is where we handled things.”

Option 2: Rebase

git rebase origin/main

This one rewrites history. Makes it look like I branched off later, after those other changes were already there. Clean, elegant—but dangerous if not handled right.

Merging felt honest. Rebasing felt poetic. I chose based on the situation, like a warrior picking the right weapon for the battle.

🤔 Chapter 4: To Squash or Not to Squash?

For years, I squashed my commits like a bug in production. I believed in clean history, like a polished résumé.

Then I read an article by Dr. Derek Austin.

He argued for the value of messy commit history—how it told the story of development, of exploration, of real work being done.

And you know what? He had a point. I stopped squashing so blindly. Now I ask: what story do I want this branch to tell?

🎯 The Moral of the Story

Git isn’t just a tool. It’s a time machine, a map, a collaboration language, and a battlefield.

Using Git like a senior engineer doesn’t mean memorizing more commands. It means asking better questions:

• What do I want to see?
• What story am I trying to understand?
• What do I want to communicate to the next developer?

Master that mindset—and you’ll never look at git log the same way again.

For more detail: - Medium

If this story helped you level up your Git game, follow me for more developer war stories and tooling wisdom. 🧠💻