Dinesh Sudha’s Post

Git in Real Life: When I started using Git, I thought it’s just for pushing code. But in real production environments, Git becomes the single source of truth. Let me share a real-world scenario Scenario: Production Issue One day, a critical service started failing after deployment. Everything looked fine in CI/CD, but users were facing errors. First step? Not logs… Git history. Using: git log --oneline We traced a recent commit where a config file was modified. Use Case: Root Cause Analysis We compared changes using: git diff <commit-id> Found that: - Environment variable was changed - API endpoint misconfigured A small change, but huge impact. Fix Strategy Instead of manually fixing, we rolled back safely: git revert <commit-id> git push origin main Production stabilized within minutes Daily Use Cases of Git in DevOps - Managing infrastructure code (Terraform, Kubernetes YAMLs) - Version controlling CI/CD pipelines - Tracking configuration changes - Enabling team collaboration - Supporting GitOps workflows Must-Know Commands (Real Usage) git clone <repo> git checkout -b feature-branch git add . git commit -m "feature update" git push origin feature-branch git pull origin main git merge main Troubleshooting Scenarios 1. Merge Conflict git pull origin main Fix conflicts manually → then: git add . git commit -m "resolved conflict" 2. Wrong Commit Made git reset --soft HEAD~1 3. Lost Changes git stash git stash apply 4. Check Who Changed What git blame <file> Key Learning Git is not just a tool. It’s your safety net, audit system, and collaboration engine. In production, debugging often starts from Git, not from code. Final Thought A single commit can: - Break production - Or save hours of debugging So always: Commit smart. Review carefully. Deploy confidently. #Git #DevOps #Troubleshooting #VersionControl #Cloud #Git Lab #MLOPS #devsecops

You're still pushing deployments manually. ArgoCD watches your Git repo and does it for you. This is GitOps. And it changes everything. The old way — Push-based CI/CD Jenkins builds your code ✅ Jenkins pushes to Kubernetes ✅ Jenkins needs cluster credentials stored somewhere 😬 Pipeline fails halfway — cluster is in unknown state 💀 Nobody knows what's actually running in prod 🤷 The ArgoCD way — Pull-based GitOps Your Git repo IS the truth. ArgoCD watches your repo 24/7. Repo changes → ArgoCD pulls → deploys automatically. Cluster drifts from Git? ArgoCD self-heals it back. What's in Git = What's in prod. Always. No exceptions. The mental model that sticks: 🏠 Git repo = The architect's blueprint 👷 ArgoCD = The builder who checks the blueprint every 3 minutes 🏗️ Kubernetes = The building If someone adds an unauthorized wall — ArgoCD tears it down and rebuilds from the blueprint. The 3 things ArgoCD gives you: 1. Sync — Desired state (Git) matches Live state (K8s). Always. 2. Self-heal — Someone kubectl applys something manually? ArgoCD reverts it. Git wins. 3. Multi-cluster — One ArgoCD. Manages dev, staging, prod clusters from one dashboard. Real talk for mid-level engineers: Your CI pipeline's job is to build and test. ArgoCD's job is to deploy and maintain. Separation of concerns. Each tool does one thing perfectly.

Why Plain Text + Git just works For a long time, documentation lived next to development. Different tools. Different workflows. Often, different levels of quality. But more teams are moving toward something simpler, and more powerful: plain text documentation, versioned in Git. Why? Because documentation starts behaving like code: - Versioned - Reviewable - Collaborative - Traceable Instead of static pages, you get a living system that evolves with your product. No proprietary lock-in. No disconnected workflows. Just documentation that stays relevant. Is your documentation versioned, or just stored? #Documentation #Git #DevOps #Elevatic

🚀 Day 39 – Git Merge Conflicts & Resolution ⚠️🔧 Today I learned about merge conflicts in Git and how to resolve them — an important skill when working in team projects 💻 ⚠️ What is a Merge Conflict? A merge conflict occurs when two changes are made to the same file or line of code in different branches, and Git is unable to automatically merge them. 🔍 When Do Conflicts Happen? Two developers edit the same file Same line is modified in different branches Changes overlap ⚙️ How to Identify Conflict When merging, Git shows: <<<<<<< HEAD Your changes ======= Other branch changes >>>>>>> feature 🛠️ Steps to Resolve Conflict 1️⃣ Open the conflicted file 2️⃣ Identify the conflicting code 3️⃣ Edit and keep the correct version 4️⃣ Remove conflict markers 5️⃣ Add and commit 👉 Commands: git add . git commit -m "resolved conflict" 💡 Best Practices ✔ Pull latest code before starting work ✔ Use small commits ✔ Communicate with team ✔ Avoid editing same file simultaneously 📌 My Learning Today Understanding merge conflicts helped me realize how important collaboration and proper version control are in real-world projects. Resolving conflicts is a key DevOps skill 💪 #Git #MergeConflict #DevOps #VersionControl #CloudComputing #LearningJourney #TechSkills #WomenInTech #CloudEngineer

Git Series | Day 9: Optimization & Deployment — Squash, Cherry-Pick, and .gitignore 🚀 As I near the end of this series, I am focusing on the "polishing" tools that professional DevOps Engineers use to ensure their repositories are clean, secure, and ready for production. 1. Squash: Consolidating the Journey Why show 10 "work-in-progress" commits when one clean commit will do? Squash allows me to combine multiple commits into a single, meaningful entry. The Command: git rebase -i HEAD~number The Workflow: In the interactive editor, I keep the first commit as "pick" and change the others to "squash." The Benefit: It keeps the master branch history concise and high-level for senior reviewers. 2. Cherry-Pick: Surgical Precision Sometimes you don't want an entire branch; you just want one specific fix or feature. The Concept: Picking a single commit from one branch and applying it to another. The Command: git cherry-pick <commit-id> The Use Case: Great for pulling a critical hotfix from a development branch directly into production without bringing unfinished features along. 3. .gitignore: The Silent Guardian A professional repository should never contain logs, environment variables, or temporary build files. The Mechanism: By creating a .gitignore file, I tell Git which files to permanently ignore from tracking. Standard Exclusions: I typically exclude *.log, .env (security), and folders like /db or node_modules. The Result: Smaller repository size and zero risk of pushing sensitive credentials to GitHub. 4. Deployment: Hosting via GitHub Pages Git isn't just for tracking; it’s for delivering. I practiced hosting static web applications directly from a repository. Push your code to a new GitHub repository. Navigate to Settings > Pages. Select the master branch and save. Your application is live and accessible via a public URL! My use of .gitignore ensures that sensitive configuration data and "garbage" files never enter the version control system. I Streamline Code Reviews: By squashing messy development commits before merging. #Git #DevOps #100DaysOfCode #WebDeployment #GithubPages #CleanCode #SoftwareEngineering #SysAdmin #GitIgnore

Git isn't just a version control tool — it's the starting point of your entire delivery pipeline. Every CI/CD pipeline, every deployment, every infrastructure change begins with a Git event. A push, a merge, a pull request. Here are the Git commands that actually matter in DevOps: The daily basics: → git clone — copy a repo to your local machine → git pull — get the latest changes from remote → git add . — stage all changes → git commit -m " " — save your changes with a message → git push — send your changes to remote Branching: → git branch — list all local branches → git checkout -b name — create and switch to a new branch → git merge branch-name — merge changes from one branch into another Debugging and recovery: → git log --oneline — see commit history in a clean format → git diff — see exactly what changed between states. → git revert <commit> — undo a commit safely without rewriting history → git stash — temporarily save changes you're not ready to commit Status: → git status — Run git status constantly. It tells you exactly where you are, what's staged, what's not, and what branch you're on. It saves so much confusion. Understanding Git properly means understanding how the entire delivery process begins. What Git command do you wish you had learned earlier? 👇 #DevOps #Git #VersionControl #CICD #LearningDevOps #BeginnerDevOps #TechCareers #LearningInPublic

📝 Day 6 Sharing my DevOps Series..... *git config is used to set and manage Git settings like your username, email, editor, and more. git config --global user.name "Your Name" git config --global user.email "your@email.com" *View commit history git log git log --oneline *Git Branch git branch git branch feature git checkout feature Branch = separate workspace *Git Merge - Combine changes git merge feature Merges feature branch into main Watch for conflicts *Git Clone Copy a repository git clone <repo-url> Downloads project to your system *Git Pull vs Fetch git fetch git pull Fetch = download changes Pull = fetch + merge *Git Push Upload your code git push origin main Sends commits to remote repo *Git Tag Mark important versions git tag v1.0 git push origin v1.0 Useful for releases *Git Stash Save work temporarily git stash git stash pop Useful when switching tasks *Git Rebase vs Merge Two ways to integrate code Merge → keeps history Rebase → cleaner history git rebase main *Git Fork (GitHub Workflow) Post: Contribute to open source Fork → copy repo Clone → local copy Push → your repo PR → contribute git cherry-pick git cherry-pick is used to pick a specific commit from one branch and apply it to another branch. git cherry-pick <commit-id> #GitHub #OpenSource #DevOps #git #cloud #repository.....

Git Branching Strategies — What actually matters in real projects When I first started using Git, I thought it was simple: create a branch, push code, and the job is done. But working on real projects changed that perspective. The wrong branching strategy does not just create small issues. It leads to confusion, messy workflows, and problems that become harder to fix over time. Here is a simple understanding of the most commonly used strategies: Feature Branching : Each feature is developed in its own branch and merged back once complete. This keeps work isolated and makes code reviews easier. It is one of the most practical approaches for most teams. Gitflow : A more structured model with dedicated branches such as main, develop, feature, release, and hotfix. It works well for teams that follow strict release cycles and need better version control. GitHub Flow A simpler approach where the main branch is always production-ready. Changes are made in short-lived branches and merged quickly. Ideal for teams practicing continuous deployment. GitLab Flow : Combines feature branching with environment-based workflows like staging and production. It integrates well with CI/CD pipelines and supports continuous delivery. Trunk-Based Development : Developers merge small changes frequently into the main branch. This requires strong discipline and testing practices but enables faster feedback and delivery. One important thing I learned is that there is no single “best” strategy. The right choice depends on your team size, project complexity, release frequency, and deployment process. A common mistake I have seen is teams adopting complex strategies like Gitflow without actually needing that level of structure. For me, feature branching felt like the most natural starting point. It is simple, clear, and effective. What has worked best for your team? #DevOps #Git #GitHub #CICD #VersionControl #SoftwareEngineering #Automation

𝗚𝗶𝘁 - 𝗧𝗵𝗲 𝗱𝗮𝗶𝗹𝘆 𝗧𝗶𝗽 As we all know git is one the most powerful tool we have, here are some tips to "optimize" your daily work 𝙗𝙧𝙖𝙣𝙘𝙝.𝙨𝙤𝙧𝙩 -𝙘𝙤𝙢𝙢𝙞𝙩𝙩𝙚𝙧𝙙𝙖𝙩𝙚 What 𝚋𝚛𝚊𝚗𝚌𝚑.𝚜𝚘𝚛𝚝 -𝚌𝚘𝚖𝚖𝚒𝚝𝚝𝚎𝚛𝚍𝚊𝚝𝚎 Does When you set this configuration, any command that lists branches (like 𝚐𝚒𝚝 𝚋𝚛𝚊𝚗𝚌𝚑) will sort them based on the 𝗱𝗮𝘁𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗹𝗮𝘀𝘁 𝗰𝗼𝗺𝗺𝗶𝘁 made to that branch. 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 𝗯𝗲𝗵𝗮𝘃𝗶𝗼𝗿: • Branches are listed A-Z. 𝗪𝗶𝘁𝗵 𝘁𝗵𝗶𝘀 𝘀𝗲𝘁𝘁𝗶𝗻𝗴: • The branches with the most recent activity appear at the bottom of the list (closest to your prompt), making them much easier to find in a repository with dozens of stale branches. 𝗣𝗿𝗼-𝗧𝗶𝗽: Adding More Detail • If you want an even more powerful view of your recent work, you can create a "𝘀𝘂𝗽𝗲𝗿 𝗮𝗹𝗶𝗮𝘀" that shows the date and the last commit message:    • Set alias 𝙜𝙞𝙩 𝙘𝙤𝙣𝙛𝙞𝙜 --𝙜𝙡𝙤𝙗𝙖𝙡 𝙖𝙡𝙞𝙖𝙨.𝙧𝙡 "𝙗𝙧𝙖𝙣𝙘𝙝 --𝙨𝙤𝙧𝙩=-𝙘𝙤𝙢𝙢𝙞𝙩𝙩𝙚𝙧𝙙𝙖𝙩𝙚 --𝙛𝙤𝙧𝙢𝙖𝙩='%(𝙖𝙪𝙩𝙝𝙤𝙧𝙙𝙖𝙩𝙚:𝙧𝙚𝙡𝙖𝙩𝙞𝙫𝙚)%𝟬𝟵%(𝙧𝙚𝙛𝙣𝙖𝙢𝙚:𝙨𝙝𝙤𝙧𝙩)%𝟬𝟵%(𝙨𝙪𝙗𝙟𝙚𝙘𝙩)'" You just created a powerful new Git alias named 𝚛𝚕 (Recent List). 𝗨𝘀𝗮𝗴𝗲: 𝗴𝗶𝘁 𝗿𝗹 Enjoy.... #GIt #DevOps

This is a very useful tip. Especially when working in a team with many branches and many commits. You can set it up to immediately see what branch was most recently used, when was the most recent commit, what was it, and maybe even add the person who committed.