Git Fundamentals for DevOps Engineers

🚀 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

🚨 My CI/CD pipeline broke before it even ran — and the issue wasn’t what I expected. While working on my Jenkins-based CI/CD pipeline for a Java Maven application, I hit a failure that completely blocked execution. No build logs. No runtime error. Just an immediate pipeline failure. In a real production environment, this would mean: ❌ No builds ❌ No deployments ❌ Broken automation flow 🔧 What I Was Working On - Jenkins setup and pipeline architecture - Writing and executing my first Jenkinsfile - Automating Java Maven builds - Building Docker images inside Jenkins - Attempting Docker Hub image pushes This was my first step into full CI/CD automation. 🔥 The Problem The pipeline failed immediately with: unexpected token: } 👉 Root cause: a syntax error in the Jenkinsfile (Groovy) This was a key realization: CI/CD pipelines don’t need runtime execution to fail — they can break purely from misconfiguration. 🔍 How I Fixed It Instead of treating it as a simple fix, I took ownership of the full pipeline: - Cloned and migrated the project from GitLab to my own GitHub repository - Took full control of the Jenkinsfile - Rebuilt and tested the pipeline step-by-step - Debugged syntax issues directly in Groovy pipeline code - Iterated through multiple pipeline runs to validate fixes 🚨 Other Issues I Encountered - Docker Hub authentication failures during image push - Incorrect CLI flag usage during login (-u vs -U) - Credential handling inside Jenkins pipelines - Understanding secure authentication in CI/CD workflows Each issue exposed another layer of how fragile automation can be without correct configuration. 💡 Key DevOps Lessons - CI/CD pipelines fail at multiple layers: code, config, and credentials - Syntax errors in pipeline-as-code stop execution completely - Ownership of your repo is critical for real debugging and iteration - Authentication and credentials are a core part of automation — not an afterthought ☁️ AWS Perspective These same failure patterns exist in cloud-native CI/CD systems: - CodePipeline failures due to misconfigured buildspec files - IAM permission issues blocking deployment stages - ECR authentication failures during image push - Infrastructure-as-Code syntax errors in CloudFormation or Terraform 👉 The lesson: automation is only as reliable as its configuration and permissions layer. 📌 Why This Week Matters This is where DevOps becomes real: Code → Build → Package → Containerize → Authenticate → Automate I’m no longer just learning tools — I’m learning how to debug and own the entire delivery pipeline. 💬 Question for DevOps Engineers When debugging Jenkins pipelines, how do you differentiate quickly between: 👉 syntax issues in Jenkinsfile 👉 vs runtime/build failures deeper in the pipeline What’s your first check? #DevOps #Jenkins #CICD #Docker #AWS #CloudEngineering #Automation #LearningInPublic

🚀 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

30 Days DevOps Revision Challenge – Day 2 Day 2 of my DevOps revision challenge — and today was all about going deeper into Jenkins and organizing everything I’ve learned so far. Yesterday was more about getting started and building a real pipeline. But today, I focused on strengthening almost all important Jenkins concepts in a more structured and practical way. 📌 Day 2 Focus: Advanced Jenkins Concepts Today I worked on multiple key areas to understand how Jenkins is actually used in real-world environments: 🔐 User-Based Authentication Explored how to manage users and roles Understood access control and security basics in Jenkins 📦 Shared Library (Deep Dive) Practiced creating and structuring shared libraries Improved reusability and organization of pipeline code 🔑 Credentials Management Learned how to securely store and use credentials Integrated credentials into pipelines safely 🔄 Build via SCM (GitHub Integration) Created jobs directly connected to GitHub repositories Automated build process using source code changes ⚡ Trigger Builds Without Opening Jenkins UI Configured builds to trigger directly from GitHub Used webhooks effectively for automation 🧑💻 Agent Setup Created and configured Jenkins agents Understood distributed builds and scalability 🔗 Webhook Optimization Used webhooks more efficiently Ensured proper trigger flow and debugging 💡 Key Takeaway Today felt like I connected all the scattered pieces of Jenkins into a complete system. From authentication → credentials → pipelines → agents → automation Everything now feels more organized and production-oriented. 🎯 Progress So Far Day 1: Pipeline + Django App + Shared Library basics Day 2: Advanced Jenkins concepts + full ecosystem understanding Slowly moving from just knowing tools → to actually understanding how everything fits together in production. I’ll continue sharing my journey daily. Consistency is the main goal 💯 If you’re also learning DevOps, let’s connect and grow together #DevOps #30DaysChallenge #Jenkins #CICD #Automation #Webhooks #LearningInPublic #Consistency #TechJourney

🚀 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 13–15: Mastering Git & GitHub | DevOps Journey A little late in posting, but staying consistent with my learning journey 💪 Over the past few days, I focused on strengthening my understanding of Git & GitHub, which are essential tools for every developer and DevOps engineer. 🔹 What I Learned: Git fundamentals: version control, repositories, commits Complete workflow: working directory → staging → commit → push/pull Branching & merging for collaborative development Handling merge conflicts effectively Difference between git reset and git revert Importance of git reflog for recovering lost commits 🔹 Hands-on Practice: Initialized and cloned repositories Worked with branches for feature development Managed code changes using commits and pushes Simulated real-world workflows used in teams 🔹 Key Takeaways: Git is not just a tool, it’s a core skill for collaboration Writing meaningful commit messages improves project clarity Using branches ensures safe and scalable development Recovery tools like reflog are lifesavers in real projects 💡 This phase has helped me move closer to industry-level development and DevOps practices. 📌 Next Goal: Integrating Git with CI/CD pipelines and real-world projects #Git #GitHub #DevOps #LearningJourney #SoftwareDevelopment #Cloud #Engineering

🔥 Day 4 of My DevOps Journey Today, I learned one of the most powerful concepts in Git — Branching 🌿 At first, I used to think everyone works on the same code… but that would create chaos 😅 💡 What I learned: Branching allows developers to work on new features without affecting the main code. 🛠️ Commands I practiced: ✔️ "git branch" → Create branch ✔️ "git checkout" → Switch branch ✔️ "git checkout -b" → Create + switch ✔️ "git merge" → Merge changes 🚀 Real-world understanding: Teams use branches to safely develop features and then merge them after testing. This made me realize how structured and efficient DevOps workflows actually are 💻 Learning something new every day 💪 #DevOps #Git #GitBranching #LearningJourney #Consistency #AWS

Understanding Workflow as a DevOps Engineer 🚀 Here’s how I manage code efficiently using Git 👇 🔹 Basic Workflow: git clone → Copy repo to local git checkout -b feature-branch → Create new branch git add . → Stage changes git commit -m "message" → Save changes git push origin branch → Push to GitHub Create Pull Request (PR) Code review → Merge to main 🔹 Why this matters: ✅ Avoids code conflicts ✅ Enables team collaboration ✅ Keeps production stable ✅ Supports CI/CD pipelines 🔹 What I learned: Using proper branching strategy makes deployments safer and faster. Next step: Automating this workflow using Jenkins CI/CD 🚀 If you're learning DevOps, mastering Git is a must. #Git #GitHub #DevOps #CICD #LearningInPublic #AWS

🚀 DevOps Journey – Day 19 / 100 Today I learned Git Tags, Fork, Merge Conflicts & Bitbucket 🔥 ⸻ 🔹 🏷️ Git Tags (Versioning) 👉 Tags are like milestones / backups in Git 📌 Example: Version1 → 3 commits Version2 → 2 more commits Version3 → 2 more commits 👉 We can mark versions like: • app-v1 • app-v2 • app-v3 ⸻ 🔹 🧪 Hands-on Example mkdir project cd project git init touch file1 file2 file3 git add file1 git commit -m "file1 commit" git add file2 git commit -m "file2 commit" git add file3 git commit -m "file3 commit" 👉 Apply tags: git tag app-v1 git tag git log 👉 Push tag to GitHub: git push origin app-v1 git push origin --tags 🔹 🍴 Git Fork 👉 Fork = Copy of someone else’s repo into your GitHub 📌 Steps: 1. Click Fork in GitHub 2. Repo copied to your account 3. Clone → Make changes → Push 💡 Used in open source contributions ⸻ 🔹 ⚠️ Merge Conflicts (Real-Time) 👉 When 2 people change same file/line → Conflict 🎬 Example: Tillu & Shanon both ask Radhika for movie at 1:30 PM 😅 👉 Same time → Conflict 💡 Solution: • Manually edit file • Remove conflict markers • Commit resolved code ⸻ 🔹 🔁 Git Alternatives • Bitbucket • Azure Repos • AWS CodeCommit ⸻ 🔹 🔵 Bitbucket Basics 👉 Same as GitHub (Repo hosting) 📌 Workflow: • Create repo • Clone repo • Create branch • Commit changes • Push & Pull ⸻ 🔹 🔐 Bitbucket Token (App Password) 📌 Steps: • Go to Settings → Access Management • Create App Password / API Token • Set permissions (read/write) • Use instead of password ⸻ 💡 Pro Tip: Use tags for releases, forks for contributions, and always resolve conflicts carefully! You’re now thinking like a real DevOps Engineer 🚀 #DevOps #Git #GitHub #Bitbucket #VersionControl #100DaysOfDevOps #LearningJourney #Cloud #Automation #RealTime #flm #frontlinemedia #reach #edutech Frontlines EduTech (FLM)

🚀 DevOps Day 21 — Git Branching & DevOps Workflow (Part 3) After fixing networking issues, I moved into real Git workflows. This is where Git becomes powerful. SSH vs HTTPS Git Connections I explored both methods: SSH Method git@github.com:nixhal33/DevOps-Mastery.git Advantages: ✔ No repeated authentication ✔ Secure ✔ DevOps-friendly HTTPS Method (Token Based) git clone https://@github.com/repo.git Steps: • Create Classic Token • Clone repo • Push changes But SSH felt more DevOps-aligned. Git Commands I Practiced ✔ git status ✔ git diff ✔ git add ✔ git commit ✔ git push ✔ git restore ✔ git revert HEAD These commands helped me: • Track changes • Revert mistakes • Monitor code differences Git Branching (Most Important Learning) Production branch: main Development branch: git checkout -b dev Workflow: Create dev branch Make changes Push to dev Merge to main Merge Conflict Practice I intentionally: • Edited files in two branches • Created merge conflict • Resolved manually • Merged successfully This was real-world Git learning. Final DevOps Insight My instructor shared something interesting: DevOps Engineers don't use Git as heavily as developers… But Git is critical for: ✔ CI/CD pipelines ✔ Automation workflows ✔ Infrastructure versioning And now I'm ready for: 🚀 Next Topic: Docker From IaC → Version Control → Containers The DevOps journey continues.  you can checkout my github repo using this link: https://lnkd.in/gjw9Fuxe #DevOps #Git #GitHub #Automation #CI_CD #InfrastructureAsCode #DockerJourney #LearningInPublic