Dinesh Sudha’s Post

𝗜 𝘁𝗵𝗼𝘂𝗴𝗵𝘁 𝗜 𝗸𝗻𝗲𝘄 𝗚𝗶𝘁... 𝘂𝗻𝘁𝗶𝗹 𝗜 𝗵𝗮𝗱 𝘁𝗼 𝗱𝗼 𝘁𝗵𝗶𝘀. Recently I ran into a pretty unusual scenario:  • move an entire sprint between different repositories  • keep the commit history intact  • adapt commit message conventions along the way But there was a real constraint: 𝘁𝗵𝗲 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗵𝗮𝗱 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 (𝘀𝗲𝗿𝘃𝗲𝗿 𝗰𝗼𝗻𝗳𝗶𝗴𝘀, 𝗗𝗼𝗰𝗸𝗲𝗿, 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀...) So copying code wasn’t an option. That’s when I used a lesser-known approach: 𝗽𝗮𝘁𝗰𝗵𝗲𝘀 + 𝘄𝗼𝗿𝗸𝘁𝗿𝗲𝗲𝘀 𝘁𝗼 𝗺𝗼𝘃𝗲 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗮𝗰𝗿𝗼𝘀𝘀 𝗰𝗼𝗻𝘁𝗲𝘅𝘁𝘀 The flow looked like this: 1. Develop normally in a worktree 2. Export commits using `git format-patch` 3. Adjust the patches 4. 𝗥𝗲𝗺𝗼𝘃𝗲 𝗰𝗼𝗺𝗺𝗶𝘁𝘀 𝘁𝗵𝗮𝘁 𝗱𝗶𝗱𝗻’𝘁 𝗯𝗲𝗹𝗼𝗻𝗴 𝗶𝗻 𝘁𝗵𝗲 𝘁𝗮𝗿𝗴𝗲𝘁 (𝗲.𝗴. 𝗶𝗻𝗳𝗿𝗮 𝗰𝗼𝗻𝗳𝗶𝗴𝘀) 5. Prepare the correct base on the destination 6. Reapply everything with `git am --3way` Sounds simple… but then reality hit: - commit conventions were different between the projects So I did what any dev would do… 𝗜 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝗱 𝗶𝘁 I built a shell script that:  • reads a YAML mapping file (from → to)  • renames patches automatically  • asks for input when no mapping is found  • allows 𝘀𝗸𝗶𝗽 or even 𝗮𝗯𝗼𝗿𝘁 𝗮𝗹𝗹 mid-process Result: - repeatable process - fewer manual errors - full control over history And that’s when it clicked: Git is not just version control it’s a tool for 𝘁𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗶𝗻𝗴 𝗮𝗻𝗱 𝘁𝗿𝗮𝗻𝘀𝗽𝗼𝗿𝘁𝗶𝗻𝗴 𝗵𝗶𝘀𝘁𝗼𝗿𝘆 You don’t need to copy code. You can 𝗿𝗲𝗯𝘂𝗶𝗹𝗱 𝘁𝗵𝗲 𝘀𝘁𝗼𝗿𝘆 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝘄𝗮𝘆 𝗼𝗻 𝘁𝗵𝗲 𝗼𝘁𝗵𝗲𝗿 𝘀𝗶𝗱𝗲. And that opens up a whole new set of possibilities. Curious: - have you ever automated a “weird” Git workflow like this? #git #softwareengineering #backend #devlife #programming #developer #tech #coding #automation #devops #softwaredevelopment #engineering

Git by itself will happily let you commit: ▪️ Ugly formatting ▪️ Failing code ▪️ Secrets ▪️ Broken configs It doesn't assess quality; it just stores snapshots, which is why automation is vital within teams to catch problems early. There are 3 Key Layers: 1️⃣ .gitignore Your first line of defence, it prevents you from tracking sensitive information by telling Git what not to track: ▪️.env files (secrets) ▪️Dependencies ▪️Logs ▪️System Files If set up properly, a lot of problems can be prevented. 2️⃣ Pre-commit hooks A hook is a script that git will run automatically at select points in the git workflow. One of the points is before a commit is created... If it passes these checks, the commit will go through If it fails, the commit will be blocked These checks include: ▪️Linters (code quality) ▪️Tests (does it still work?) ▪️Secret scanning This layer stops bad code before it enters your repo history. But its not perfect and must not be solely relied on. 3️⃣ CI - Continuous Integration This set of checks runs after you push your code CI will: ▪️Run tests ▪️Check formatting ▪️Scan for secrets ▪️Build the project If something fails, your PR will be blocked. The issue here is that it runs after the commit already exists, so the secret is already in history, but the PR won't be merged; warnings will show, and the team will be notified. All 3 are needed to ensure that rules are consistent, checks are automatic, and fewer mistakes reach PRs or the main. If all is well, then the PR will be approved. A Pull Request isn't just a click merge button... It acts as a checkpoint: ▪️Reviews the code ▪️Catches mistakes ▪️Enforces standards A proper workflow: ( *simplified) *Feature Branch ➡️ PR ➡️ Review ➡️ Merge Git doesn't protect you - these layers and check do. #Git #CoderCo #DevOps

Most engineers learn 4-5 Git commands (add, commit, push, pull, status) and think they know git. Well, it's enough to ship code and also enough to get into trouble 😉 At least learn the ones below to stay safe --> git log --oneline --graph --all Shows the entire branch history as a tree. Whole repo, one screen. --> git reflog Remembers every action for 90 days. Deleted a branch? Reset to the wrong commit? Force-pushed over your work? Reflog brings it back. --> git stash Parks uncommitted work without a commit. Switch branches, come back, pop it. No fake "WIP" commits in your history. --> git bisect Turns debugging into binary search. Tell it a working commit and a broken one. Find the bad commit across hundreds of changes in five steps. --> git blame Finds the commit, the PR, and the context behind a decision someone made eighteen months ago. --> git cherry-pick Pulls a single commit from one branch into another. Hotfix on main you need on staging? One command, no baggage. --> git diff --staged Shows exactly what's about to be committed. Catches debug prints and hardcoded keys before they ship. --> git restore --staged Unstages a file without losing your changes. The fix for "I added the wrong file." --> git switch Modern replacement for git checkout when moving between branches. Cleaner and harder to misuse. --> git clean -fd Deletes untracked files and directories. The nuclear option for a messy working tree. --> git commit --amend Rewrites your last commit. Forgot a file? Bad message? Fix it before anyone sees. Save it. Share it. and Like this post as a thank you😀😀 Subscribe to my Devops newsletter for more quality Devops content https://lnkd.in/gy-eSwWF

My PR got rejected and the code was fine. The commit author was wrong. 🔥 Happy Git Friday! Back in my early git days, when I was working in a lesser controlled environment, I pushed a PR to a work repo and CI flagged it before a human even looked at it. The code passed every test. The linting was clean. The branch was up to date. But the pipeline rejected it because the commit was authored by my personal email, not my corporate identity. I had my global git config set to my personal email. The work repo didn't have a local override. So every commit I made in that repo went out under the wrong identity. I didn't notice because git doesn't warn you. It just uses whatever config it resolves, silently, and moves on. One git config --local user.email fixed it. But the commits already pushed were stamped with the wrong author. Rewriting them meant a force push on a shared branch. Which meant telling the team. Which meant explaining why my personal email was in the commit history of a corporate repo. All because I never set the local config when I cloned the repo. The Danger Zone (When Git Uses the Wrong Identity): 🔹 Git resolves your identity from config without ever asking if it's correct. If global is set and local isn't, global wins. No prompt. No warning. No confirmation. 🔹 Commits pushed under the wrong identity are permanent in the history unless you rewrite them. On a shared branch, that means force-pushing, which affects everyone who has pulled. 🔹 In regulated or audited environments, commit authorship matters. A commit attributed to an unrecognized email can trigger compliance flags, break CI gates, or raise questions during code review. ❓ Question of the Day: How do you configure your global username for Git? A. git config --global user.name "My Name" B. git setup --user "My Name" C. git user --set "My Name" D. git init --user "My Name" 👇 Answer and breakdown in the comments! #Git #GitOps #DevOps #DamnitRay #QOTD #WayBackWhen

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

Developer: “Code works on my machine.” Production: “Cool… now watch this 💥” Somewhere between writing code and merging into GitHub, bugs sneak in, security issues hide, and code quality quietly takes a vacation. Manual reviews try their best… but let’s be honest — nobody spots everything (especially before coffee ☕). 🚀 Why Integrating SonarQube with GitHub Matters In today’s fast-paced development world, writing code is just the beginning — maintaining clean, secure, and reliable code is what truly makes a difference. 🔍 So, why integrate SonarQube with GitHub? When SonarQube is connected to your GitHub repositories, it automatically analyzes your code with every pull request or commit. This means issues are caught before they reach production. 💡 Problems it solves: ✅ Code Quality Issues Detects bugs, code smells, and duplication early in the development cycle. 🔐 Security Vulnerabilities Identifies potential security risks and helps developers fix them proactively. 📉 Technical Debt Highlights maintainability issues so teams can avoid long-term complications. 🔁 Manual Code Review Overload Reduces dependency on manual reviews by providing automated insights. 🚦 Quality Gates Ensures only code that meets defined standards gets merged. ⚡ Why it’s important: Promotes a shift-left approach (fix issues early) Improves developer productivity Builds confidence in deployments Encourages a culture of clean coding 👉 In short, integrating SonarQube with GitHub turns code review into a continuous, automated, and intelligent process. #CodeQuality #SonarQube #GitHub #DevOps #CleanCode #SoftwareDevelopment

Goodbye, Manual Deployment! 👋 | Continuous Integration and Deployment using GitHub Actions & Hostinger I am delighted to announce the successful setup of an automated CI/CD pipeline for my most recent React application! 🚀 Prior to doing this, my deployment process involved steps such as: 1. Building locally. 2. Accessing FTP or the File Manager interface. 3. Uploading the contents of the dist folder manually. 4. Hoping to God I did not forget any files! 😂 Now, however, with the use of GitHub Actions, my workflow involves the following: ✅ Automation of the Build Process: Each commit to the code base generates a build within the virtual environment. ✅ Intelligent Sync Process: All production-relevant files are automatically synchronized to my Hostinger server using FTP. ✅ Lightning-Fast Deployment: My changes are live on the web in less than 2 minutes without human intervention. Aside from saving me time, the process helped me gain further insight into DevOps automation and how it can transform a developer’s workflow. 💻✨ More automation coming up next! 🛠️ #WebDevelopment #ReactJS #GitHubActions #CICD #DevOps #Automation #Hostinger #SoftwareEngineering #ContinuousDeployment

12 Git Commands Every Developer Should Know Today I revised some of the most important Git commands that every developer should be comfortable using. Git is not just a tool — it’s a daily survival skill for developers, DevOps engineers, data professionals, and anyone working on real projects. 📌 Commands I revised: ✅ git init – Initialize a new repository ✅ git add – Stage changes ✅ git commit – Save changes with a message ✅ git push – Upload local changes to GitHub ✅ git pull – Get latest updates from remote ✅ git remote – Connect local repo to remote repo ✅ git branch – Create and manage branches ✅ git fetch – Download updates without merging ✅ git checkout – Switch branches ✅ git merge – Merge code from one branch to another ✅ git status – Check current repo state ✅ git reset – Undo changes / go back to a previous state 💡 What I understood: Git helps us track every code change Branching makes teamwork much easier Commands like status, add, and commit are used almost every day Commands like merge, fetch, and reset are very useful in real-world projects 🔥 My takeaway: If you want to become strong in: Full Stack Development DevOps Data Engineering Open Source Contributions Then Git is non-negotiable. I’m currently improving my development workflow step by step and building stronger fundamentals every day. 📚 Small learning today = big growth tomorrow. #Git #GitHub #DeveloperJourney #WebDevelopment #DevOps #Coding #Programming #SoftwareDevelopment #OpenSource #LearnInPublic #TechSkills #100DaysOfCode

🚨 Stop using git push --force It's one of the most destructive commands in a shared codebase — and most developers don't realize it until something breaks in production. Here's what actually happens when you force push: ❌ Overwrites your teammates' commits silently ❌ Permanently destroys shared history ❌ Breaks CI/CD pipelines mid-deployment The fix? You have better options: (: git push --force-with-lease → Fails if someone else pushed first. Protects your team without you thinking about it. (: git fetch && git rebase origin/main → Pull in upstream changes before pushing. Clean history, zero force needed. (: git reset --soft HEAD~1 → Undo your last commit but keep changes staged. Recommit cleanly — no remote impact. 🔑 The rule of thumb: If anyone else could be touching the branch — never force push. force-with-lease should honestly be your default. Alias it if you have to: git config --global alias.fpush "push --force-with-lease" Have you ever been burned by a force push? Drop a 🔥 below. #Git #DevOps #SoftwareEngineering #OpenSource #100DaysOfCode #Programming #WebDevelopment

Legacy code and life are basically the same thing - just without Git history ) We didn’t write this code. But now we’re responsible for maintaining it. There are weird decisions everywhere: why is this here? why is it done like this? who approved this?.. And then we run git blame… and it’s us ))) Life works the same way: - habits we kept “just in case” - decisions made under pressure - beliefs that should’ve been deprecated years ago And all of it is running in production with zero tests ( Sometimes we just add another if: - “not the right time to fix this” - “we’ll deal with it later” Next thing we know - 5 levels of nesting and no idea what’s going on. Refactoring means: - removing what’s unnecessary - simplifying - stopping backward compatibility with our previous selves (yes, breaking changes are inevitable) And the hardest part - realizing: some of this “legacy” used to be our best practice.