CI/CD Pipeline: What Happens After Git Push

🚀 GitHub for DevOps – Day 4 (Part 2) 🔥 Git Reset Practical — Hands-on Lab Let’s stop theory and actually see what happens 👇 🧪 Step 1: Create Repo mkdir git-reset-lab cd git-reset-lab git init 🧪 Step 2: Create Commits echo "Version 1" > file.txt git add . git commit -m "v1 commit" echo "Version 2" >> file.txt git add . git commit -m "v2 commit" echo "Version 3" >> file.txt git add . git commit -m "v3 commit" 👉 Current state: v1 → v2 → v3 🔥 PART 1: SOFT RESET git reset --soft HEAD~1 ✔ v3 commit removed ✔ Changes still staged 👉 Check: git status 💡 Perfect for fixing commit messages 🔥 PART 2: MIXED RESET git reset HEAD~1 ✔ Commit removed ✔ Changes remain in file ❌ Not staged 👉 You must run: git add . 🔥 PART 3: HARD RESET (⚠️ Dangerous) git reset --hard HEAD~1 ❌ Commit removed ❌ Changes deleted permanently 👉 File goes back to: Version 1 Version 2 🧠 Final Understanding Soft → Keep changes staged Mixed → Keep changes in files Hard → Delete everything 💬 If you cannot control Git history, you cannot survive in real DevOps environments. Follow for more real-world DevOps learning 🚀 #HiteshDevOps #DevOps #Git #GitHub #CI_CD #Docker #Kubernetes #AWS #OpenToWork #HiringDevOps #DevOpsEngineer #TechHiring   #LearningInPublic #BuildInPublic #TechJourney

Day 2 of actually learning Git properly. My CS degree gave me a lot—algorithms, data structures, the whole nine yards. But version control? We touched it once and called it a day. So here I am, playing catch-up. Learned about git config—turns out Git needs to know who you are before it lets you do anything. Simple, but somehow I never stopped to think about why my commits were always showing up with the wrong name. Also finally understand the difference between tracked and untracked files. Sounds basic, I know. But I used to just git add . everything like a caveman and hope for the best. On top of that, I started reading about the DevOps lifecycle. Interesting stuff, but honestly? Theory is great, but actually managing code with a team? That's a different beast entirely. Small steps. But at least now when I break something, I'll know who's to blame (me, it's always me). What's a basic Git thing that took you embarrassingly long to figure out? Asking so I don't feel alone here. #DevOps #Git #ComputerScience #LearningInPublic #Day2

3 months ago, I had no idea what GitOps even meant. 🤷 Today, I'm running production deployments with ArgoCD on Kubernetes — and I'll never go back to manual kubectl apply again. Here's everything I learned 👇 ☸️ What is GitOps? Your Git repo IS the source of truth. If it's in Git → it's in your cluster. Period. No more "works on my machine" deployments. 🔁 How ArgoCD changed my workflow: → Push code to Git → ArgoCD detects the change automatically → Syncs it to the Kubernetes cluster → Done. Zero manual steps. 🔥 What I actually built: ✅ Set up ArgoCD on a K8s cluster from scratch ✅ Connected it to my GitHub repo ✅ Configured auto-sync so every push = live deployment ✅ Added health checks so broken deploys never go live ✅ Used Helm charts for cleaner app management 💡 The biggest mindset shift? Stopped thinking "I'll deploy from my terminal" Started thinking "I'll deploy by pushing to Git" That one shift makes your deployments: 📌 Auditable — every change is a Git commit 📌 Reversible — bad deploy? git revert and done 📌 Automated — no human in the loop 🚀 If you're learning DevOps and haven't tried ArgoCD yet — start today. It's genuinely one of the most satisfying tools to set up. GitHub: https://lnkd.in/dHCw_eWR #Kubernetes #ArgoCD #GitOps #DevOps #CloudEngineering #LearningInPublic #K8s #CI_CD

I think Git becomes truly important the day something breaks. Before that, it just feels like a tool for pushing code. But the moment a deployment fails, the first question changes everything: “What changed?” Without Git, that question becomes painful. With Git, you can track changes, see history, compare versions, and understand who changed what and when. That is why Git is not just for developers. It is one of the foundations of DevOps. A simple workflow already teaches a lot: git status git add . git commit -m "update login fix" These are not just commands. They create traceability. And in DevOps, traceability matters a lot. When code moves through build, test, and deployment stages, teams need confidence in what exactly is being shipped. One beginner mistake I see often is using Git like cloud storage. Push everything. Save everything. Move on. But Git is much more useful when you use it intentionally: small commits, clear messages, meaningful history. One thing I am learning is this: In DevOps, speed matters. But safe speed matters more. And Git helps create that safety. Do you use Git more from the command line or from GitHub UI? #Git #GitHub #DevOps #VersionControl #LearnDevOps #SoftwareEngineering #Automation

GitOps — Is It Stupid or Brilliant? In the beginning, there was only one. One person writing the code for a small application. One person maintaining that tiny switched network. But software grows. Infrastructure grows. Teams grow. And suddenly you’re troubleshooting at 10 PM asking: Who added these lines of code? Why was this config pushed to the switch? Is this still needed? We’ve all been there. As complexity increases, changes happen constantly. Without visibility and traceability, you’re left guessing who did what — and why. When Linus Torvalds created Git to manage development of the Linux kernel, he solved a massive coordination problem: distributed development at scale. Git became more than a version control system. It became an information management system. Today, we use it not just for code — but for infrastructure and configuration. And that’s where GitOps comes in. --- The Beauty of Git You don’t need to know everything to start. At its core: git clone git add git commit git push That’s enough to begin. Behind these simple commands, you get: ✅ Full change tracking ✅ Accountability (who changed what) ✅ Context (why it changed — if commit messages are meaningful) ✅ History you can revert to No more guesswork. --- Git Is a Tool. GitOps Is a Practice like DevOps. The key idea: The repository is the single source of truth. Not the production server. Not someone’s laptop. Not a late-night manual CLI change. If it’s not in Git — it doesn’t exist. GitOps extends this principle to infrastructure: Store infrastructure and configuration in Git Use automated pipelines to deploy changes Ensure production always reflects what’s in the repository In simple terms: GitOps = Version control + Automation + Discipline --- Is GitOps stupid? Well, fun fact: Linus once said Git was “stupid.” But that “stupid” tool changed how the world builds software. Maybe GitOps isn’t about being clever. Maybe it’s about being consistent. And in complex systems, consistency beats heroics every time. So… Git going. Git commit. Git it done. #GitOps #DevOps #InfrastructureAsCode #Automation #Cloud #SRE

🚀 DevOps Learning Series Git Merge vs Git Rebase — two ways to combine code, one way to start arguments 🧑💻🍿 When multiple developers touch the same repo, Git has two main ways to bring branches together: Merge and Rebase. - Both work. - Both are powerful. - Both can ruin your day if used wrong. 🔀 Git Merge (The Honest Historian) git merge feature-branch What it does: - Combines branches - Keeps complete commit history - Creates a merge commit 🧠 Think of it like: Two timelines meeting and saying “Let’s record exactly what happened.” ✔ Safe ✔ Transparent history ✔ Good for shared branches 🧹 Git Rebase (The History Cleaner) git rebase main What it does: - Replays your commits on top of another branch - Creates a linear history - No extra merge commit 🧠 Think of it like: Pretending your branch started from the latest code all along. ✔ Cleaner commit history ✔ Easier to read logs ✔ Preferred before merging PRs ⚠️ DevOps Golden Rule Never rebase shared or public branches. Because rewriting history in a team repo is like editing the past in a shared Google Doc 😅 💡 TL;DR merge → honest history rebase → clean history Both are useful. Just don’t time-travel in a shared branch 🚀 #DevOps #Linux #CloudComputing #SystemAdministration #LearningInPublic #TechCareers #TrainWithShubham

🚀 𝗪𝗵𝗮𝘁 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗛𝗮𝗽𝗽𝗲𝗻𝘀 𝗪𝗵𝗲𝗻 𝗬𝗼𝘂 𝗣𝘂𝘀𝗵 𝗖𝗼𝗱𝗲 𝘁𝗼 𝗚𝗶𝘁𝗛𝘂𝗯? Most beginners think “𝗴𝗶𝘁 𝗽𝘂𝘀𝗵” 𝗷𝘂𝘀𝘁 𝘂𝗽𝗹𝗼𝗮𝗱𝘀 𝗰𝗼𝗱𝗲. But in real DevOps environments… That single command can 𝘁𝗿𝗶𝗴𝗴𝗲𝗿 𝗮𝗻 𝗲𝗻𝘁𝗶𝗿𝗲 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲. 💼 𝗜𝗻 𝗿𝗲𝗮𝗹 𝗰𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀... When developers push code to GitHub, it often starts a 𝗖𝗜/𝗖𝗗 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄. 𝗧𝗵𝗮𝘁 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝗺𝗮𝘆 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰𝗮𝗹𝗹𝘆: • Run automated tests • Build the application • Scan for vulnerabilities • Build Docker images • Deploy to staging or production So a simple 𝗽𝘂𝘀𝗵 𝗰𝗮𝗻 𝘁𝗿𝗶𝗴𝗴𝗲𝗿 an entire 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲. ⚙️ 𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘀𝘁𝗲𝗽-𝗯𝘆-𝘀𝘁𝗲𝗽? 1️⃣ Developer writes code locally 2️⃣ Code is committed with git commit 3️⃣ Code is pushed to GitHub with git push 4️⃣ GitHub stores the new commit in the repository 5️⃣ Webhooks trigger CI tools (Jenkins, GitHub Actions, etc.) 6️⃣ CI pipeline starts build + tests 7️⃣ Artifacts are created (Docker image, binaries) 8️⃣ CD pipeline may deploy automatically This is how 𝗺𝗼𝗱𝗲𝗿𝗻 𝗗𝗲𝘃𝗢𝗽𝘀 𝘁𝗲𝗮𝗺𝘀 𝘀𝗵𝗶𝗽 𝗰𝗼𝗱𝗲 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝘁𝗶𝗺𝗲𝘀 𝗽𝗲𝗿 𝗱𝗮𝘆. 🧠 𝗦𝗶𝗺𝗽𝗹𝗲 𝗮𝗻𝗮𝗹𝗼𝗴𝘆  • Think of GitHub like a switch that starts a factory machine.  • You press the switch (git push)  • And suddenly the factory starts:  • Code → Build → Test → Package → Deploy ❌ 𝗖𝗼𝗺𝗺𝗼𝗻 𝗺𝗶𝘀𝘁𝗮𝗸𝗲 𝗯𝗲𝗴𝗶𝗻𝗻𝗲𝗿𝘀 𝗺𝗮𝗸𝗲 They think: 𝗚𝗶𝘁𝗛𝘂𝗯 = 𝗼𝗻𝗹𝘆 𝗰𝗼𝗱𝗲 𝘀𝘁𝗼𝗿𝗮𝗴𝗲. ❌ 𝗡𝗼𝘁 𝘁𝗿𝘂𝗲. GitHub is also the 𝗲𝘃𝗲𝗻𝘁 𝘁𝗿𝗶𝗴𝗴𝗲𝗿 𝗳𝗼𝗿 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀. 🎯 𝗜𝗳 𝘆𝗼𝘂 𝗿𝗲𝗺𝗲𝗺𝗯𝗲𝗿 𝗢𝗡𝗘 𝘁𝗵𝗶𝗻𝗴  • git push is not just uploading code.  • It can start the entire DevOps delivery pipeline. 💬 𝗛𝗼𝘄 𝗺𝗮𝗻𝘆 𝘁𝗶𝗺𝗲𝘀 𝗽𝗲𝗿 𝗱𝗮𝘆 𝗱𝗼𝗲𝘀 𝘆𝗼𝘂𝗿 𝘁𝗲𝗮𝗺 𝗽𝘂𝘀𝗵 𝗰𝗼𝗱𝗲? 𝗙𝗼𝗹𝗹𝗼𝘄 𝗼𝘂𝗿 𝗟𝗶𝗻𝗸𝗲𝗱𝗜𝗻 𝗣𝗮𝗴𝗲 𝗳𝗼𝗿 𝗱𝗮𝗶𝗹𝘆 𝗰𝗹𝗼𝘂𝗱 𝗰𝗹𝗮𝗿𝗶𝘁𝘆: https://lnkd.in/dN4JSkfH 𝗝𝗼𝗶𝗻 𝗼𝘂𝗿 𝗪𝗵𝗮𝘁𝘀𝗔𝗽𝗽 𝗖𝗹𝗼𝘂𝗱 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆: https://lnkd.in/dTJfEFyK 𝗪𝗲𝗯𝘀𝗶𝘁𝗲: www.vyomanant.com #DevOps #GitHub #CICD #Docker #Kubernetes #CloudComputing #DevOpsEngineer #LearnDevOps #VyomanantAcademy #Vyomanant

🚨 DevOps Learning: When GitHub Rejects Your Push Because of Large Files Today I ran into an interesting Git issue while pushing my DevSecOps project to GitHub from an EC2 instance. Everything looked fine locally, but GitHub rejected my push with this error: GH001: Large files detected The reason? Some binaries were accidentally committed to the repository: • argocd-linux-amd64 (205 MB) • awscliv2.zip (63 MB) • kubectl (55 MB) GitHub limits file sizes: ⚠ Recommended: 50 MB ❌ Maximum: 100 MB So the push failed. 🔧 The Fix 1️⃣ Remove the files from Git tracking git rm --cached <file> 2️⃣ Add them to .gitignore 3️⃣ Clean the Git history because large files still exist in previous commits git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <file>' --prune-empty --tag-name-filter cat -- --all 4️⃣ Force push the cleaned history git push origin main --force 💡 DevOps Best Practice Never commit binaries like: • kubectl • awscli zip files • ArgoCD binaries Instead install them via scripts or package managers in your setup pipeline. This was a great reminder that Git tracks history, not just current files. Every small issue in DevOps is a learning opportunity 🚀 #DevOps #Git #GitHub #Kubernetes #ArgoCD #Terraform #LearningByDoing

🚀 Git Learning Series – Part 2: Branching Strategy Explained After understanding Git basics and SSH setup, the next important concept is: 🌿 Git Branching Strategy Many beginners ask: 👉 Why do we need branches? Because in real projects, you should never work directly on "main". --- 🔑 What is a Branch? A branch is like a separate workspace where you can: ✔ Develop features ✔ Fix bugs ✔ Experiment safely Without affecting the main code. --- 🔥 Common Branching Workflows 1️⃣ Feature Branch Workflow (Most Used) - Create branch from main - Work on your feature - Push → Raise PR → Merge Example: git checkout -b feature/login-api --- 2️⃣ GitHub Flow (Simple & Powerful) - Only main + feature branches - Direct PR → review → merge ✔ Best for startups & small teams --- 3️⃣ Git Flow (Structured) - main → production - develop → active development - feature / release / hotfix branches ✔ Used in large enterprise projects --- 4️⃣ GitLab Flow - Includes environments like: - preprod - production ✔ Useful for DevOps pipelines --- ⚠️ Beginner Mistake 🚫 Working directly on main ✅ Always create a feature branch --- 📘 Follow for more hands-on Git & DevSecOps learning DevSecOps Learning Hub #Git #GitHub #DevOps #DevSecOps #CI_CD #Automation #CloudSecurity #SoftwareEngineering #LearningInPublic #TechLearning #Developers #VersionControl #OpenSource #CareerGrowth #Engineering

🚀 DevOps Multi-Cloud Learning Journey – Day 14 Today’s session was focused on advanced Git commands, which are essential for efficient version control and managing code history. Key learnings: ⚙️ git config – Configure username and email ✏️ git commit --amend – Modify last commit 🚫 .gitignore – Ignore unnecessary files 🔄 git reset (soft & hard) – Undo changes in different ways 🍒 git cherry-pick – Apply specific commits 📜 git reflog – Track all Git activities 🔍 git log -p – View detailed commit changes These concepts help in better control, debugging, and managing project history in real-time development. Frontlines EduTech (FLM) #DevOps #Git #VersionControl #AWS #CloudComputing #LearningJourney #TechSkills #ContinuousLearning #FrontlinesEduaTech #FLM