Git Workflows: The Commands and Workflows That Senior Engineers Actually Use

Git Mastery: The Commands and Workflows That Senior Engineers Actually Use
9 views

Most developers use 10% of Git’s capabilities. They add, commit, push, and occasionally merge. Senior engineers reach for a completely different toolset: interactive rebase to clean up history before review, bisect to find which commit introduced a bug, worktrees to work on multiple branches simultaneously, and reflog to recover from any mistake. These are the commands that separate experienced engineers from beginners.

⚡ TL;DR: git rebase -i to clean history before PRs. git bisect to find which commit broke something. git reflog to recover anything. git stash with names for context-switching. git worktree for parallel branches. git blame -L to understand code history.

Interactive rebase — clean history before review — Git workflows

# Clean up last 5 commits before opening PR
git rebase -i HEAD~5

# In the editor, you can:
# pick abc123 Add user auth → keep as-is
# squash def456 Fix typo in auth → merge into previous
# squash ghi789 Fix typo again → merge into previous
# reword jkl012 Add tests → keep but edit message
# drop mno345 WIP debugging commit → remove entirely
# fixup pqr678 Minor cleanup → squash, discard message

# Result: clean history with logical commits
# Never rebase shared branches (main, develop) — only feature branches

# Squash all feature branch commits into one before merge:
git checkout main
git merge --squash feature/user-auth
git commit -m "feat: add user authentication"

git bisect — find which commit broke production

# Binary search through commits to find the one that introduced a bug
# 1000 commits? Only needs ~10 checks.

git bisect start
git bisect bad HEAD # Current commit has the bug
git bisect good v2.1.0 # This version was working

# Git checks out a commit midway between good and bad
# Test it: does the bug exist?
git bisect good # Bug not here — go forward
# or
git bisect bad # Bug here — go backward

# Repeat ~10 times. Git tells you:
# "abc1234 is the first bad commit"
# commit abc1234
# Author: Developer 
# Date: Tue Apr 1 10:23:45 2026
# "Optimize database query in user service"

git bisect reset # Return to HEAD when done

# Automate with a test script:
git bisect start HEAD v2.1.0
git bisect run npm test -- --grep "user auth" # Auto-bisects!

git reflog — recover anything

# Reflog records every HEAD movement for 90 days
# Accidentally deleted a branch? Amend the wrong commit? Hard reset?
# Reflog can recover all of it.

git reflog
# abc1234 HEAD@{0}: commit: Add feature X
# def5678 HEAD@{1}: reset: moving to HEAD~3 ← accidentally lost commits!
# ghi9012 HEAD@{2}: commit: Add feature Y
# jkl3456 HEAD@{3}: commit: Add feature Z

# Recover the commits lost in the accidental reset:
git checkout -b recovery-branch HEAD@{2}
# or:
git reset --hard HEAD@{2} # Return to that state

# Recover deleted branch:
git branch recovered-feature ghi9012 # Create branch at commit SHA

git worktree — multiple branches simultaneously

# Work on hotfix while continuing feature work — no stash needed
git worktree add ../hotfix-branch hotfix/critical-bug
# Creates a new working directory linked to same repository
# You now have two terminals:
# ~/myapp → feature/user-auth branch
# ~/hotfix-branch → hotfix/critical-bug branch

# Both share .git history — no clone overhead
# Fix the hotfix in one terminal, keep working in the other

# Remove when done:
git worktree remove ../hotfix-branch

# List worktrees:
git worktree list

git stash — named stashes for context switching

# Named stash — don't lose context when interrupted
git stash push -m "WIP: user auth validation, blocked on API spec"
git stash push -m "WIP: payment flow, waiting for QA"

# List named stashes:
git stash list
# stash@{0}: WIP: payment flow, waiting for QA
# stash@{1}: WIP: user auth validation, blocked on API spec

# Apply specific stash by name:
git stash pop stash@{1} # Apply and remove
git stash apply stash@{1} # Apply and keep in stash list

# Stash only unstaged changes (keep staged):
git stash push --keep-index

Useful aliases every senior engineer has

# Add to ~/.gitconfig [alias] section:

# Beautiful one-line log:
log1 = log --oneline --graph --decorate --all

# Show changed files in last commit:
last = log -1 HEAD --stat

# Undo last commit, keep changes staged:
undo = reset --soft HEAD~1

# Stage only parts of a file interactively:
stage = add -p

# See what will be pushed:
outgoing = log @{upstream}..HEAD --oneline

# Incoming from remote:
incoming = log HEAD..@{upstream} --oneline

# Find when a string was introduced:
pickaxe = log -S # Usage: git pickaxe "secretKey"

# Show all branches with last commit date:
branches = branch -v --sort=-committerdate

git blame and log for code archaeology

# Understand why code was written this way

# Blame specific line range:
git blame -L 45,60 src/auth/middleware.ts
# Shows commit SHA, author, date for each line in range

# Follow function across renames:
git log -L :functionName:filename.ts
# Shows every commit that touched that function

# Find all commits that changed a specific string:
git log -S "deprecated_function" --all --oneline

# Show changes to a file across all branches:
git log --all --follow --oneline -- path/to/deleted-file.ts

# See the full context of a commit:
git show abc1234 --stat # Files changed
git show abc1234 # Full diff

Git senior engineer checklist

  • ✅ git rebase -i HEAD~n before every PR — clean history saves reviewers time
  • ✅ git bisect run script — automate bug hunting in large history
  • ✅ git reflog — nothing is permanently lost within 90 days
  • ✅ git worktree — parallel branches without multiple clones
  • ✅ Named stashes with -m — never lose context again
  • ✅ git log -L :function:file — trace a function’s entire history
  • ✅ git log -S "string" — find when code was introduced
  • ❌ Never git push --force to shared branches — use --force-with-lease
  • ❌ Never rebase commits that have been pushed to shared branches

Git mastery is foundational for the debugging techniques in the API debugging guide — git bisect and git log -S are often the fastest way to trace when a production bug was introduced. External reference: Pro Git book (free online).

Related: Agentic Git Workflows: Atomic Commits From Noisy LLM Diffs · Go Concurrency Patterns: Goroutines, Channels, and the Patterns Senior Engineers Use · Redis Mastery: Caching Patterns, Data Structures, and Production Best Practices

Related: Regular Expressions Mastery: Patterns That Actually Make Sense · Linux Commands Every Developer Must Know: The 50 Commands You Use Daily · Day 79: FinOps Dashboards Engineers Open

Watch: 100 Days of AI on YouTube

Short videos from CheatCoders, one AI engineering topic per day.

Open the playlist on YouTube · CheatCoders on YouTube

Deep-dive PDF

Get the expanded guide for this post — extra diagrams-style checklists, failure modes, and a production walkthrough. Free when you subscribe to CheatCoders.

Already subscribed? or open the subscribe page.


Discover more from CheatCoders

Subscribe to get the latest posts sent to your email.

Comments

No comments yet. Why don’t you start the discussion?

Leave a comment

No account needed. Name and email are optional.