8 Years of Git: The Safety Net for Modern Engineering

Yesterday I had to sync a branch from one Git repository into another repo , one of those tasks that sounds simple but needs precision. Added the external repo as a remote, fetched the branch, merged it into a one‑time sync branch, and pushed it for review. ```git remote add <remote-name><repo-url> git fetch <remote-name> git checkout -b one-time-sync git merge <remote-name>/<remote-branch> git push origin one-time-sync``` A neat reminder that Git is powerful when you understand remotes, not just branches. #Git #Devops

𝗗𝗮𝘆 𝟯𝟬 𝗼𝗳 𝗺𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 💻 Cleaning up Git history — used hard reset to remove unwanted commits and restore a clean state 🔥 𝗧𝗮𝘀𝗸: Git Hard Reset 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗼𝗱𝗮𝘆: • How `git reset --hard` rewrites commit history • Difference between `git revert` (safe) vs `git reset` (destructive) • Importance of identifying the correct commit before resetting • Why force push is required after history rewrite • Risks of using hard reset in shared environments 𝗪𝗵𝗮𝘁 𝗜 𝗯𝘂𝗶𝗹𝘁 / 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱: • Navigated to repo `/usr/src/kodekloudrepos/beta` • Checked commit history using `git log --oneline` • Identified target commit (`add data.txt file`) • Performed `git reset --hard <commit-id>` • Verified only required commits remain • Force pushed changes using `git push origin master --force` 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: • Understanding when it’s safe to rewrite history • Ensuring correct commit is selected before reset • Awareness of impact on remote repositories 𝗙𝗶𝘅 / 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: • Learned that `git reset --hard` permanently removes commits • Understood why force push is necessary after reset • Realized this approach should be used carefully in team environments • Gained clarity on cleanup strategies for test repositories 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: With great power comes great responsibility — `git reset --hard` is powerful, but should be used only when you’re absolutely sure. This felt like performing a controlled cleanup in a real DevOps environment 🚀 When do you prefer using reset vs revert in your workflow? #Day30 #DevOps #Git #VersionControl #Linux #Automation #CloudComputing #AWS #DevOpsJourney #LearningInPublic #100DaysOfDevOps

If a change isn’t in Git, it didn’t happen. That’s not something I’m adopting for this build, it’s something I stopped tolerating. In it-re-dc01, everything lives in one place: Ansible roles. Terraform modules. Docker Compose stacks. Helm charts. Docs. Runbooks. ADRs. One repo: it-re-dc01-infra. GitHub Actions runs on a self-hosted runner on re01-mgmt-01. Every push triggers: • ansible-lint • docker compose validation • terraform validate Merges to main trigger applies. Terraform state is not local. It’s stored and secured via Vault-backed workflows. Secrets don’t live in the repo. They’re issued dynamically. Git defines the desired state. Vault secures access to it. GitHub Actions enforces the path to change. No manual changes. No exceptions. I’ve seen what happens without this discipline. At one point, we ran Jenkins where the pipeline configuration lived inside Jenkins itself. When Jenkins went down, the pipelines went with it. We rebuilt them from memory and screenshots and it took two weeks. That wasn’t a tooling issue, it was a process failure. The tool doesn’t matter, the discipline does. No change, no matter how small or urgent, happens outside the pipeline. Because if your system can’t be rebuilt from Git, you don’t control it. #GitOps #PlatformEngineering #CI/CD

Someone manually changed a deployment in production. GitOps fixed it in 3 minutes. Self-healing. 🔄 No more "who changed what?" Git history = complete audit trail. Read more by clicking below https://lnkd.in/d9tC43qb #K8s #CloudNative #InfrastructureAsCode #TechLeadership

🚀 GitLab Migration: A Story Between Old Repo & New Repo 😄 So I recently had to migrate projects from one GitLab to another… and honestly, it felt like shifting houses 🏠 🔹 Step 1: Packed everything git clone --mirror 👉 “Take EVERYTHING. Even things I forgot existed.” 🔹 Step 2: Moved to new place git push --mirror 👉 “Congrats, new GitLab… you now have my entire past.” 🔹 Step 3: Panic moment 😱 Error: “deny updating a hidden ref” 👉 Me: “WHAT DID I BREAK???” 👉 GitLab: “Relax… that’s just merge request stuff.” 🔹 Step 4: Trust issues 👉 Checked commits 👉 Checked branches 👉 Checked again… just in case 🔹 Step 5: Size mismatch 🤨 Old repo: 500 MB New repo: 480 MB 👉 Me: “WHERE ARE MY 20 MB???” 👉 Git: “Bro… I cleaned your mess.” 🔹 Reality check 💀 ❌ Members didn’t come ❌ Permissions didn’t come ❌ Pipelines didn’t come 👉 Basically moved house… but forgot the people 💡 Final lesson: If commits match → You’re safe If branches match → You’re happy If no errors → Don’t overthink 😄 #DevOps #GitLab #Migration #Git

Just wrapped up an insightful 3-hour workshop on Containerisation, Jenkins installation, NGINX, and Docker with Vikas Ratnawat and CloudDevOpsHub Community🚀 It was a hands-on deep dive into modern DevOps practices - from understanding how containers streamline application deployment to setting up Jenkins for continuous integration and exploring the role of NGINX in managing web traffic efficiently. Key takeaways:- - Practical exposure to Docker and container workflows - Step-by-step Jenkins installation and configuration - Understanding how NGINX acts as a reverse proxy - Real-world insights into DevOps pipelines Mastering these tools is a game-changer for building scalable, secure, and resilient applications. Looking forward to implementing these workflows in my upcoming projects!💡 #DevOps #Docker #Jenkins #NGINX #Containerization

𝗗𝗮𝘆 𝟯𝟮 𝗼𝗳 𝗺𝘆 𝗗𝗲𝘃𝗢𝗽𝘀 𝗝𝗼𝘂𝗿𝗻𝗲𝘆 💻 Keeping history clean — used Git rebase to update a feature branch without creating extra merge commits 🔄 𝗧𝗮𝘀𝗸: Git Rebase 𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝘁𝗼𝗱𝗮𝘆: • How `git rebase` helps maintain a clean, linear history • Difference between `merge` vs `rebase` • Why rebase avoids unnecessary merge commits • Importance of syncing feature branches with latest `master` • When to use force push after rebase 𝗪𝗵𝗮𝘁 𝗜 𝗯𝘂𝗶𝗹𝘁 / 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝗱: • Navigated to repo `/usr/src/kodekloudrepos/games` • Switched to feature branch • Pulled latest changes from `master` • Rebased feature branch using `git rebase origin/master` • Resolved conflicts (if any) • Verified clean commit history using `git log` • Pushed updated branch using `git push --force` 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: • Understanding difference between merge and rebase • Handling conflicts during rebase • Knowing when force push is required 𝗙𝗶𝘅 / 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: • Learned that rebase rewrites commit history • Understood why it creates a cleaner project timeline • Gained clarity on resolving conflicts step-by-step • Realized rebase is widely used in professional workflows 𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆: Rebase isn’t just about updating branches — it’s about keeping your Git history clean and readable. This felt like working with real-world collaborative Git workflows 🚀 Do you prefer using rebase or merge in your projects — and why? #Day32 #DevOps #Git #VersionControl #Linux #Automation #CloudComputing #AWS #DevOpsJourney #LearningInPublic #100DaysOfDevOps

🚀 Day-25/90 of #90DaysOfDevOps -Day 25-Git Reset vs Revert & Branching Strategies...!!! I have learned git reset, revert and Branching Strategies. 🔁 Git Revert → Safe, keeps history, ideal for shared branches. ⚡ Git Reset → Rewrites history, powerful but risky if misused. 🌿 Branching Strategy matters: A good workflow (feature branches, main protection, PR reviews) prevents chaos before it starts. 🌿 Branching Strategy + PR Reviews = Clean Collaboration. 👀 PR (Pull Request) Reviews matter because: ✔ Catch bugs before they hit production ✔ Improve code quality & consistency ✔ Share knowledge across the team ✔ Ensure standards & best practices So need to take this process for best practice-> { "Strong branching + Proper PR reviews = fewer conflicts, better releases, and a healthier codebase" } And #Branching_Strategies is a set a rules for how your team works on code without breaking it. With #branching ✅ Create a branch 👉 feature/login Do your work there 👉 safe, no impact on main code Create PR (Pull Request) 👉 team reviews your code Merge into main 👉 only after approval { 👉 Create branch → Work → Review → Merge } #git repo- https://lnkd.in/gpC4pXqk TrainWithShubham Shubham Londhe #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #cloudengineer #devOps #devopsengineer #cloud #aws #linux

Wrote a short note on something I recently found useful while working with Git — git cherry-pick. It helped me move specific commits across branches without merging everything, especially in a GitFlow setup. Tried to keep it simple and practical. Read here: https://lnkd.in/dt4xQ7Da #git #devops #versioncontrol

Real-time DevOps scenario (Jenkins & GitHub Actions): 🔹 Developer pushes code to GitHub 🗂️ 🔹 Pipeline triggers automatically (Jenkins / GitHub Actions) ⚙️ 🔹 YAML file defines steps: * Build (Gradle) 🏗️ * Code quality check (SonarQube) ✅ * Run tests 🧪 🔹 If everything passes → Deploy to server 🚀 🔹 If anything fails → Pipeline stops & logs help debug 🔍 💡 Real learning: Not just writing pipelines… 👉 Handling failures, fixing quickly, and keeping deployments smooth #DevOps #Jenkins #GithubActions #CI_CD #RealTimeScenario