Git Reset Practical Lab: Soft, Mixed, and Hard Resets Explained

🚀 GitHub for DevOps – Day 4 (Part 5) 🔁 Git Revert vs Git Reset – Know the Difference (Very Important in Production) In real-world DevOps environments, handling mistakes safely is more important than just fixing them. Let’s understand two commonly confused commands: git revert and git reset 🔹 1️⃣ Git Revert – Safe Undo (Recommended for Shared Branches) 👉 git revert is used to undo a commit without deleting history 📌 What it does: Creates a new commit Reverses the changes of a specific commit Keeps history clean and traceable 📍 Example: git log --oneline c3 v3 commit b2 v2 commit a1 v1 commit Now revert the latest commit: git revert c3 📍 New log: d4 Revert "v3 commit" c3 v3 commit b2 v2 commit a1 v1 commit ✅ A new commit is created ✅ History is preserved ✅ Safe for production & team environments 🔹 2️⃣ Git Reset – History Rewriting (Use Carefully) 👉 git reset is used to move the branch pointer backward 📌 What it does: Removes commits from history No new commit is created Can rewrite history (dangerous in shared branches) 📍 Example: git reset --hard b2 📍 New log: b2 v2 commit a1 v1 commit ❌ v3 commit is completely removed ❌ No trace of undo action ⚠️ Risky if code is already pushed 🔥 Key Difference ✔️ git revert → Safe, creates a new commit, keeps history ⚠️ git reset → Dangerous, deletes history, no new commit 💡 Pro Tip (MNC Level Practice): Use git revert in production or shared branches Use git reset only for local changes or before pushing 📌 Understanding this difference can save your team from major production issues. #HiteshDevOps #DevOps #Git #GitHub #CI_CD #Docker #Kubernetes #AWS #OpenToWork #HiringDevOps #DevOpsEngineer #TechHiring #LearningInPublic #BuildInPublic #TechJourney

🚀 GitHub for DevOps – Day 4 (Part 1) 🔥 Git Reset — The Most Misunderstood Command in Git As a DevOps Engineer, you’re not just writing code — you’re managing history, fixing mistakes, and maintaining clean repositories. 👉 That’s where git reset becomes powerful. 📌 Simple Meaning: Git reset = Move your project back to a previous commit Example: A → B → C → D Want to go back to B? 👉 git reset B ⚙️ Git Works in 3 Areas (Must Know) 1️⃣ Working Directory → Your files 2️⃣ Staging Area → git add 3️⃣ Repository → commits 🔥 Types of Git Reset 🔹 1. Soft Reset (Safe) 👉 git reset --soft HEAD~1 ✔ Commit removed ✔ Changes still in staging 💡 Use when: You want to fix commit message or recombine commits 🔹 2. Mixed Reset (Default) 👉 git reset HEAD~1 ✔ Commit removed ✔ Staging cleared ✔ Changes still in files 💡 Use when: You added wrong files 🔹 3. Hard Reset (Dangerous ⚠️) 👉 git reset --hard HEAD~1 ❌ Commit removed ❌ Staging removed ❌ Changes deleted permanently 💡 Use when: You want to completely discard changes 📍 When to Use? ✔ Fix wrong commit → soft reset ✔ Remove staged files → mixed reset ✔ Delete everything → hard reset 🚨 Golden Rule 👉 Use git reset only in local branches 👉 Avoid using it on shared/main branches 💬 Real DevOps work is not about tools It’s about controlling changes safely and confidently. #HiteshDevOps  #DevOps #Git #GitHub #CI_CD #Docker #Kubernetes #AWS  #OpenToWork #HiringDevOps #DevOpsEngineer #TechHiring   #LearningInPublic #BuildInPublic #TechJourney

While learning, I discovered that as a DevOps engineer, Git is not only where code lives. It is where: • Infrastructure configurations are stored • Terraform files are versioned • CI/CD pipelines are managed • Bash and PowerShell scripts are tracked • Teams collaborate without overwriting each other’s work The beauty of Git is that it gives you history. If something breaks, you can trace what changed. If you make a mistake, you can roll back. If multiple people are working together, everyone can contribute without chaos. Concepts that once sounded confusing are now starting to make sense: • git clone → bring a project from the remote repository to your local machine • git add . → prepare your changes • git commit -m "message" → save a snapshot of those changes • git push → send your changes to the remote repository • git pull → get the latest updates from others I now see Git as the memory of a project. Without it, DevOps would feel like trying to build a house with no blueprint and no record of what has changed. What Git command or concept took you the longest to understand? #Git #DevOps #CloudComputing #VersionControl #LearningInPublic #TechJourney #CI_CD

👨💻 50-day journey to revisit and strengthen my DevOps engineering skills 📌 Day 2/50 📌 ⚙️ Tools I’ll be working with: Git | GitHub Actions Today, I focused on how local Git operations turn into real CI/CD execution using GitHub Actions. In production environments, every pipeline execution is a result of developer actions performed locally, making it critical to understand the complete flow from code creation to deployment trigger. 🔄 Flow Overview: 💠 Developer writes code locally 💠 Commits and pushes using Git 💠 Code is pushed to GitHub 💠 GitHub Actions workflow is triggered 💠 CI/CD pipeline executes (build, test, deploy) ➡️ Flow attached below 👇 📌 Note: Key CI/CD stability considerations as covered in Day 1 are critical. ➡️ For a more detailed understanding of GitHub Workflows and Actions, I’ve referred to the official documentation—feel free to explore it for deeper insights  🔗 https://lnkd.in/gm77PY7y 🚨 Possible Issue Scenario: A CI pipeline was set to trigger on every push to the main branch. A developer pushed changes without syncing with the latest remote updates, causing merge conflicts and pipeline failure due to inconsistent code. 🛠️ Resolution: Pulled latest changes from the repository Resolved conflicts locally Pushed updated code Pipeline re-triggered and executed successfully 💡 Always sync before pushing. ➡️ The key takeaway is that CI/CD pipelines are only as reliable as the version control practices behind them. Proper use of git pull, disciplined commits, and clean synchronization between local and remote repositories ensures smooth pipeline execution and avoids unnecessary failures. #DevOps #git #cicd #Github #skills #GithubCommands #Branchingstrategy #GithubActions #GithubDocs #Reskill #Workflow #Syntax

I used to think CI/CD was something only big companies with DevOps teams could have. Then I set up my first GitHub Actions pipeline in 20 minutes and shipped code to a server without touching it once. That's when it clicked. CI/CD isn't about the tools. It's about one thing: how fast do you find out something is broken? A bug caught in CI takes 5 minutes to fix. The same bug in production takes 5 hours, a post-mortem, and a very uncomfortable Slack thread. Here's what most tutorials skip: → A pipeline without tests is just a fancy way to deploy bugs faster → npm ci is NOT the same as npm install (use it in every pipeline) → Secrets in your YAML = secrets exposed to anyone who forks your repo → One massive job that does everything is the slowest way to get feedback → If nobody gets notified when the pipeline fails, the pipeline doesn't exist I put together a 12-page guide that breaks down exactly how CI/CD works, from first push to automated deployment. No fluff. No "it depends" answers. Real GitHub Actions YAML. Real pipeline stages. Common mistakes with the actual fixes. A cheat sheet you can keep open while building. If you've been putting off setting this up because it felt too complex, this is for you.

If you are working with Git in DevOps, you need to understand Git LFS. Here is why 👇 There are use cases where you might need to push a large file to git. For example, - ML models - Datasets etc. But Git was designed for text files, not binaries. Every change stores the entire file again, which bloats your repository fast. GitHub also has a hard limit of 100MB per file. Also, large files make git clone slow and git pull heavy. This directly impacts your CI pipeline performance. This is exactly where Git Large File Storage (LFS) helps you. It is an open source Git extension for versioning large files. Instead of storing large files directly in your repo, Git LFS replaces them with a small pointer file. That pointer file contains the LFS version, a SHA-256 hash of the actual file, and the file size. The real file is stored separately in Git LFS storage, not inside your Git repository. So where does it actually store the file? If you are using GitHub, the large file is stored in GitHub’s managed storage, separate from your Git objects. If you're self-hosting, it can be stored in your own LFS server or object storage like S3. Tools like DVC use similar workflow for versioning data in MLOPS use cases. --- 19000+ engineers read our DevOps/MLOPS newsletter. 𝗦𝘂𝗯𝘀𝗰𝗿𝗶𝗯𝗲 𝗵𝗲𝗿𝗲 (𝗶𝘁’𝘀 𝗳𝗿𝗲𝗲): https://lnkd.in/guFma5_V #mlops

What happens after you push your code to Git? 🤔 Day 16 of my DevOps Journey Today I started learning Jenkins and understood the backbone of DevOps — CI/CD ⚙️🚀 Until now, I was just pushing code… But what happens after that? That’s where CI/CD comes in. CI/CD explained simply: Continuous Integration (CI) → Combination of build + test Whenever a developer commits code to Git: • Code is automatically fetched • Build process starts • Unit tests are executed This helps us quickly know whether new code works with existing code or breaks it Continuous Delivery vs Continuous Deployment: • Continuous Delivery → Code is ready for deployment (manual approval needed) • Continuous Deployment → Code is automatically deployed to production after build & test CI/CD Pipeline stages: Version Control • Code is pushed using tools like Git Build • Code is compiled and prepared for execution Unit Testing • Code is tested to validate functionality Deploy • Application is deployed to environments (Dev/Test/Prod) After deployment, we can see the actual output of the application Tools used for CI/CD pipelines: Jenkins, GitHub Actions, GitLab CI, Azure Pipelines, AWS Pipelines, Travis CI, CircleCI, Harness Day 16 realization💡 Writing code is just the beginning. The real power lies in what happens after the commit. CI/CD makes sure: ✔ Code is tested instantly ✔ Issues are caught early ✔ Deployment becomes fast and reliable Now imagine: The moment code is committed It automatically builds → tests → deploys That’s CI/CD. That’s automation replacing manual effort. This is where DevOps actually begins⚡ Next — I’ll go deeper into Jenkins pipelines🔥 See you on Day 17 with Jenkins Installation and Access🚀 #DevOps #Jenkins #CICD #Automation #LearningInPublic #100DaysOfDevOps #Day16 #Git #Linux

My first post! Let's talk about the one tool that sits at the heart of every DevOps workflow: Git. 🧵 When I first started in DevOps, I thought Git was just "code backup." I used to zip folders with names like deploy_final_v2_FINAL.zip 😅 (please tell me I wasn't alone). If you're just starting your DevOps journey, don't let Git intimidate you. In our world, Git isn't just version control — it's the source of truth for everything: infrastructure, configuration, deployment pipelines, and application code. Here are 3 fundamentals that clicked for me: 1️⃣ Commit early, commit often — but make it meaningful. In DevOps, every commit can trigger a pipeline. Small, atomic commits mean faster feedback loops. Your CI/CD pipeline will thank you when it's not sitting through a 20-minute build just to find a typo at the end. 2️⃣ Treat infrastructure the same as application code. Your Terraform, Ansible, Kubernetes manifests — they all belong in Git. If it's not in Git, it doesn't exist. Period. This is the foundation of GitOps — your Git repo should be the single source of truth for both apps AND infrastructure. 3️⃣ Master the merge, but understand the strategy. git merge vs git rebase isn't just a preference — it's about maintaining a clean, auditable history. In DevOps, that history helps you trace exactly when and why infrastructure changed during an incident. Trust me, being able to pinpoint "which commit broke production" saves hours of debugging at 2 AM. 💡 For my fellow DevOps engineers: We all know the basics. But what's one Git command or practice you've baked into your CI/CD pipelines that saved your team during an outage? For me, it was git bisect — automating it in our pipeline to find exactly which commit introduced a performance regression. Absolute game-changer for root cause analysis. Drop your GitOps wisdom in the comments! Let's help the next generation of DevOps engineers level up. 👇 #git #devops #gitops #cicd #terraform #kubernetes #infrastructureascode #softwareengineering

🗓️ Day 29/100 — 100 Days of AWS & DevOps Challenge Today's task wasn't just Git — it was the full engineering team workflow that makes collaborative development actually safe. The requirement: Don't let anyone push directly to master. All changes must go through a Pull Request, get reviewed, and be approved before merging. This is branch protection in practice. Here's the full cycle: Step 1 — Developer pushes to a feature branch (already done) $ git log --format="%h | %an | %s" # Confirms user commit, author info, commit message Step 2 — Create the PR (Log into GIT) - Source: story/fox-and-grapes - Target: master - Title: Added fox-and-grapes story - Assign a user as reviewer Step 3 — Review and merge (log into GIT as reviewer) - Files Changed tab — read the actual diff - Approve the PR - Merge into master Master now has user story. And there's a full audit trail of who proposed it, who reviewed it, who approved it, and when it merged. Why this matters beyond the task: - A Pull Request is not a Git feature - it's a platform feature. Git only knows commits and branches. The PR is a Git/GitHub/GitLab construct that adds review, discussion, approval tracking, and CI/CD status checks on top of a branch merge. When companies say "we require code review before anything goes to production," this is the mechanism. When GitHub Actions or GitLab CI runs tests on every PR — this is where that hooks in. When a security audit asks "who approved this change?" — the PR has the answer. The workflow is identical across Git, GitHub, GitLab, and Bitbucket: push branch → open PR → assign reviewer → review diff→ approve → merge → master updated → branch deleted Full PR workflow breakdown on GitHub 👇 https://lnkd.in/gpi8_kAF #DevOps #Git #PullRequest #CodeReview #Gitea #BranchProtection #100DaysOfDevOps #KodeKloud #LearningInPublic #CloudEngineering #GitOps #TeamCollaboration

🚀 GitOps Changed How We Deploy. Here’s the Full Playbook. Traditional deployments are slow, manual, and error-prone. One wrong command → production break. One missed step → downtime. Then came GitOps… and it completely changed how modern DevOps teams ship software. ⚙️ What is GitOps? GitOps is a modern deployment approach where: 👉 Git = Single Source of Truth 👉 Infrastructure + Application configs live in Git 👉 Any change = Pull Request 👉 Deployment = Automated reconciliation No manual kubectl commands. No direct server changes. Everything is version-controlled. 🔥 How GitOps Works (Simple Flow) Developer pushes code to Git Pull Request gets reviewed Merge triggers CI pipeline GitOps controller (ArgoCD / Flux) detects change Cluster automatically syncs to desired state Deployment happens without manual intervention 🚀 💡 Why GitOps is a Game Changer ✔ Fully automated deployments ✔ Rollback with one Git commit ✔ Zero manual server access ✔ Better security & audit trail ✔ Faster release cycles ✔ Production stability improves significantly ⚠️ Reality Check Most companies still struggle with: ❌ Manual deployments ❌ Configuration drift ❌ Environment inconsistencies ❌ No rollback strategy GitOps solves all of these. 🧠 Tools Used in GitOps ArgoCD FluxCD Kubernetes Helm Terraform (for infra layer) GitHub / GitLab 🚀 Final Thought GitOps is not just a tool… It’s a culture shift in DevOps engineering. If your deployment is not Git-driven, you are already behind modern engineering teams. 💬 Want next-level guide? I can create: ✔ GitOps real project (ArgoCD + Kubernetes + Terraform) ✔ Interview Q&A set ✔ Step-by-step implementation roadmap ✔ DevOps training module for your students https://lnkd.in/gd_3gZwX #GitOps #DevOps #Kubernetes #CloudComputing #ArgoCD #FluxCD #CI_CD #InfrastructureAsCode #DevOpsEngineer #SRE #PlatformEngineering #CloudNative #Microservices #Docker #Automation #SoftwareEngineering #TechCareers #SystemDesign #Git #GitHub #CloudArchitecture #DevOpsLife #TechCommunity #Engineering #Learning #CareerGrowth #ITJobs #OpenSource