Git from a Veteran Developer: Mental Models, Battle Scars, and Habits That Saved My Work
Early in my career, whenever the terminal flashed `CONFLICT (content): Merge conflict in...`, my pulse jumped to 120. I would copy the folder onto my desktop, run `git stash` with fingers crossed, and hope nothing vanished into thin air. If you have ever kept a folder named `project_final_v2_really_final`, know that you are not alone. Almost every seasoned engineer went through that rite of passage.
The trouble is that most tutorials treat Git like magical spells: "Type this incantation, then that one, then push." Until you understand what is actually going on under the hood, any unexpected edge case will freeze you. Here is the realistic mental model and the habits that kept my sanity across years of production work.
---
1. The Mental Model that Clicked: Git Does Not Store Diffs
The single biggest breakthrough in understanding Git is realizing that **Git does not store differences between files (deltas); it stores full snapshots of your project.**
Think of each commit as a Polaroid picture of your entire project at that exact moment: * If a file has not changed, Git does not duplicate it; it simply points back to the existing file in its internal object database. * The commit SHA-1 hash is an immutable fingerprint of the tree plus the hash of the parent commit. This graph structure makes history durable and auditable.
Once you see this, you understand what a **branch** really is. A branch is not a duplicated folder of code! In Git, a branch is merely a 41-byte text file under `.git/refs/heads/` that holds the 40-character commit hash it points to. Creating or deleting a branch is instantaneous and essentially free.
---
2. Atomic Commits: Saving Yourself at 2 AM
A common trap is waiting until the end of the sprint to dump all work into one giant commit: ```bash git commit -m "fixed issues and updated design and bugfix" ``` When a production regression strikes two days later, you cannot isolate or revert that single bug fix without undoing three other unrelated features.
The rule of **atomic commits**: * Each commit does one focused thing and does it completely. * The test suite must pass on every individual commit. * The commit message should explain **why** the change was made, not just describe the diff that `git show` already displays.
Pro-tip: Instead of blindly running `git add .`, use `git add -p`. It steps through file chunks (hunks) interactively, letting you stage refactoring separately from a critical logic fix.
---
3. Rebase vs. Merge: Practical Rules over Dogma
Online discussions often turn rebase vs. merge into a religious debate. In real teams:
* **Local Private Branches:** Use `git rebase -i` freely to squash typo fixes and draft commits before publishing your pull request. Clean history respects your team's review time. * **Shared Public Branches:** **Never rebase a branch that other teammates are pulling from.** Rebase rewrites commit hashes, which creates divergent duplicate histories for anyone else collaborating on that branch. Use explicit merges for shared integration branches.
---
4. Git Reflog: Almost Nothing is Ever Lost
Accidentally ran `git reset --hard HEAD~3` and watched your unpushed commits disappear? Don't panic. ```bash git reflog ``` While `git log` only traverses the active branch's ancestry, `reflog` is Git's flight recorder. Every time `HEAD` moves (commit, checkout, rebase, reset), Git records the previous position.
Find the commit hash right before your blunder, and restore it: ```bash git branch rescue-branch HEAD@{1} ``` As long as changes were committed at least once, Git keeps the loose objects around for weeks before garbage collection touches them.
---
5. Small Branches, Rapid Feedback
A branch that sits open for a month with 200 modified files is a ticking conflict bomb. The cognitive overhead of reviewing code scales exponentially with the diff size. Keep branches short-lived: split features into manageable pull requests, automate lint and tests in CI, and merge daily.
Mastering Git is not about memorizing flags; it is about building a clear mental model so you can work fearlessly.
