Mastering Git Undo & Branching Strategies for DevOps

Day 25 of #90DaysOfDevOps – Learning How to Undo Mistakes Without Breaking Everything Today was about something every developer eventually faces: Mistakes. But more importantly — how to undo them properly. I explored the real difference between git reset and git revert, and this completely changed how I think about fixing errors in Git. Here’s what I learned: git reset Moves the branch pointer backward Can rewrite history Powerful but dangerous Should NOT be used on shared branches git revert Creates a new commit that reverses changes Preserves history Safe for production and team collaboration Big realization: Reset is for cleaning up your own room. Revert is for fixing things in a shared house. I also studied branching strategies used by real engineering teams: • GitFlow – structured, great for enterprise release cycles • GitHub Flow – simple, ideal for fast-moving startups • Trunk-Based Development – continuous integration focused, used in strong CI/CD cultures Understanding when to use each strategy made me realize that Git is not just a tool — it's a workflow design system. Day by day, I’m moving from “knowing commands” to understanding real-world engineering practices. Consistency continues. On to Day 26. #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Git #DevOpsJourney #LearningInPublic

🚀 Day 60 of my Learning Journey – Git Cherry-Pick 🎯 Discovered how to copy specific commits between branches using Git Cherry-Pick. A small command, but extremely powerful when working with multiple branches in real-world projects. 📘 What is Git Cherry-Pick? Git Cherry-Pick allows you to select a specific commit from one branch and apply it to another branch. Instead of merging an entire branch, you can bring only the exact change you need. This is very useful when fixing bugs or moving small features across branches without affecting other changes. ⚙️ Key Commands & Features 🔹 git cherry-pick <commit-id> – Applies a specific commit from another branch to the current branch. 🔹 Find Commit ID using git log – Helps identify the exact commit you want to copy. 🔹 Resolve Conflicts if they occur – Similar to merge conflicts when changes overlap. 🔹 git cherry-pick --continue – Continue the cherry-pick process after resolving conflicts. 🔹 git cherry-pick --abort – Cancel the cherry-pick operation if needed. 💡 Key Takeaway Understanding Cherry-Pick helps me manage code changes more efficiently and is an important skill for working with Git in DevOps workflows. 📈 💻 Real-World Usage in Industry 🔹 Hotfix management – Developers move urgent bug fixes from development to production branches quickly. 🔹 CI/CD workflows – Teams apply critical commits to release branches without merging incomplete features. 🔹 Production stability – Only safe and verified commits are applied to production environments. 🔹 Multi-branch development – Used when maintaining different versions of software simultaneously. #Git #GitHub #DevOpsLearning #TechJourney #ContinuousLearning #SoftwareDevelopment #CareerGrowth

Day 25 of my #90DaysOfDevOps journey Today I explored Git Reset vs Git Revert and understood how to safely undo mistakes in Git. Practiced --soft, --mixed, and --hard resets and learned when each should be used. Compared reset vs revert and understood why revert is safer for shared branches. Also researched branching strategies like GitFlow, GitHub Flow, and Trunk-Based Development. This helped me understand how real engineering teams manage code at scale. 🔗 GitHub Notes: https://lnkd.in/gptC5JTw #90DaysOfDevOps #DevOps #Git #VersionControl #TrainWithShubham #LearningInPublic

🚀 𝐃𝐚𝐲 35: 𝐕𝐞𝐫𝐬𝐢𝐨𝐧 𝐂𝐨𝐧𝐭𝐫𝐨𝐥 𝐈𝐧𝐭𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 Before starting today's learning update, a quick community note. Over the past month, I intentionally took a LinkedIn detox break — both from scrolling and content sharing. The goal was simple: • Focus deeply on learning • Reduce noise • Build stronger fundamentals Now I'm back to sharing my journey publicly again and continuing my Learn in Public goal. Starting today, I’m diving into DevOps fundamentals, beginning with one of the most important pillars of modern software development: ⚙ Version Control Systems (VCS) Imagine building software without version control. Developers would face problems like: ❌ Overwriting each other's code ❌ No history of changes ❌ No rollback if a bug appears ❌ Difficult collaboration This is where Version Control Systems help. A VCS allows developers to: ✔ Track code changes over time ✔ Maintain complete project history ✔ Collaborate safely with teams ✔ Experiment with new features using branches ✔ Rollback to previous stable versions Today, most engineering teams use Git, which works using a snapshot-based versioning system. Think of Git as a time machine for your codebase. Tomorrow I’ll break down how Git actually tracks changes internally. #DevOps #Git #VersionControl #LearnInPublic #SoftwareEngineering #100DaysOfLearning #100DaysOfLearning

🚀 𝗗𝗲𝘃𝗢𝗽𝘀 – 𝗗𝗮𝘆 𝟭𝟭: 𝗛𝗼𝘄 𝗚𝗶𝘁 𝗜𝘀 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱 𝗶𝗻 𝗥𝗲𝗮𝗹 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 Ever wonder how Git is actually practiced in real development — not just learned from tutorials? We all know the basics: git add → git commit → git push But real engineering teams don’t work like that. 🔥 The Big Difference: In real projects, nobody pushes directly to main. Instead, teams follow structured workflows: 🔹 main → Always production-ready 🔹 develop → Integration branch 🔹 feature/* → For new features 🔹 hotfix/* → For urgent fixes You don’t just “code and push”. You: 1️⃣ Create a feature branch 2️⃣ Work locally with clean, meaningful commits 3️⃣ Push the branch 4️⃣ Open a Pull Request 5️⃣ Go through Code Review 6️⃣ Merge after approval That review step alone changes everything. Because now: Your code must be readable Your commits must be clean Your changes must not break others’ work Git becomes a collaboration tool — not just a version control tool. 🧠 What I Realized Git workflow teaches engineering maturity: Think before committing Write meaningful commit messages Keep branches organized Don’t break production Respect team structure This is where DevOps mindset begins. It’s not about knowing commands. It’s about building safely, collaboratively, and professionally. Practice Notes: https://lnkd.in/gvSS7mVy #DevOps #Git #SoftwareEngineering #bongodev 🚀

🚀 Day 24 & 25 – From Basic Git to Real Engineering Git Most people learn: 👉 git add 👉 git commit 👉 git push But real engineers master: ✅ Merge vs Rebase ✅ Stash & Cherry Pick ✅ Reset vs Revert ✅ Branching Strategies This week I went deep into advanced Git workflows — the skills that separate beginners from confident developers. 🔀 Day 24 – Advanced Git 🔁 Merge vs Rebase Learned how fast-forward merge works. Understood when Git creates a merge commit. Practiced git rebase and saw how it rewrites history. Key rule: Never rebase shared branches. 📦 Git Stash Mid-feature but urgent bug? git stash saves your unfinished work like a temporary locker. Real-world lifesaver. 🍒 Cherry Pick Needed only ONE fix from a branch? git cherry-pick <commit> Applied a single commit without merging everything. Powerful. Dangerous if misused. 🔥 Day 25 – Undoing Mistakes Like a Pro 🟢 git reset --soft → Undo commit, keep staged changes --mixed → Undo commit, keep working changes --hard → Deletes everything (danger zone ⚠️) Rule: Never reset pushed commits. 🔄 git revert Safely undo changes by creating a new commit. ✔ Keeps history ✔ Safe for teams ✔ Production-friendly 🌳 Branching Strategies I Explored GitFlow Best for large teams with release cycles. GitHub Flow Simple + fast + PR based. Perfect for startups shipping quickly. Trunk-Based Development Short-lived branches + strong CI. Used by high-performance teams. 🧠 Biggest Lessons Merge preserves history. Rebase rewrites history. Reset deletes. Revert protects. Stash saves your context. Cherry-pick isolates fixes. Strategy depends on team size and release model. Git is not just commands — it’s engineering discipline. This DevOps journey is getting deeper every day. Day 24 & 25 complete ✅ Consistency > Motivation. #DevOps #Git #OpenSource #SoftwareEngineering #100DaysOfDevOps #LearningInPublic #VersionControl #DevOpsKaJosh #TrainWithShubham

Excited to share that I recently worked on the Git Branching topic in DevOps and prepared a detailed presentation on it. Learning how branching helps teams collaborate, manage versions, and maintain clean code workflows was a great experience. Looking forward to exploring more concepts in DevOps and software development. 🚀 different commands like 1 git init 2 git branch 3 git switch branch_name 4 git add . 5 git commit -m " msg " 6 git push origin main #DevOps #GitBranching #TechLearning #StudentsInTech

🚀 Day 25 – Git Reset vs Revert & Branching Strategies Today was all about something every developer must know: 👉 How to undo mistakes safely in Git 👉 How real teams manage branches at scale And honestly… this is where Git becomes powerful 💥 🔁 Git Reset – Rewriting History I practiced 3 types of reset: 🔹 git reset --soft Removes last commit Keeps changes staged Useful when you want to redo a commit 🔹 git reset --mixed (default) Removes last commit Keeps changes in working directory (unstaged) Good when you want to edit before committing again 🔹 git reset --hard Removes last commit Deletes changes completely ⚠️ Dangerous – never use on pushed commits 💡 Key learning: Reset rewrites history. Use only for local/unpushed commits. 🔄 Git Revert – Safe Undo git revert <commit-id> Creates a new commit Undoes changes of a previous commit Keeps history intact ✅ Safe for shared branches 💡 Key learning: Revert doesn’t delete history — it adds a corrective commit. If working in a team → Prefer revert If fixing local mistakes → reset is fine 🌿 Branching Strategies I Explored 🔹 GitFlow Feature → Develop → Release → Main → Hotfix Best for large teams with planned releases 🔹 GitHub Flow Main + short-lived feature branches Simple and fast Perfect for startups 🔹 Trunk-Based Development Everyone commits to main (or very short branches) Strong CI/CD required Used in modern continuous delivery setups 🎯 My Takeaways ✔ Reset = rewrite history ✔ Revert = safe undo ✔ Choose branching strategy based on team size & release cycle ✔ git reflog is your safety net The more I learn Git, the more I realize — It’s not just about commands. It’s about collaboration, discipline, and clean history. #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #ankitaspectrum TrainWithShubham

Day 25 - Git Reset Vs Revert & Branching Strategies This week I focused on one of the most underrated Git skills: undoing safely at scale. Here’s the executive summary: • git reset rewrites history. Powerful. Dangerous. Local use only. • git revert preserves history. Safe. Production-ready. If your code is already pushed, revert. If you’re cleaning up locally, reset. Understanding this distinction is the difference between: • Confident engineering • And breaking your team’s main branch at 2AM Branching strategy should be a reflection of your organizational DNA, not just a technical preference: • GitFlow: Designed for enterprise-grade control and structured, scheduled release cycles. • GitHub Flow: Optimized for agile startups requiring rapid, continuous deployment. • Trunk-Based Development: The benchmark for continuous value flow of DevOps culture prioritizing CI/CD and minimal merge friction. Full commit history on GitHub: https://lnkd.in/gNDRhAXq #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham

🚀 5 Essential Git Branching Strategies 1. Feature Branching: The classic approach. Create a dedicated branch for every new feature and delete it once merged. Perfect for keeping the main history clean. 2. GitFlow: Best for projects with scheduled release cycles. It uses dedicated branches for main, dev, features, releases, and hotfixes. Complex, but highly structured. 3. GitLab Flow: A middle ground that links branching to environments (e.g., staging, preprod). Great for when your code needs to pass through multiple validation gates. 4. GitHub Flow: Simple and agile. The main branch is always deployable. You branch off for a fix or feature, then merge back immediately after testing. Ideal for Continuous Delivery. 5. Trunk-Based Development: The speed demon's choice. Developers merge small, frequent updates into a single "trunk" (main). Large features are hidden behind feature flags to keep the build stable. Which one should you choose? • Small team/SaaS? GitHub Flow is your best friend. • Enterprise/Regulated industry? GitLab Flow or GitFlow offers the control you need. • High-velocity DevOps? Trunk-Based is the way to go. How does your team handle branching? Are you a GitFlow traditionalist or a Trunk-Based speedster? Let's discuss in the comments! 👇 #SoftwareEngineering #WebDevelopment #Git #DevOps #CodingTips #TechCommunity #Programming #VersionControl