DEV Community

Cover image for How Junior and Senior Developers Use Git: A Story of Two Mindsets
Raj Aryan
Raj Aryan

Posted on • Edited on

How Junior and Senior Developers Use Git: A Story of Two Mindsets

Avi—six months into his first dev job—opens his laptop to a sea of sticky notes: “fix login,” “dark mode,” “merge Sam’s changes???” He takes a breath and types:

git pull
git add .
git commit -m "fixed stuff"
git push
Enter fullscreen mode Exit fullscreen mode

At the next desk, Meera—staff engineer and the team’s quiet Git whisperer—types a single command and smiles:

git switch -c feat/theme-toggle
Enter fullscreen mode Exit fullscreen mode

They’re working on the same codebase. They both know Git. But they use it very differently. This is a story about mindset more than commands—how a junior and a senior developer approach version control, and what you can learn to level up faster.


Scene 1: Starting the Work

Avi (Junior):
He works directly on main, because that’s where “the latest code” lives. He pulls, edits files, and makes one catch-all commit. When a merge conflict appears, he scrolls until it compiles and pushes. The goal is speed—get it working, move on.

Meera (Senior):
She starts by naming the work:

git fetch --prune
git switch -c feat/theme-toggle origin/main
Enter fullscreen mode Exit fullscreen mode
  • Branch naming: feat/, fix/, chore/ so others can scan intent.
  • Isolation: Separate branch per task to reduce blast radius.
  • Fast feedback: Small, focused changes are easier to review and roll back.

Mindset difference: Juniors often see Git as backup. Seniors see Git as a communication tool. Every branch name, commit, and tag tells a story to future readers.


Scene 2: Making the Change

Avi:
He edits multiple files—CSS tweaks, a stray console.log, and the theme toggle logic—then commits everything:

git add .
git commit -m "fix"
Enter fullscreen mode Exit fullscreen mode

One commit, vague message. It works locally. Ship it?

Meera:
She commits intentionally:

git add src/theme/toggle.tsx
git commit -m "feat(theme): add toggle component with persisted state"
git add src/styles/theme.css
git commit -m "style(theme): define CSS variables for light/dark"
Enter fullscreen mode Exit fullscreen mode
  • Atomic commits: Each does one thing.
  • Conventional messages: feat(scope):, fix(scope): for changelogs and CI rules.
  • Guardrails: She uses a pre-commit hook (via pre-commit or Husky) to run tests and linting.
# example pre-commit
npm test --silent
eslint . --max-warnings=0
Enter fullscreen mode Exit fullscreen mode

Mindset difference: Juniors commit when done. Seniors commit to explain the journey: why this change exists, what it affects, how to revert it cleanly.


Scene 3: Syncing With the Team

Avi:
Time to push:

git push origin main
Enter fullscreen mode Exit fullscreen mode

Remote rejects the push: “non-fast-forward.” He pulls. Conflicts. He edits until it builds. Another push. A reviewer asks for tests. He changes files again, force-pushes to fix a mistake in history.

Meera:
She syncs frequently without disrupting others:

git fetch origin
git rebase origin/main
# resolve conflicts, test
git push -u origin feat/theme-toggle
Enter fullscreen mode Exit fullscreen mode

She opens a PR with a checklist: purpose, screenshots, test plan, fallback, and risk notes. CI runs linting, unit tests, and accessibility checks. Reviewers focus on logic, not whitespace.

Mindset difference: Juniors treat conflicts as interruptions. Seniors anticipate them and integrate often to keep deltas small.


Scene 4: The Merge Strategy

Avi:
The PR has 27 changed files and a single “fix” commit. Review is slow. He merges with a squash to hide the messy history.

Meera:
Before merge, she uses an interactive rebase to polish:

git rebase -i origin/main
# squash tiny fixups, edit commit messages
Enter fullscreen mode Exit fullscreen mode

The final log reads like a table of contents:

feat(theme): add toggle component with persisted state
style(theme): add CSS variables and prefers-color-scheme support
test(theme): add unit tests for reducer and storage
docs: update README with theme usage
Enter fullscreen mode Exit fullscreen mode

She merges with --no-ff when the team wants a visible merge commit (useful for release notes) or squashes if the policy prefers one commit per feature. The key is intentionality.

Mindset difference: Juniors think in terms of “get it in.” Seniors think in terms of “how will someone debug this in six months?”


Scene 5: The Emergency Hotfix

3 PM. A production error appears: dark mode crashes on Safari.

Avi:
He patches main directly (again), tries a quick commit, and hopes the CI is green.

Meera:
She cuts a hotfix branch from the release tag:

git fetch --tags
git switch -c hotfix/theme-safari v2.4.1
Enter fullscreen mode Exit fullscreen mode

She reproduces, writes a failing test, fixes, and then:

git tag -a v2.4.2 -m "hotfix: prevent null CSS var on Safari"
git push --tags
Enter fullscreen mode Exit fullscreen mode

She cherry-picks the fix into main to keep branches aligned:

git switch main
git cherry-pick <hotfix-commit-sha>
git push
Enter fullscreen mode Exit fullscreen mode

Mindset difference: Juniors patch where they stand. Seniors anchor to tags, cut hotfix branches, and cherry-pick to maintain a clean, auditable chain.


Scene 6: When Things Go Really Wrong

Avi:
After a bad rebase, his branch seems lost. Panic sets in.

Meera:
She reaches for the time machine:

git reflog
# find the last known good HEAD
git reset --hard HEAD@{3}
Enter fullscreen mode Exit fullscreen mode

Or, to find the commit that introduced a bug:

git bisect start
git bisect bad
git bisect good v2.4.1
# Git guides through a binary search until the culprit appears
Enter fullscreen mode Exit fullscreen mode

Mindset difference: Juniors fear Git’s depth. Seniors rely on it. Tools like reflog and bisect are their compass and map.


Scene 7: Collaboration and Reviews

Avi:
His PR descriptions are short: “added dark mode.” He pushes commits like “fix” and “wip”. Reviewers guess at context, ask for changes, and the cycle drags.

Meera:
She writes the PR like a tiny product doc:

  • Problem: “Dark mode state wasn’t persisted across reloads.”
  • Solution: “Introduce themeReducer, localStorage persistence, and CSS vars.”
  • Scope: “No API changes; CSS variables backward compatible.”
  • Testing: “Unit tests + manual Safari/iOS checks.”
  • Risk: “Low; fallback to light mode if storage fails.”

She responds to comments with commits that reference them:

git commit -m "fix(theme): handle undefined storage (#842 review)"
Enter fullscreen mode Exit fullscreen mode

Mindset difference: Juniors see review as a gate. Seniors use it as a design conversation captured in history.


Scene 8: Automation and Guardrails

Avi:
His local environment sometimes differs from CI. He forgets to run tests or prettier. Inconsistent results lead to “works on my machine.”

Meera:
She codifies the rules:

  • Branch protection: Require PR reviews and green checks.
  • Status checks: Linting, unit tests, type checks, Lighthouse.
  • Pre-push hook: Run quick sanity tests.
# .git/hooks/pre-push (or via Husky)
npm run typecheck && npm test
Enter fullscreen mode Exit fullscreen mode

She also uses CODEOWNERS to route reviews and commitlint to enforce message conventions. Git becomes a quality pipeline, not just a history log.


Scene 9: Releases That Tell a Story

Avi:
He deploys from whatever is on main, asks in Slack what changed, and writes a minimal changelog.

Meera:
She uses semantic versioning and annotated tags:

git tag -a v2.5.0 -m "feat: theme toggle + accessibility fixes"
git push --tags
Enter fullscreen mode Exit fullscreen mode

A release note is generated from conventional commits. The history is a product narrative: what shipped, why it matters, how to roll back.


What Juniors Can Borrow Today

If you’re early in your journey, you don’t need all the tricks at once. Start with a few habits that deliver outsized value:

  1. Create a branch for every task. git switch -c feat/short-intent
  2. Make small, atomic commits with descriptive messages. “fix(auth): handle null token on refresh” is gold.
  3. Rebase before you push, push often. Keep diffs small; conflicts stay friendly.
  4. Write PRs for humans. Problem → Solution → Scope → Testing → Risk.
  5. Learn three rescue commands. git reflog, git reset --hard <sha>, git cherry-pick <sha>.
  6. Tag releases. Your future self (and ops) will thank you.

Epilogue

At 5:30 PM, Avi peeks at Meera’s terminal. Her commit log reads like chapters in a book. There are no heroics, no force-push drama—just careful steps, each one named, tested, and explained.

“Teach me that rebase thing?” he asks.

Meera nods and opens the editor.
“Git isn’t about memorizing commands,” she says. “It’s about telling a clear story—so your teammates, your future self, and your users never get lost.”

And that’s the real difference: Juniors use Git. Seniors design with it.


Handy Cheat Sheet

# Start clean work
git fetch --prune
git switch -c feat/scope origin/main

# Commit intentionally
git add <files>
git commit -m "feat(scope): single, clear change"

# Sync safely
git fetch origin
git rebase origin/main
git push -u origin feat/scope

# Polish before merge
git rebase -i origin/main

# Hotfix flow
git switch -c hotfix/issue vX.Y.Z
# ...fix...
git tag -a vX.Y.(Z+1) -m "hotfix: summary"
git push --tags
git cherry-pick <sha>  # back to main
Enter fullscreen mode Exit fullscreen mode

Adopt the mindset, not just the commands. Your Git history will become a living document of craftsmanship—and your team will move faster with far fewer surprises.

If you're a developer looking to level up your skills, I highly recommend checking this out:

👉 GitHub for Dummies (by Phil Haack Sarah Guthals)
👉 Beginning Git and GitHub (by Mariot Tsitoara)
I’ve personally found it helpful and thought it could be useful for many in the GitHub/dev community as well. 🚀

(affiliate link — it helps support my content at no extra cost to you!)

Top comments (12)

Collapse
 
er-raj-aryan profile image
Raj Aryan

Glad you found this useful 🙌! For anyone who wants to dive deeper, I’ve also added a list of recommended books that really helped me boost my knowledge and mindset as a developer. 📚 These aren’t just about coding, but also about thinking, communicating, and growing in your career. Definitely worth checking out! 🚀

Collapse
 
dillionhuston profile image
Dillion Huston

Really enjoyed this breakdown, Raj. The way you highlighted the differences in mindset between junior and senior developers, especially in the context of Git workflows, was spot on. It's easy to get caught up in the technicalities, but understanding the 'why' behind our practices is what truly sets us apart.

Your insights on branching strategies and commit messages resonated with me. It's something I’ve been working on improving in my own workflow. Looking forward to more of your posts!

Collapse
 
er-raj-aryan profile image
Raj Aryan

Thank you so much for the kind words 🙏. I’m really glad the breakdown resonated with you — especially on the mindset shift from junior to senior developers. You’re absolutely right: understanding the why behind Git practices is what makes us better engineers, not just following commands mechanically.

Collapse
 
suvrajeet profile image
Suvrajeet Banerjee

Awesome breakdown! 🎉

Collapse
 
er-raj-aryan profile image
Raj Aryan

Thanks a ton! 🎉 Really glad you enjoyed the breakdown. Your support keeps me motivated to share more deep dives like this 🚀🙌

Collapse
 
anik_sikder_313 profile image
Anik Sikder

This really hits the mindset difference! 🚀 Knowing Git commands isn’t enough, thinking in terms of communication, clarity, and history is what separates a junior from a senior. Love how Meera treats every commit like a story future devs can read.

Collapse
 
er-raj-aryan profile image
Raj Aryan

Exactly! 🚀 You nailed it — Git isn’t just about commands, it’s about communicating with your future team (and even your future self). Every commit becomes part of the project’s story, and the way Meera approaches it shows how powerful clear, thoughtful commit history can be. Glad this resonated with you — I think more devs need to view Git as a narrative tool, not just a technical one. 🙌

Collapse
 
radiant1 profile image
ONOH UCHENNA PEACE

This is nice

Collapse
 
er-raj-aryan profile image
Raj Aryan

Thanks for your kind words

Collapse
 
zuoan_ling_7f9c8549b25792 profile image
zuoan ling

I will embrace this change.

Collapse
 
er-raj-aryan profile image
Raj Aryan

That’s awesome to hear 🙌! Embracing this mindset will make your Git history so much more valuable — both for you and your teammates. 🚀 Small consistent changes in commit habits add up to a huge impact over time. Keep at it, you’ll notice the difference quickly!

Collapse
 
publicspace profile image
Donovan Martinez

I needed this. Thank you

Some comments may only be visible to logged-in visitors. Sign in to view all comments.