Git Branching and Pull Requests for a Maintainable Codebase

Day 101. I'm back on the consistency grind. No fluff. Let's talk about something I've been sharpening — Git DAGs. You've used git commit, git reset, git revert. But do you actually know what's happening under the hood? DAG = Directed Acyclic Graph. Directed → commits point to their parent(s). Time only moves forward. Acyclic → no loops. History never circles back on itself. Graph → it's a network of nodes (commits) and edges (parent relationships). Every commit is a snapshot — not a diff, not a delta. A full picture of your entire repo at that moment, stored as a SHA hash. Now the three commands people confuse: git checkout → moves your HEAD to a different commit or branch. You're not changing history — you're just looking at a different snapshot. Like rewinding a film without cutting any frames. git reset → rewrites history. Moves the branch pointer backward. Three flavors: --soft → keeps your changes staged --mixed → keeps changes unstaged --hard → wipes everything. No mercy. git revert → the safe option. Creates a new commit that undoes a previous one. History stays intact. This is what you use on shared branches. I've done Git before. But "done" and "sharp" are two different things. I'm going deeper — understanding conflicts at the DAG level, debugging merges, knowing why a rebase breaks so I can fix it, not just panic-force-push. If you're learning Git too, stop memorizing commands. Learn the graph. Day 101. Still here. Still building. #Git #DevOps #100DaysOfCode #CloudEngineering #Infracodebase #LearningInPublic

🔧 Understanding git reset in a simple way (Senior Dev concept) One of the most important Git concepts every developer should clearly understand is how different git reset modes behave. Git has 3 key layers: Commit history (HEAD) Staging area (index) Working directory Here’s the breakdown 👇 🟢 git reset --soft Moves HEAD only Keeps staging area intact Keeps working directory unchanged 👉 Use case: When you want to redo commits but keep changes staged. 🟡 git reset --mixed (default) Moves HEAD Resets staging area Keeps working directory unchanged 👉 Use case: When you want to unstage files but keep your code. 🔴 git reset --hard Moves HEAD Resets staging area Resets working directory ⚠️ This deletes all changes permanently (use carefully) 💡 Simple memory trick: soft → keep everything mixed → unstage changes hard → erase everything Understanding this properly is critical in real-world development and interviews, especially at senior level. #Git #GitHub #SoftwareEngineering #WebDevelopment #DevOps #CodingTips

"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

git blame is one of Git's most misused commands. A developer joined a team and started using it to identify "who wrote the bad code." In reviews they would say: "The blame shows this was written by Sarah." The tone implied fault. The team atmosphere deteriorated over months. Here is what git blame actually does: It shows which commit last changed each line. That is not the same as: — Who introduced the bug — Who made the design decision — Who is responsible for the current state The correct workflow: $ git blame src/auth.py -L 47,52 # Note the commit hash for the line of interest $ git show a1b2c3d # Read the full commit: context, message, what else changed Now you have context. Now you can understand the decision. Now you can have a productive conversation. The word "blame" is an unfortunate name for a context command. Use it to understand — not to accuse. Has git blame ever helped you understand a mysterious piece of code? Have you been on the receiving end of blame used as blame rather than context? What happened? #Git #SoftwareEngineering #TeamCulture #CodeReview #TechLeadership

❌ 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

🚨 Stop using git push --force It's one of the most destructive commands in a shared codebase — and most developers don't realize it until something breaks in production. Here's what actually happens when you force push: ❌ Overwrites your teammates' commits silently ❌ Permanently destroys shared history ❌ Breaks CI/CD pipelines mid-deployment The fix? You have better options: (: git push --force-with-lease → Fails if someone else pushed first. Protects your team without you thinking about it. (: git fetch && git rebase origin/main → Pull in upstream changes before pushing. Clean history, zero force needed. (: git reset --soft HEAD~1 → Undo your last commit but keep changes staged. Recommit cleanly — no remote impact. 🔑 The rule of thumb: If anyone else could be touching the branch — never force push. force-with-lease should honestly be your default. Alias it if you have to: git config --global alias.fpush "push --force-with-lease" Have you ever been burned by a force push? Drop a 🔥 below. #Git #DevOps #SoftwareEngineering #OpenSource #100DaysOfCode #Programming #WebDevelopment

Git Workflow (At a Glance) 🚀 Most developers use Git daily, but many still struggle with the difference between the Staging Index and Local Repo, or when to Merge vs. Rebase. If you’re guessing your way through your terminal, you’re eventually going to break a production branch. Stop memorizing commands and start understanding the architecture. 🛠 The Three Areas You Must Know: Working Directory: Where you actually write the code (Untracked/Modified). Staging Index: The "loading dock" where you prep your changes for a commit. Local Repo (.git/): Your personal history of snapshots. Remote Repo: Where the team collaborates (GitHub/GitLab). 💡 Key Technical Takeaways: Merge vs. Rebase: Merging preserves the full history with a "merge commit." Rebase rewrites history for a clean, linear timeline. Choose wisely based on your team's workflow. File Lifecycle: A file isn't just "saved"—it moves from Untracked → Staged → Committed → Modified. The "Safety Net" Commands: Learn git stash for temporary work and git revert to fix mistakes without destroying the commit history. The Reality Check: You aren’t a Senior Engineer until you can manage a complex branching model without losing data. Save this infographic for your next "merge conflict" headache. #DevOps #Git #VersionControl #CloudEngineering #SoftwareDevelopment #CodingTips #TechCommunity

🚀 Day 13 of #100DaysOfDevOps Today I explored some powerful Git commands that help in better code management and recovery: 🔹 Config – Set up Git username, email, and preferences 🔹 Ignore – Avoid tracking unnecessary files using .gitignore 🔹 Amend – Modify the last commit (message or changes) 🔹 Reset – Undo changes and move to a previous state 🔹 Reflog – Track all Git actions and recover lost commits 🔹 Cherry-pick – Apply a specific commit from one branch to another 💡 These commands are very useful in real projects for fixing mistakes, managing commits, and maintaining clean history. 📌 Learning step by step, improving every day! #DevOps #Git #VersionControl #LearningJourney #TechSkills #100DaysOfCode

Struggling with messy commit messages? Here’s a simple way to make them clean and professional 👇 ## 🔹 Use Standard Commit Types Using commit types makes your Git history easy to read and understand. 🎯 Common types: * feat → New feature feat: add user authentication * fix → Bug fix fix: resolve login redirect issue * refactor → Improve code (no behavior change) refactor: optimize API handling * style → UI / formatting changes style: update button spacing * docs → Documentation docs: add API guide * test → Testing test: add login unit tests * chore → Maintenance chore: update dependencies 💡 Why it matters: ✔ Easy to scan history ✔ Better team collaboration ✔ Cleaner debugging ✔ Helps automation (changelogs, releases) 🚀 Pro tip: One commit = one purpose. Split your changes. Bad ❌ feat: add login and fix bugs and update UI Good ✅ feat: add login API fix: correct validation style: improve UI 👉 Rule: Your commit should tell the story instantly. 💬 What’s the worst commit message you’ve ever written? 👍 If this helped, drop a like & follow for more dev tips! #Git #GitHub #WebDevelopment #Programming #SoftwareEngineering #CleanCode #Developers #CodeQuality #VersionControl #TechTips