Mastering Git Stash for DevOps: A Key Skill

🔄 Restoring Lost Work with Git Stash — Hands-On DevOps Practice Today, I worked on an interesting Git task in the /usr/src/kodekloudrepos/demo repository on the Storage Server in Stratos DC. One of the developers had stored some changes using git stash, and my job was to restore those stashed changes safely and push them back to the remote repo. 🛠 What I Did ✔ Checked the repository status and verified the current branch (master) ✔ Viewed available stashes using: git stash list ✔ Inspected stash details using: git stash show ✔ Applied the correct stash (stash@{1}) ✔ Committed the restored file (welcome.txt) with the message: "Restore the stash 1" ✔ Successfully pushed changes to the remote repository 📌 Final Commands Used git stash list git stash show git stash apply stash@{1} git commit -m "Restore the stash 1" git push origin master 🚀 Outcome The previously stashed file was fully restored, committed, and pushed — ensuring no work was lost and the repository is back in a clean, consistent state. Always good to see how Git’s stash mechanism helps recover changes effortlessly during real-world DevOps workflows! 💡 #DevOps #Git #VersionControl #KodeKloudEngineer #GitStash #LearningByDoing #100DaysOfDevOps

🔄 Day 27 of #100DaysOfDevOps — Reverting Commits in Git “Failure is simply the opportunity to begin again, this time more intelligently.” – Henry Ford Today’s task was all about damage control in Git — something every DevOps engineer eventually faces. Here’s the scenario: The Nautilus application development team encountered an issue with the latest changes pushed to the repository located at: 📍 /usr/src/kodekloudrepos/demo on the Storage server in Stratos DC. The development team needed the repository rolled back to the previous stable commit. As part of the DevOps team, it was my job to: Identify the latest commit (HEAD) that introduced issues. Revert the repository to the previous commit, which contained the initial stable codebase. Create a new revert commit with the message revert demo message to document the rollback cleanly. This exercise reinforced why version control isn’t just about committing code, but also about managing mistakes gracefully. A well-structured revert ensures that the project history stays intact while swiftly neutralizing any bad changes. In real-world CI/CD pipelines, knowing how to revert without disrupting collaborators is a critical operational skill. It maintains velocity while preserving integrity. #100DaysOfDevOps #Day27 #Git #VersionControl #GitRevert #DevOpsJourney #ContinuousLearning #TechCommunity #SoftwareEngineering #InfrastructureManagement #GitOps #CodingJourney #ProfessionalGrowth #EngineeringExcellence #CommandLine #DevOpsCulture #ErrorRecovery #Teamwork #OpenSource #CloudComputing #TechGrowth

I'm excited to share this visual that clearly breaks down the difference between a traditional 𝗗𝗲𝘃𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗮𝗻𝗱 𝗮 𝗺𝗼𝗱𝗲𝗿𝗻 𝗚𝗶𝘁𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲! While both share the 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 (𝗖𝗜) steps from Source Code to Unit Test, Artifact Build, Image Build, and finally Image Registry the 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 (𝗖𝗗) stage is where GitOps truly changes the game. 𝗞𝗲𝘆 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀 𝗶𝗻 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁: 𝗗𝗲𝘃𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗: The deployment is typically push-based. After the image is built, a tool (like Jenkins, GitLab CI, etc.) pushes the new image to the Kubernetes Cluster. 𝗚𝗶𝘁𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗: The deployment is pull-based and Git-centric.  • The deployment configuration (𝗠𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝘀 𝗮𝗻𝗱 𝗖𝗵𝗮𝗿𝘁𝘀) is 𝘀𝘁𝗼𝗿𝗲𝗱 𝗶𝗻 𝗮 𝗚𝗶𝘁 𝗿𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆.  • The Container Version 𝗨𝗽𝗱𝗮𝘁𝗲 𝘁𝗿𝗶𝗴𝗴𝗲𝗿𝘀 𝗮 𝗣𝘂𝗹𝗹 𝗥𝗲𝗾𝘂𝗲𝘀𝘁 𝘁𝗼 𝘂𝗽𝗱𝗮𝘁𝗲 𝘁𝗵𝗲 𝗺𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝘀 𝗶𝗻 𝗚𝗶𝘁.  • A 𝗚𝗶𝘁𝗢𝗽𝘀 𝗧𝗼𝗼𝗹 (𝗹𝗶𝗸𝗲 𝗔𝗿𝗴𝗼𝗖𝗗 𝗼𝗿 𝗙𝗹𝘂𝘅) 𝗿𝘂𝗻𝘀 𝗶𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗰𝗹𝘂𝘀𝘁𝗲𝗿 𝗮𝗻𝗱 𝗽𝘂𝗹𝗹𝘀 the desired state from Git, syncing the cluster with the repository's source of truth. 𝗪𝗵𝘆 𝗚𝗶𝘁𝗢𝗽𝘀? 𝗦𝗶𝗻𝗴𝗹𝗲 𝗦𝗼𝘂𝗿𝗰𝗲 𝗼𝗳 𝗧𝗿𝘂𝘁𝗵: Git becomes the single, declarative source for your application and infrastructure state. 𝗔𝘂𝗱𝗶𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 & 𝗥𝗼𝗹𝗹𝗯𝗮𝗰𝗸: Every change is a committed version in Git, making auditing easier and rollbacks as simple as reverting a commit. 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: Clusters only need read access to the repo, avoiding the need for CI tools to hold sensitive cluster credentials. GitOps is the future of declarative infrastructure and Kubernetes management! 𝗪𝗵𝗮𝘁 𝗮𝗿𝗲 𝘆𝗼𝘂𝗿 𝗳𝗮𝘃𝗼𝗿𝗶𝘁𝗲 𝗚𝗶𝘁𝗢𝗽𝘀 𝘁𝗼𝗼𝗹𝘀? 𝗟𝗲𝘁 𝗺𝗲 𝗸𝗻𝗼𝘄 𝗶𝗻 𝘁𝗵𝗲 𝗰𝗼𝗺𝗺𝗲𝗻𝘁𝘀! 👇 #DevOps #GitOps #CI/CD #Kubernetes #CloudNative #ContinuousDeployment

💡The .gitignore file in Git helps you keep your repo clean by excluding unnecessary files like logs, temporary files, build outputs, or system-generated files from being tracked. It’s a simple yet powerful way to maintain a professional and clutter-free project repository. 🚀 #DevOps #Git

In real-time projects, Git is our best friend — but sometimes it becomes a puzzle! Here are some common Git issues teams face in day-to-day DevOps work 👇 🚫 Merge Conflicts — when multiple people change the same file or line. 💥 Detached HEAD State — happens when you checkout a commit instead of a branch. 🔁 Rebase gone wrong — leads to overwritten commits or lost changes. 🕵️ Wrong branch commits — pushing code to main instead of your feature branch. 🔒 Permission errors — while pushing or pulling due to access or SSH key issues. ✅ Tip: Always take a backup branch before doing a rebase or reset, and pull the latest changes before committing. Git is powerful — mastering it saves hours in debugging and helps maintain clean version control in any DevOps pipeline. #Git #GitHub #DevOps #VersionControl #CICD

🚀 𝟏𝟎𝟎 𝐃𝐚𝐲𝐬 𝐨𝐟 𝐃𝐞𝐯𝐎ps – 𝐌𝐲 𝐉𝐨𝐮𝐫𝐧𝐞𝐲 (𝐃𝐚𝐲 𝟐𝟑) 🚀 Day 23 of my 100 Days of DevOps challenge on KodeKloud is complete! Today's task shifted from the command line to the web UI to perform a core collaborative action: forking a Git repository. This is a fundamental step in the fork-and-pull-request workflow, which is central to modern development. 🔹 Today's Challenge: Fork a Git Repository Goal: As a new developer ('jon'), log in to the Gitea UI, locate a team repository, and create a personal fork to begin work without affecting the main codebase. • Log in to the Gitea server as user jon. • Find the existing repository named sarah/story-blog. • Fork this repository under the jon user account. 🧭 My Approach • Navigated to the Gitea UI and signed in with the jon user credentials. • Used the search bar to locate the sarah/story-blog repository. • Clicked the "Fork" button on the repository's main page. • Selected jon as the owner for the new forked repository. • Verified that I was redirected to jon/story-blog, confirming the fork was successful. ⚙️ Challenges Faced • This was a UI-driven task, so the main check was ensuring I was logged in as the correct user (jon) before initiating the fork. 🧩 Resolutions • The Gitea UI clearly prompts for which user/organization to fork to, making it easy to confirm the correct destination (jon). 💡 Key Takeaways • Forking vs. Cloning: A clone copies the repo, but a fork creates a new, separate server-side copy linked to the original (upstream). • Safe Development: Forking is the essential first step for contributing to a project you don't have direct push access to. You push changes to your fork, then open a Pull Request. • Foundation of Collaboration: This fork-and-PR model is the standard for open-source projects and many internal teams, as it protects the main branch and enables code review. This task was a great practical demonstration of the standard developer workflow in a shared code environment. On to Day 24! 💪 #100DaysOfDevOps #KodeKloud #DevOps #Git #Gitea #VersionControl #Collaboration #LearningJourney #KeepLearning #CI CD

Building My Own Full DevOps Environment — From Zero to Production 😊 Over the past weeks, I challenged myself to build a complete DevOps lifecycle — not just a demo, but a real, working environment that covers everything from infrastructure provisioning to CI/CD deployment on Kubernetes. And yes, everything is automated. What I Built I started by automating the installation of a Kubernetes v1.30.14 one master node cluster using Ansible, with: -- containerd as the CRI -- Calico as the CNI -- Docker and Helm integrated for flexibility The entire setup is fully idempotent, meaning it can rebuild itself from scratch in a clean and repeatable way. The CI/CD Stack Once Kubernetes was up, I deployed the DevOps core tools: 1-Jenkins for pipeline automation (Using Helm). 2-Nexus for private Docker registry management (Using Helm). 3-Gitea with MySQL as a lightweight Git service hosted inside the cluster (As Deployment) The CI/CD Pipeline Every time I push code to Gitea, a webhook triggers Jenkins to: 1-Pull the code 2-Run tests and build 3-Use Kaniko to build the Docker image securely (no Docker-in-Docker) 4-Push the image to Nexus 5-Automatically deploy the updated application on my Kubernetes cluster All of this happens without any manual steps. This project reflects months of learning, experimentation, and real DevOps problem-solving — covering networking, container runtimes, CI/CD automation, and infrastructure as code. ------------------------------------------------------------------------------------- For anyone interested in the technical details, I've open-sourced the entire project, including all Ansible playbooks, pipeline configurations, and K8s manifests. GitHub Repo: https://lnkd.in/d5DQA9dU #DevOps #Kubernetes #Ansible #Helm #Jenkins #Nexus #Gitea #Kaniko #CICD #Automation #Containerization #InfrastructureAsCode #LearningByDoing

💡 AZ-400 : 1 | Source Control with Git & Branching Strategies. Every strong DevOps pipeline begins with 'source control' — not just storing code, but enabling collaboration, traceability, and continuous delivery. 1️⃣ Feature Branch Workflow Concept: Each new feature or bug-fix is developed in its own branch, and merged back when ready. When to use: ▪️Teams where multiple features are worked on simultaneously. ▪️ Need isolation and independent work streams. Benefits: Clean isolation; easier rollback. Watch out for: Long-lived branches can drift and cause merge conflicts. 2️⃣ GitHub Flow Concept: Lightweight workflow where you branch off main, work, then open a Pull Request (PR) to merge back to main. Main is always deployable. When to use: ▪️Continuous deployment to production. ▪️Fast-moving teams working directly in GitHub. Benefits: Simpler model; promotes frequent integrations. Watch out for: Less suited for complex release versioning. 3️⃣ Branching Model for Continuous Delivery Concept: A strategic branching workflow where main, feature branches, and possibly release/hotfix branches are used. Emphasizes frequent merges and CI/CD readiness. When to use: ▪️Teams implementing continuous delivery practices. ▪️Need to stabilize main branch for frequent releases. Benefits: Keeps main always shippable; supports automated deployments. Watch out for: Requires strong automated testing and pipeline discipline. 💬 Concept Insight: Choosing the right branching strategy is not just about the code, but about how your team collaborates, releases, and delivers value continuously. 💡 Start with a simple model (GitHub Flow or Feature Branch), evolve into a robust continuous-delivery model when your pipeline grows. #AzureDevOps #Git #BranchingStrategies #GitHubFlow #FeatureBranches #ContinuousDelivery #CloudEngineer #LearningJourney

Dear DevOps, If you're still running Jenkins pipelines in 2025, you're not wrong but you're probably spending more time maintaining infrastructure than shipping features. The shift to GitHub Actions and ArgoCD isn't just about trendy tools. It's about treating your deployment process like code: versioned, reviewable, and declarative. Here's what's actually changing: instead of configuring Jenkins servers and managing plugins, teams define workflows in YAML that live right next to their application code. Instead of imperative deploy scripts, GitOps controllers like ArgoCD watch your Git repos and reconcile the desired state automatically. The practical wins? Multi-cloud deployments without custom scripting. Visual pipeline builders that non-ops team members can actually understand. And for K8s-heavy teams, declarative deploys that make rollbacks a Git revert away. But here's the reality check: GitOps isn't a silver bullet. It works brilliantly for container-native workloads. It's still maturing for legacy apps, database migrations, and stateful services. Start where it makes sense: containerized microservices, infrastructure-as-code, and environments that benefit from audit trails. Don't rip out working CI/CD just to chase the hype. The 2026 job market is clear though GitHub Actions experience is becoming table stakes. Not because it's the only way, but because it represents a fundamental shift toward Git as the single source of truth. Learn it now. Your future interviews will thank you. #GitOps #GitHubActions #ArgoCD #CICD #Kubernetes #DevOps