Git for Code and Configuration Management

Week 4 Update. This week I started learning Git and Github. Here's what I've learnt so far. 1. Git is the time machine for your code. Every commit is a snapshot. Every branch is a timeline. You’re not just saving files, you’re building a complete history of decisions. Git used for: -Tracking code changes -Tracking who made changes -Coding collaboration In DevOps, this history is how you debug production incidents, audit changes, and roll back disasters. 2. The 3 areas in Git (Local Machine): Working Directory → where you edit files   ↓ git add Staging Area → where you prepare commits   ↓ git commit Repository → permanent history You can edit 10 files but only commit 3. That’s the power of the staging area. 3. Local vs Remote Git (what push and pull actually mean): Your local repository is your personal timeline. The remote (GitHub) is the shared source of truth. git push = publish your history   git pull = sync with shared history   git clone = copy an existing timeline to your machine  Once I understood this, Git started feeling predictable. 4. Branches are not copies. They’re pointers. When you create a branch, Git doesn’t duplicate files. It creates a new pointer to a commit. This is why: -Branching is instant -Switching branches is fast -Merging is possible Merging isn’t “combining folders”, it’s reconciling histories. 5. .gitignore is a security and sanity tool. Not everything belongs in Git. Secrets, logs, build artifacts, and environment files should never be committed. .gitignore is how you prevent leaking credentials(API keys). Which is especially important in DevOps and cloud work. 6. SSH (Secure Shell) is a way to connect securely to remote computers and services, like Git repositories. Using SSH keys instead of passwords isn’t just convenience. It’s identity. SSH keys come in pairs: -Public Key: Shared with external servers (like GitHub) to identify you. -Private Key: Stored secretly on your local machine to authenticate you. This is the same trust model used in production servers and cloud environments. I've realized that Git isn’t just a developer tool. Infrastructure as Code, CI/CD pipelines, and deployments all start with Git. Still learning📌, it's all coming together. Linux - Networking - Git #DevOps #Git #CloudSecurity #DevSecOps

This is post 2 of 3 🚨 We Rewrote Git History to Remove a Secret. Here’s What Broke. A Gmail password was accidentally committed in a `.env` file. First step?   👉 We rotated the password immediately. Because here’s the truth: If the primary secret is not actively being exploited,   rotating it is often enough. Rewriting Git history should NOT be your first reaction. 💥 When We Decided to Rewrite History We used `git filter-repo` and force pushed. That fixed the repository history. But here’s what changed 👇 `A → B → C → D → E` became `A → B → C' → D' → E'` Every commit after the change got a new hash. ❌ What Broke? • Team couldn’t pull → everyone re-cloned   • CI/CD pipelines referencing old SHA failed   • Open PRs needed rebase/recreation   • Commit references in Jira became invalid ✅ So What’s the Right Approach? If a secret is committed: 1️⃣ Rotate it immediately   2️⃣ Assess impact   3️⃣ Rewrite history only if risk remains Because rewriting Git history is powerful —   but it affects your entire team. 💡 Lesson for SDETs & DevOps Engineers Security is priority. But controlled impact is also engineering maturity. Sometimes rotating the secret is enough.   Sometimes rewriting history is necessary. Knowing the difference is real experience. #SDET #AutomationTesting #Playwright #APITesting #DevOps #Git #CI_CD #SecureCoding #QualityEngineering

90% of DevOps Engineers fail the "Git Internals" round. Here is why. I used to struggle with Rebasing vs Merging too. So I consolidated my notes into a 50-Question Deep-Dive Guide. Most candidates know git commit and git push. But when asked about "Detached HEADs", "Refspecs", or "Bisecting", they freeze. This PDF bridges the gap between a Junior Developer and a Senior Architect. What’s inside this 18-slide Deep Dive? ✅ Rebasing Strategies: Interactive rebase, squashing, and the Golden Rule. ✅ Undo Mechanics: Hard vs Soft Reset, Revert, and Reflog recovery. ✅ Debugging: Using git bisect to find bugs in O(log n) time. ✅ Internals: The Object Model (Blobs, Trees) and Packfiles. ✅ Workflows: Gitflow, Trunk-Based, and Submodules. No fluff. Just the exact answers you need to clear the round. 💡 Pro Tip: The reflog is your safety net. It tracks everything, even the commits you "deleted." Download the PDF 📄 | Repost ♻️ if this saves you time. #DevOps #Git #CloudComputing #SoftwareEngineering #TechInterview #Linux #MouliS #Programming #Automation #VersionControl

🚀 Day 6 – Git & GitHub Series | Reverting & Resetting (Undo Like a Pro) Let’s be honest… Every developer has done this at least once: 👉 committed wrong code 👉 deleted a file by mistake 👉 pushed something broken 👉 or thought “How do I go back now?!” 😅 That’s where Git recovery commands save your life. Because in real projects, it’s not about never making mistakes — it’s about fixing them safely and fast. 🔹 Must-know Undo Commands ✅ Move HEAD but keep changes git reset --soft <commit_id> ✅ Unstage changes git reset --mixed <commit_id> ✅ Reset everything (⚠ dangerous) git reset --hard <commit_id> ✅ Safely undo via new commit (team-friendly) git revert <commit_id> ✅ Restore files git restore <file> ✅ Remove from staging git restore --staged <file> ✅ Clean unwanted files git clean -f git clean -fd 💡 Real-world rule I follow ✔ Working alone → reset ✔ Working in team/shared repo → revert ✔ Avoid --hard unless 100% sure ✔ Always double-check before cleaning Small knowledge → Huge time saved during production issues. 📌 This is Day 6 of my Git Mastery Series Daily practical Git + GitHub tips for Developers, DevOps & SREs. If you’re serious about leveling up your engineering skills: 👉 Follow for the next post #Git #GitHub #DevOps #SRE #VersionControl #SoftwareEngineering #Developers #ProgrammingLife #TechLearning #CloudComputing #Debugging #OpenSource #CareerGrowth #LearnInPublic

Excited to share the next post in my Git series: "Git: The Hard Parts Explained". Covered the basics and internals before—added a few more useful ones here: Squashing commits Reset vs Revert Reflog recovery Stash for context-switching Rebase vs Merge Pull strategies Read it here: https://lnkd.in/gcsrZCeZ Feedback and suggestions welcome as always! #Git #VersionControl #TechBlog #GitInternals

Stop wasting CI minutes on the wrong branches. ⚙️ GitHub Actions lets you control exactly which branches run which jobs — and this article walks through the practical YAML patterns to do it right. It covers branch filters, wildcards, ignores, manual triggers, job dependencies, and environment-aware deployments. Key takeaways: - ✅ Use on: branches to limit triggers to main/dev or named branches - 🔁 Use wildcards (* and **) to match feature/* or releases/** - 🚫 Use branches-ignore to exclude temp or experimental branches - 🧪 Use needs + if to run deploy only after tests and only on refs/heads/main - 👇 Use workflow_dispatch for manual environment deployments Read for ready-to-copy YAML examples and patterns that keep tests everywhere and deployments only where they belong. https://lnkd.in/eyteNsfs #GitHubActions #CI/CD #DevOps #GitHub #Automation

🚀 Day 11 of Git & GitHub Mastery – Submodules (Manage External Repos Like a Pro) As projects grow… one repository is rarely enough. Shared libraries. Common utilities. Reusable services. Copy-pasting code? ❌ Professional teams use Git Submodules ✅ Submodules let you embed and manage external repositories inside your main project — cleanly, versioned, and controlled. Today’s essentials: ✅ git submodule add → Add external repo ✅ git submodule init → Initialize after clone ✅ git submodule update → Sync to correct commit ✅ git submodule status → Track versions ✅ git submodule update --remote → Pull latest ✅ git submodule foreach → Run commands across all 💡 Why this matters: • Better code reuse • Separate version control • Cleaner architecture • Production-grade dependency management This is how real enterprise projects manage shared components. If you’re aiming for Senior Dev / DevOps / Platform Engineer roles, Submodules are a skill you shouldn’t skip. 📌 Save this post 📌 Try adding one submodule today 📌 Follow the series for Day 12 Level up your Git. Level up your career 🚀 #Git #GitHub #DevOps #SoftwareEngineering #BackendDevelopment #DeveloperTools #CodingLife #TechSkills #OpenSource #VersionControl #SystemDesign #EngineeringLife #LearnInPublic #BuildInPublic #100DaysOfCode

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

🚀 Jenkins Master-Slave (Node) Configuration – Learnings & Key Takeaways Over the past few days, I had an excellent hands-on learning experience exploring Jenkins Master-Slave (Node) architecture and several advanced CI/CD concepts. Here are some of the major highlights from the session: 🔧 1. Jenkins Master–Slave (Node) Setup Configured multiple Jenkins nodes (e.g., Dev Node, Performance Node) to efficiently distribute workloads across teams. This helped ensure that activities from one team do not interfere with another — improving overall pipeline stability and performance. 🔌 2. Jenkins Plugins – Essential Tools Explored and worked with important Jenkins plugins such as: Docker Kubernetes Maven Git / GitHub Ansible Terraform Blue Ocean RBAC The instructor emphasized the importance of knowing at least 10 key plugins for interviews and practical usage. 🖥️ 3. Jenkins UI & Administration Deep dive into the Manage Jenkins section, including: System configurations Tool integrations Plugin installation & upgrades Node management Security settings User creation & access control 🎯 4. Restricting Jobs to Specific Nodes Learned how to: Use “Restrict where this project can run” in freestyle jobs Apply agent labels in pipeline projects This ensures jobs run only on designated nodes (e.g., heavy builds on a performance node). 🛠️ 5. Troubleshooting & Real-World Scenarios Covered practical scenarios like: Node connectivity issues Jobs stuck in the queue Auto-recovery when nodes come back online Handling job failures across distributed nodes 🛡️ 6. Jenkins Maintenance & Security Discussed: Java version compatibility Plugin updates Vulnerability fixes Jenkins LTS upgrades 🎨 7. Blue Ocean Plugin Explored Blue Ocean for a more modern, visual, and intuitive pipeline interface, making debugging and visualization easier. 🔐 8. Role-Based Access Control (RBAC) Got an introduction to the RBAC plugin for defining granular user roles, permissions, and secure access control within Jenkins. Overall, this session boosted my understanding of Jenkins infrastructure management, pipeline optimization, security practices, and advanced plugin usage — essential skills for modern DevOps environments. If you're working with CI/CD or planning to dive deeper into DevOps, I highly recommend exploring these Jenkins capabilities! #AWS hashtag #EC2 hashtag #CloudComputing hashtag #DevOps hashtag #LoadBalancing hashtag #NGINX hashtag #Apache hashtag #LearningInPublic hashtag #CloudEngineering hashtag #TechSkills hashtag #Bootcamp hashtag #HandsOnLearning hashtag #Linux hashtag #SystemAdministration hashtag #TechSkillsv hashtag #CloudDevOpsHu hashtag #VikasRatnawat hashtag #LearningJourney

Have you ever wondered how Git actually works under the hood? What really happens when you run `git init`? 🤔 I built a Git clone in Go from scratch to understand how Git actually works. Trunk is a functional Git core written in Go that directly reads and writes the .git directory instead of shelling out to Git. While building it, I dug into Git’s internals and learned how its object model, refs, and plumbing commands really operate under the hood. Here's what I discovered: Key Learnings: 1️⃣ Git is a Content-Addressable Storage System Git isn't a "diff engine" - it's essentially a key-value database where every piece of content gets a unique SHA-1 hash as its key. 2️⃣ Commits are Full Snapshots, Not Diffs Contrary to popular belief, each commit stores the ENTIRE state of your project. Git optimizes this through compression and deduplication - identical files across commits share the same storage. 3️⃣ The Merkle Tree Architecture Git uses a Merkle tree structure where: - Blobs store file content (no filenames!) - Trees represent directories (mapping names to hashes) - Commits link trees with metadata - Any change propagates up: file → tree → root tree → commit 4️⃣ Clever Object Storage Objects are stored in `.git/objects/` using a smart scheme: - First 2 characters of the hash = directory name - Remaining 38 characters = filename - All compressed with zlib 5️⃣ Branches Are Just Pointers A branch is simply a lightweight pointer to a commit hash. That's why creating branches is so cheap! 💻 The Implementation: I built both plumbing (low-level) and porcelain (high-level) commands: - Plumbing: hash-object, cat-file, update-index, write-tree, commit-tree - Porcelain: commit, log The project is compatible with standard Git repositories, reinforcing the idea that Git is fundamentally clever file organization plus cryptographic hashing. Check out the full implementation on GitHub: https://lnkd.in/g6AG2js5 #Git #SoftwareEngineering #OpenSource #VersionControl #Golang #DevOps #Programming #TechEducation #ComputerScience