10 Git & GitHub Scenarios for DevOps Engineers

Day 12/100 – Git & GitHub Deep Dive: Restore, Reset & Force Push 🔁🐙 Today was all about fixing mistakes in Git the right way — something every developer & DevOps engineer faces in real projects. I learned how to safely undo changes, uncommit code, and even force push when local and remote histories don’t match. 🛠️ What I did today ✔ Cloned a GitHub repository ✔ Modified files in the working directory ✔ Checked file states using git status ✔ Used git restore to discard changes ✔ Used git restore --staged to unstage files ✔ Configured Git username & email ✔ Committed changes with proper messages ✔ Explored git reset (soft, mixed & hard) ✔ Understood commit history using git log ✔ Fixed wrong commits using reset ✔ Used force push to sync local & remote branch ✔ Learned how companies handle private repos & tokens 🔁 Git File Lifecycle Working Directory → Staging Area → Commit History → Remote Repository (GitHub) 🔄 Reset Types Explained Soft Reset → Removes commit → Keeps changes staged Mixed Reset → Removes commit → Keeps changes in working directory Hard Reset → Removes commit → Deletes changes completely (⚠️ careful) 🚀 Important Commands Used gitclone <repo-url> git status # Discard local changes git restore index.html # Unstage files git restore --staged index.html # Stage & commit git add . git commit -m"Updated index.html" # View history gitlog --oneline # Reset commits git reset --soft HEAD~1 git reset --mixed HEAD~1 git reset --hard HEAD~1 # Force push git push -f origin main 🔐 Private Repository Access ✔ Companies use private repositories ✔ Cloning requires Personal Access Token (PAT) ✔ Tokens are safer than passwords ✔ Token-based access is industry standard 💡 Key Learnings ✔ Git mistakes are normal — fixing them is a skill ✔ Restore helps discard unwanted changes ✔ Reset helps fix wrong commits ✔ Force push should be used carefully ✔ Understanding Git internals = confidence at work ✔ Essential knowledge for DevOps & real projects 📌 Save this post — Git reset & force push are frequently asked in interviews. #Git #GitHub #DevOps #VersionControl #SoftwareDevelopment #CloudCareers #Linux #100DaysOfDevOps #SRTechOps

𝐆𝐢𝐭 𝐂𝐨𝐦𝐦𝐚𝐧𝐝𝐬 𝐄𝐯𝐞𝐫𝐲 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫 𝐒𝐡𝐨𝐮𝐥𝐝 𝐊𝐧𝐨𝐰 🚀 People rush into CI/CD, Docker, Kubernetes… but struggle with Git basics. If you want to work confidently in any tech team, Git is non-negotiable. Here’s a clean, practical Git cheat-sheet every developer & DevOps engineer should know 👇 ✔ 𝐠𝐢𝐭 𝐢𝐧𝐢𝐭 →  Create an empty Git repository or reinitialize an existing one ✔ 𝐠𝐢𝐭 𝐬𝐭𝐚𝐭𝐮𝐬 → Show the working tree status ✔ 𝐠𝐢𝐭 --𝐯𝐞𝐫𝐬𝐢𝐨𝐧 → Check the Git version ✔ 𝐠𝐢𝐭 𝐚𝐝𝐝 . →  Add files to the staging area ✔ 𝐠𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 -𝐦 "𝐦𝐞𝐬𝐬𝐚𝐠𝐞" → Save your changes to the local repository ✔ 𝐠𝐢𝐭 𝐥𝐨𝐠 → See commit history ✔ 𝐠𝐢𝐭 𝐝𝐢𝐟𝐟 → Check what has changed before committing ✔ 𝐠𝐢𝐭 𝐩𝐮𝐬𝐡 → Send your changes to the remote repository ✔ 𝐠𝐢𝐭 𝐜𝐨𝐧𝐟𝐢𝐠 --𝐠𝐥𝐨𝐛𝐚𝐥 𝐮𝐬𝐞𝐫.𝐧𝐚𝐦𝐞 "𝐘𝐨𝐮𝐫 𝐍𝐚𝐦𝐞" → Sets the global username. ✔ 𝐠𝐢𝐭 𝐜𝐨𝐧𝐟𝐢𝐠 --𝐠𝐥𝐨𝐛𝐚𝐥 𝐮𝐬𝐞𝐫.𝐞𝐦𝐚𝐢𝐥 "𝐲𝐨𝐮𝐫𝐞𝐦𝐚𝐢𝐥@𝐞𝐱𝐚𝐦𝐩𝐥𝐞.𝐜𝐨𝐦"→ Sets the global email. ✔ 𝐠𝐢𝐭 𝐜𝐥𝐨𝐧𝐞 <𝐫𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲_𝐮𝐫𝐥> → Creates a copy of a remote repository on your local machine. ✔ 𝐠𝐢𝐭 𝐜𝐥𝐞𝐚𝐧 -𝐧 → Shows a list of untracked files that will be removed. ✔ 𝐠𝐢𝐭 𝐜𝐥𝐞𝐚𝐧 -𝐟 → Removes untracked files from the working directory. ✔ 𝐠𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡 → List all local branches ✔ 𝐠𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡 𝐛𝐫𝐚𝐧𝐜𝐡-𝐧𝐚𝐦𝐞 → Create a new branch ✔ 𝐠𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 𝐛𝐫𝐚𝐧𝐜𝐡-𝐧𝐚𝐦𝐞 → switches to another branch ✔ 𝐠𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 -𝐛 𝐛𝐫𝐚𝐧𝐜𝐡-𝐧𝐚𝐦𝐞 → creates a branch and switches to it ✔ 𝐠𝐢𝐭 𝐦𝐞𝐫𝐠𝐞 𝐛𝐫𝐚𝐧𝐜𝐡-𝐧𝐚𝐦𝐞 → merges another branch into the current/master branch ✔ 𝐠𝐢𝐭 𝐛𝐫𝐚𝐧𝐜𝐡 -𝐝 𝐛𝐫𝐚𝐧𝐜𝐡-𝐧𝐚𝐦𝐞 → deletes a branch after the work is done  ✔ 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 → Used when you want to undo local changes. ✔ 𝐠𝐢𝐭 𝐫𝐞𝐯𝐞𝐫𝐭 → Safely undo a commit  ✔ 𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡 → Temporarily save work when you’re not ready to commit If you’re learning DevOps or working as a developer master Git before chasing advanced tools. #git #DevOps #CloudComputing #LearningInPublic #TechSkills #Beginners #ITCareer #Practice

🚀 Git Commands Every Developer Should Know 💻 Hey LinkedIn fam 👋 If you're working with Git & GitHub, excelling at these commands is non-negotiable for aspiring DevOps engineers and tech enthusiasts 🌐 📝 Essential Git Commands Cheat Sheet: Repo Setup: - git init - Initialize a new repository - git clone - Clone an existing repository Day-to-Day Workflow: - git pull - Fetch and merge changes from remote - git commit - Save changes to local repository - git push - Upload local commits to remote - git add - Stage changes for commit Branching & Collaboration: - git checkout - Switch between branches - git merge - Combine branches together - git branch - Create and manage branches - git rebase - Reapply commits on top of another branch Debugging & Recovery: - git revert - Create new commit that undoes previous changes - git cherry-pick - Apply specific commits from other branches - git stash - Temporarily save uncommitted changes - git reset - Undo commits and changes These commands are what you use daily in real projects, not just interviews. From initializing a repo to handling branches, merges, rebases, and fixing mistakes - understanding when and why to use each command is critical. 👉 If you truly want to work like a professional developer or DevOps engineer, don't just memorize commands. Spend time understanding their practical applications and how they fit into your workflow. Git mastery is important, so make sure you practice these commands regularly. HAPPY LEARNING :) #DevOps #CloudEngineer #AWS #Azure #Cloud

Most DevOps engineers work with Git every day— yet only a few know how to troubleshoot Git issues with confidence. This guide focuses on real-world Git debugging skills that go far beyond basic commands. What you’ll learn inside: 🔥 Diff & Patch Analysis — using git diff, word-level changes, stats, and commit inspection 🔥 Commit Investigation — advanced git log filtering, regex searches, and author-based queries 🔥 Pinpointing the Problem Commit — identifying the exact change using git bisect 🔥 Reflog Recovery — restoring lost commits, branches, and accidental resets 🔥 Branch & Merge Troubleshooting — merge-base analysis, cherry-pick strategies, and safe reverts 🔥 Stash Debugging — recovering and managing “missing” local changes 🔥 File-Level History & Blame Analysis 🔥 Low-Level Git Internals — inspecting objects and repository integrity 🔥 Submodules & Worktrees — managing complex repositories safely 🔥 Remote & Network Debugging — diagnosing push, pull, and connectivity issues This is the Git reference I wish I had early in my DevOps journey. If you’re serious about mastering Git for production environments, incident recovery, and interviews, this guide will significantly sharpen your skills. #git #github #devOps #storage #versioning #branching #preparation

🚀 Master the Git Workflow: A Quick Guide Whether you're a seasoned dev or just starting, these 20 commands are your bread and butter. Here is the simple breakdown: 🛠️ The Basics git init: 🆕 Create a brand new local repository. git config: 👤 Set your identity (name & email). git clone: 👯 Copy an existing remote project to your machine. git remote: 🔗 Manage connections to external repositories. 📝 Daily Development git status: 👀 See what files you've changed or staged. git add: 📥 Move changes to the "staging area" (prepare for save). git commit: 💾 Save your staged changes to project history. git push: 📤 Upload your local saves to the cloud (GitHub/GitLab). 🔄 Staying Updated git pull: 📥 Download and merge updates from teammates. git fetch: 🔍 See what’s new on the remote without merging yet. git branch: 🌿 Create or list different versions of the project. git checkout: 🏃♂️ Jump between different branches. 🔀 Merging & Cleaning git merge: 🤝 Combine work from two different branches. git rebase: 🪜 Move your commits to a new starting point for a cleaner history. git log: 📖 View the "timeline" of every save ever made. git diff: 📋 Compare exactly what lines of code changed. 🆘 The "Oops" & Advanced Tools git stash: 📦 Temporarily hide messy work to fix a quick bug elsewhere. git reset: ⏪ Unstage files or undo commits entirely. git revert: 🛡️ Create a "counter-commit" to undo a past mistake safely. git cherry-pick: 🍒 Grab one specific commit from another branch and apply it here. Which Git command do you use most often? Let me know in the comments! 👇 #SoftwareDevelopment #CodingTips #Git #Programming #WebDev #TechCommunity

🚀 Day 34 of #100DaysOfDevOps with #KodeKloud 🚀 Today's challenge was all about Git Hooks 🧠 Need to Know Git provides a way to trigger custom scripts when certain important actions occur. There are two types of hooks: client-side and server-side. 🔹 Client-side: triggered by operations such as committing and merging 🔹 Server-side: triggered by network operations such as receiving pushed commits To install a hook, you just need to rename it by removing .sample from its name in the .git/hooks directory The task was to create a post-update hook to generate a release tag for each push. The post-update hook runs right after a push is completed on the remote repository. Here's How I Did It: 🔹 Merged the feature and master branches in the repository 🔹 Went to the remote repository (/opt/ecommerce.git), accessed the Git hooks, and updated the post-update hook by removing .sample from its name and changing its content to: #!/bin/bash if [ "$1" = refs/heads/master ]; then echo "Creating release tag" git tag release-date '+%Y-%m-%d' master fi 🔹 Went back to the local repository and pushed the changes 🔹 Tested the release tag in the remote repository using git tag 🔹 Verified the tag release-2026-02-05 💡 Key Takeaways: ✅ Since this specific hook is a server-side one, the configuration and script must be in the remote repository, not the local one (took me a while to figure that out!). ✅ There are many other useful hooks as well, such as: 🔸pre-commit: runs first, before you even type a commit message. 🔸post-commit: runs after a commit is made. often used for notifications or similar tasks. 🔸 post-merge: runs after a successful merge. It can be used to restore data that Git doesn't track, such as file permissions. …and many others that perform specific tasks at different stages of the Git workflow. Have a good Day, everyone! 🦬 #GitHooks #DevOps #AutomationScripting

I just published a new piece on Medium about my latest DevOps assignment: Real-World Git: Moving Beyond "Push and Pray." This week wasn't just about running commands; it was about understanding the professional workflow of forking, branching, and opening Pull Requests. I hit some real friction with authentication and synchronization errors, but solving those taught me more than a perfect run ever could. What’s inside: - The difference between origin and upstream. - Why Personal Access Tokens (PAT) are the new standard. - How I fixed "No such remote" and push rejection errors. - The importance of single-purpose commits. Check out the full story of my technical hurdles and breakthroughs here: https://lnkd.in/dB9j2tFS #DevOps #Git #GitHub #TechWriting #ContinuousLearning

Stepping into the world of Git & GitHub! I’ve been learning how developers collaborate, manage versions, and track code using Git and GitHub — and it’s been super exciting! Here are some key commands : 🛠️ Setup & Configuration git config --global user.name "jayasrk" git config --global user.email "jaya79@gmail.com" git init git clone <repository-url> git remote add origin <url> 📂 Tracking & Staging Files git status git add filename git add . # adds all files 💬 Commit & Push Changes git commit -m "commit message" git push origin main git pull git push origin main --force 🌿 Branch Management git branch git branch -M main git checkout branchname Each command taught me how developers organize their projects, collaborate in teams, and contribute to open-source efficiently 🌍 #Git #GitHub #CodingJourney #VersionControl #BeginnerToPro #DevOps #Cloud

Why Git is the Go-To option for Code, Configuration ? We all know that application code is stored in the github repos and every team is dependent on it as it offers many advantages like - Audit Trail - Using git revert we can roll back changes easily - We can see when each change was made, who made it and what changes they made - Everything is Version Controlled - Life Saviour in team environments - Approvals via Pull Requests It didnt stop with application code but also extended to application configurations like terraform code, K8s manifests, helm charts, ansible playbooks, chef recipes, puppet manifests, pipeline code, custom code etc., All of these things are moving towards Git. Lets say we have a team of 5 people and currently there are 5 replicas running for a deployment, a devops engineer went to k8s cluster and changed the no of replicas from 5 to 3, now suddenly the pods metrics went up as only 3 are serving the traffic to the end users. When we see the no of pods its 3 instead of 5, no body is taking the ownership. How do we find who made the change. Git solves these problem. So all the changes will go via Git, the code can be merged only when Lead approves the Pull Request, so without git the k8s manifests are scattered across engineers laptop. With git everything is put in place. Rollback is also made easy with git commands, we can also see the change history using git log command, git revert command to go back to previous commit, git gives powerful branching strategies so we can do parallel development without touching the current production code ( main branch ). Also one big advantage git offers is single source of truth, if i hear that term the first thing the comes in my mind is GitOps ArgoCD, and its because the argocd checks what is currently present in the git ( desired state ) and compares it with what is being present in the K8s cluster ( current state ). It is similar to how terraform state file compares current state, desired state and make necessary changes, even ArgoCD does the same. ArgoCD is able to do this because of git stores the code and its the desired state. ➕ Follow Sai P. for more insights ♻ Repost to help others 📩 Save for later #github #singlesourceoftruth #rollback #auditing #compliance #ISO #PCIDSS #SOC2 #git #K8s #ansible #applicationcode #configuration #manifests #versioncontrol #rollout

 Day 1: The Mental Model 𝐒𝐭𝐨𝐩 𝐭𝐫𝐞𝐚𝐭𝐢𝐧𝐠 𝐆𝐢𝐭 𝐥𝐢𝐤𝐞 𝐚 𝐬𝐢𝐦𝐩𝐥𝐞 "𝐬𝐚𝐯𝐞 𝐛𝐮𝐭𝐭𝐨𝐧." 🛑 When I first started, I thought Git was just a magic sequence: git add → commit → push. I was wrong. To move from "Junior" to "Senior" DevOps, you have to stop thinking about files and start thinking about 𝐓𝐡𝐞 𝐓𝐡𝐫𝐞𝐞 𝐓𝐫𝐞𝐞𝐬. Understanding the relationship between your Working Directory, the Staging Area, and the Local Repository is the "lightbulb moment" for engineers. Here is the mental model I built to visualize how data 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 moves through the Git lifecycle. 𝐓𝐡𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐨𝐟 𝐚 𝐂𝐨𝐦𝐦𝐢𝐭: 𝟏. 𝐖𝐨𝐫𝐤𝐢𝐧𝐠 𝐃𝐢𝐫𝐞𝐜𝐭𝐨𝐫𝐲 📂 The chaotic scratchpad where you mess things up. It's untracked and messy. 𝟐. 𝐒𝐭𝐚𝐠𝐢𝐧𝐠 𝐀𝐫𝐞𝐚 (𝐓𝐡𝐞 𝐈𝐧𝐝𝐞𝐱) 📝 The "Loading Dock." This is your quality control gate. It allows you to craft granular, meaningful commits instead of dumping a "work in progress" mess into history. 𝟑. 𝐋𝐨𝐜𝐚𝐥 𝐑𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲 💾 The permanent database. This is why Git is fast—you aren't talking to a server, you are talking to your local history. 𝟒. 𝐑𝐞𝐦𝐨𝐭𝐞 𝐑𝐞𝐩𝐨𝐬𝐢𝐭𝐨𝐫𝐲 ☁️ The synchronization point. It’s just another copy of the database, somewhere else. Stop guessing why your merge failed. Visualize where your code is sitting right now, and the commands will finally make sense. 👇 𝐒𝐚𝐯𝐞 𝐭𝐡𝐢𝐬 𝐝𝐢𝐚𝐠𝐫𝐚𝐦. 𝐈𝐭 𝐜𝐫𝐞𝐚𝐭𝐞𝐬 𝐭𝐡𝐞 𝐦𝐞𝐧𝐭𝐚𝐥 𝐦𝐚𝐩 𝐟𝐨𝐫 𝐞𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 𝐞𝐥𝐬𝐞 𝐰𝐞 𝐰𝐢𝐥𝐥 𝐥𝐞𝐚𝐫𝐧. #DevOps #Git #LearningInPublic #SoftwareEngineering #TechCareers