Git DAGs: Understanding the Directed Acyclic Graph

“𝐃𝐨𝐧’𝐭 𝐜𝐨𝐧𝐭𝐫𝐢𝐛𝐮𝐭𝐞 𝐭𝐨 𝐭𝐡𝐞 𝐫𝐞𝐩𝐨 𝐰𝐢𝐭𝐡 𝐝𝐢𝐫𝐭𝐲 𝐜𝐨𝐦𝐦𝐢𝐭𝐬.” Early in my career, I rushed a fix. My PR looked like this: • Initial commit • Typo fix • Debugging • Updated README 1 • Updated README 2 • Plz work • Final FINAL fix It got clumsy and junky. The lesson? 𝐌𝐞𝐬𝐬𝐲 𝐡𝐢𝐬𝐭𝐨𝐫𝐲 = 𝐦𝐞𝐬𝐬𝐲 𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠 (at least from the outside). 𝐂𝐥𝐞𝐚𝐧 𝐜𝐨𝐦𝐦𝐢𝐭𝐬 𝐛𝐮𝐢𝐥𝐝 clarity and make it easier to update features in the future. Commands every serious developer should master: → 𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡 Temporarily save your work to switch tasks instantly. → 𝐠𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 --𝐚𝐦𝐞𝐧𝐝 Fix your last commit without adding noise. → 𝐠𝐢𝐭 𝐫𝐞𝐛𝐚𝐬𝐞 -𝐢 𝐇𝐄𝐀𝐃~𝐧 Clean, reorder, or squash commits into one clear story. → 𝐠𝐢𝐭 𝐜𝐡𝐞𝐫𝐫𝐲-𝐩𝐢𝐜𝐤 Move only the changes you need (perfect for hotfixes). → 𝐠𝐢𝐭 𝐫𝐞𝐟𝐥𝐨𝐠 Your safety net — recover “lost” commits anytime. → 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 --𝐬𝐨𝐟𝐭 𝐇𝐄𝐀𝐃~𝟏 Undo last commit, keep your changes ready. → 𝐠𝐢𝐭 𝐝𝐢𝐟𝐟 Review changes before you embarrass yourself. The truth? Good developers write code. 𝐆𝐫𝐞𝐚𝐭 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐩𝐫𝐞𝐬𝐞𝐧𝐭 𝐢𝐭 𝐜𝐥𝐞𝐚𝐧𝐥𝐲. Do you clean your commit history — or ship the chaos? 👇 #BackendEngineering #Git #CleanCode #DeveloperMindset #Coding #CodingIsTherapy

Day 103. Branching and pull requests. Not flashy. But this is where real team Git lives. Spent today understanding branching properly — not just git checkout -b and hoping for the best, but why branches exist in the DAG. A branch is just a pointer. A lightweight label on a commit node. That's it. Then pull requests. A PR isn't a Git feature — it's a conversation. You're not just merging code, you're saying "hey, here's what I built, here's why, review it before it touches main." The discipline of: Branching off main cleanly Making focused commits Writing a PR description that actually explains the change ...that's the difference between a codebase you can navigate and one that's a nightmare. Still sharpening. Day 103. Consistent. #Git #DevOps #100DaysOfCode #LearningInPublic #Infracodebase

Most people use Git. Very few understand why it’s so efficient. Here’s the short explanation 👇 🧠 Git = content-based system It doesn’t store files. It stores snapshots (via hashes) Same content? → Stored once. No duplication.(deduplication) ⚙️ What happens in a commit? git commit -m "update" Behind the scenes: • Blob → file content • Tree → folder structure • Commit → snapshot + metadata Everything linked with hashes 🔗 📦 Why Git stays fast • Packfiles → bundle objects • Delta compression → store only changes Change 1 line? Git stores just that. Not the whole file. !! Without this the repose just explode !! 🔧 Hidden layer (most ignore) • Porcelain → git add, git push • Plumbing → actual engine Try this once 👇 echo "hello" | git hash-object -w --stdin You just created a Git object manually. If you understand internals → branching, rebasing, debugging becomes easy. 💡 Insight Git isn’t storing history… It’s storing connected snapshots 📚 Quick refs: https://lnkd.in/gSeM2kmA https://lnkd.in/gEMefujR Git becomes powerful the moment you stop memorizing… and start understanding ⚡ 👉 What part of Git still feels confusing to you? #Git #DevOps #Engineering #Backend — Abhishek Singh Chauhan

❌ Branches contain commits ✅ Branches just point to commits 🧠 What We Expect Most of us think: 👉 Each branch has its own commits 👉 Feature branches store separate histories 👉 Same starting commit is duplicated across branches In short: ❌ “Branches contain commits” 🔍 How Git Actually Works Git doesn’t store commits inside branches. Instead, everything lives in a Directed Acyclic Graph (DAG) 👉 A connected structure where: ⬢ Each commit points to its parent commit ⬢ History flows backward ⬢ No duplication, only relationships 🌿 What Happens in the Diagram ⬢ All commits are connected via parent relationships (PCH) ⬢ Both branches start from a common base commit (shared, not copied) ⬢ The history diverges into two paths ⬢ Each branch adds new commits on its own path 🎯 Branches & HEAD (The Most Misunderstood Part) 👉 A branch is just a pointer (label): feature-branch-1 → latest commit (blue) feature-branch-2 → latest commit (yellow) 👉 HEAD is another pointer: HEAD → current branch → commit ✔ Only one HEAD exists at a time ✔ It defines your current working position 🚀 Key Insights 1️⃣ git log moves backward using parent links From current commit: blue → orange → pink 👉 Git follows Parent Commit Hash (PCH) step by step 2️⃣ No duplicate commits across branches 👉 Both branches share the same base commit ✔ Stored once ✔ Referenced multiple times 3️⃣ Commits are globally accessible git log <commit-hash> 👉 Works from any branch ✔ Because commits belong to the graph, not a branch 4️⃣ Deleting a branch doesn’t delete commits 👉 Only the pointer is removed ✔ Commits remain in the graph ✔ Removed later by garbage collection 5️⃣ Branches are just pointers 👉 They don’t store commits 👉 They only point to the latest commit 6️⃣ Divergence = new commits, not copies From a common base: One path → green → yellow Another path → orange → blue ✔ New commits are created ❌ Old commits are never duplicated 💡 Core Idea Commits = nodes Branches = pointers (labels) HEAD = current pointer 🔥 Once this clicks, Git becomes predictable. #Git #DevOps #SoftwareEngineering #VersionControl #Backend #TechConcepts #CodeNewbie #TechEducation #CodingLife #DevCommunity #SystemDesign #SoftwareDevelopment #TechLearning

Day 25 of learning and practicing DevOps🔄 Focused on one of the important Git skill — undoing mistakes Worked on • Understanding git reset with soft, mixed and hard modes • Learning how git revert safely undoes changes without breaking history • Comparing reset vs revert in real scenarios • Exploring branching strategies like GitFlow, GitHub Flow and Trunk-Based • Understanding when to use each strategy in real projects Important part : git reset can rewrite history and even delete changes git revert creates a new commit and keeps everything safe Learning today: Reset is for local cleanup Revert is for team safety Branching strategy defines how a team builds, releases and collaborates Here are my notes https://lnkd.in/gr5CNBTU 🌐 #DevOps #Git #VersionControl #LearningInPublic #90DaysOfDevOps #TrainWithShubham

5 Git commands I wish someone had shown me on day one. Everyone teaches git add, commit, push. Nobody teaches the commands that actually save you when things go wrong. 1. git stash Shelve your uncommitted work without losing it. Switch branches cleanly, come back, and run git stash pop. Done. 2. git log --oneline --graph A visual map of your entire branch history in the terminal. Essential when you're debugging "how did the codebase get into this state." 3. git bisect Binary search through your commit history to find the exact commit that introduced a bug. Sounds complex — takes 5 minutes to learn and saves hours. 4. git commit --amend Fix your last commit message or add a forgotten file before pushing. No more embarrassing "oops" commits cluttering the history. 5. git reflog Your ultimate safety net. Every HEAD movement recorded. Accidentally deleted a branch? Reset too hard? Reflog can bring it back. Almost nothing in Git is truly gone. Bonus: git cherry-pick [hash] — Apply one specific commit from another branch without merging everything else. Surgical and underused. Bookmark this for the next time something breaks at 11 PM. Which of these took you the longest to discover? #Git #CodingTips #DevProductivity #SoftwareEngineering #DevLife

Stop the "Stash & Switch" madness. 🛑 We’ve all been there: You’re deep in a feature, your workspace is a mess of half-finished logic, and suddenly... a critical bug hits production. Most devs reach for git stash. Some make a messy "WIP" commit. But there’s a better way that most people ignore: Git Worktree. Instead of flipping a single folder between branches, Git Worktree lets you "check out" multiple branches into separate folders simultaneously, all linked to the same local repo. Why is this a game-changer? ✅ Zero Context Switching: Keep your feature code open in one VS Code window and your hotfix in another. No stashing required. ✅ Parallel Testing: Run a heavy test suite or build process on one branch while you keep coding on the other. ✅ Code Reviews: Need to test a teammate's PR? Open it in a new worktree without touching your current progress. ✅ No More npm install Loops: If branches have different dependencies, worktrees keep their respective node_modules intact. No more re-installing every time you switch. The Magic Command: git worktree add ../hotfix-folder hotfix-branch It’s one of those "once you know it, you can't go back" tools. Are you still stashing, or have you made the switch to Worktrees? Let’s hear your workflow hacks in the comments! 👇 #Git #WebDevelopment #SoftwareEngineering #DevOps #ProgrammingTips #Efficiency

One thing I've noticed building with Claude Code: it loves to lay out 4-6 week sprints in Plan Mode, completely serious, as if it isn't about to knock out most of it in a weekend. Powerful tool. Very silly estimator. What actually helped me calibrate: I stopped letting it estimate in time and started asking it to break work into phases (a bundle of related features), then blocks (one feature or part of a larger one), then chunks (described as roughly 1-2 hours of pre-AI work each). Every finished chunk is a reminder for me to git commit. Every commit is a natural place to pause, assess, and manage usage limits before moving on. Then I turned this practice into a skill so I didn't have to think about it again. If you're a non-engineer just getting started with Claude Code, treat the timeline as noise and the structure as signal. You'll get a much more accurate sense of what you're actually building — and how fast. This Sunday (Apr 26 8am PT), I'm going deeper on exactly this — how to build a personal software development lifecycle, and make vibe coding a repeatable high quality skill. Joining me for a Maven lightning lesson: **Become an AI Builder: The Right Way to Vibe-Code.** Free to join → https://maven.com/p/ba6812

"Why is this line like this?" Nobody on the team knew. The code did. 🔥 Happy Git Friday! Code review. Someone flagged a line in a config file that looked wrong. Not broken, just odd. A hardcoded value where a variable should have been. Nobody on the team remembered writing it. Nobody remembered approving it. It had been there so long it was just part of the landscape. Instead of guessing, I ran: git blame config.yml Every line in the file came back annotated with the commit hash, the author, and the date. That odd line? It was a workaround from two years ago. A specific bug in a dependency required a hardcoded value to avoid a crash. The bug was patched six months later. The workaround was never removed. No comment. No ticket reference. Just a line that made no sense anymore because the context was gone. git blame didn't just tell me who wrote it. It told me when, which commit, and gave me enough context to pull up the original PR and understand why. Two minutes of blame saved an hour of guessing and a potential rollback of something that turned out to be safe to remove. The Danger Zone (When Nobody Remembers Why): 🔹 Uncommented workarounds become mysteries the moment the original author leaves or forgets. git blame is the only way to recover the context when the code doesn't explain itself. 🔹 git log shows you commit history for the whole file. git blame shows you commit history per line. When you need to know why one specific line exists, log is too broad. Blame is surgical. 🔹 Removing a line you don't understand is risky. Blame gives you the commit, the commit gives you the PR, the PR gives you the discussion. That's the chain of context that makes the decision safe. ❓ Question of the Day: Which command shows who modified each line of a file and in which commit? Ⓐ git blame filename Ⓑ git who filename Ⓒ git log filename Ⓓ git diff filename 👇 Answer and breakdown in the comments! #Git #GitOps #DevOps #DamnitRay #QOTD