Raymond Andrew Rizzo’s Post

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

"Why is this line like this?" Nobody on the team knew. The code did. 🔥 Happy Git Friday! Code review. Someone flagged a line in a config file that looked wrong. Not broken, just odd. A hardcoded value where a variable should have been. Nobody on the team remembered writing it. Nobody remembered approving it. It had been there so long it was just part of the landscape. Instead of guessing, I ran: git blame config.yml Every line in the file came back annotated with the commit hash, the author, and the date. That odd line? It was a workaround from two years ago. A specific bug in a dependency required a hardcoded value to avoid a crash. The bug was patched six months later. The workaround was never removed. No comment. No ticket reference. Just a line that made no sense anymore because the context was gone. git blame didn't just tell me who wrote it. It told me when, which commit, and gave me enough context to pull up the original PR and understand why. Two minutes of blame saved an hour of guessing and a potential rollback of something that turned out to be safe to remove. The Danger Zone (When Nobody Remembers Why): 🔹 Uncommented workarounds become mysteries the moment the original author leaves or forgets. git blame is the only way to recover the context when the code doesn't explain itself. 🔹 git log shows you commit history for the whole file. git blame shows you commit history per line. When you need to know why one specific line exists, log is too broad. Blame is surgical. 🔹 Removing a line you don't understand is risky. Blame gives you the commit, the commit gives you the PR, the PR gives you the discussion. That's the chain of context that makes the decision safe. ❓ Question of the Day: Which command shows who modified each line of a file and in which commit? Ⓐ git blame filename Ⓑ git who filename Ⓒ git log filename Ⓓ git diff filename 👇 Answer and breakdown in the comments! #Git #GitOps #DevOps #DamnitRay #QOTD

For the first year of my career, my PRs were littered with commented-out code. Old implementations, "just in case" blocks, and debug lines I might need again. I thought I was being careful. I was actually being sentimental. What changed my mind was watching a senior engineer review one of my PRs. He deleted ~60 lines of commented code before merging. I asked why. He said: "If we need this back, git remembers. If we don't, future-you will waste ten minutes wondering if it's important." Then he ran `git log -p <file>` and showed me the exact commit where that block had lived. The insight wasn't technical — it was about trust. Commented code is what you write when you don't trust your version control. If you can navigate git, you don't need a graveyard in your source files. The commands that replaced the habit for me: → `git log -p <file>` — see every change that ever touched this file → `git log -S "<code>"` — find the commit where a specific string was added or removed → `git blame <file>` — who wrote this line, and in which commit → `git stash` — keep temporary experiments off the branch entirely Two honest exceptions I still make: 1. A `// TODO: remove after <flag> ships` block tied to a real in-flight migration. That's not commented code, it's scaffolding with a deletion date. 2. An `// kept for reference, see PR #123` line — rare, and only when the context genuinely matters for the next reader. Everything else goes. Delete it. Commit it. Trust git. What's a code-hygiene habit you unlearned? #backend #git #cleancode

I didn't wait for a production incident to teach me Git. I built the incident myself. Leaked API keys. Bad force pushes. Corrupted history. Merge conflicts. A teammate who wiped the entire branch. A production bug hiding somewhere in 30+ commits. 10 chaos scenarios. No steps. No guide. Just objectives and a terminal. Fix everything. Lose nothing. This is what separates engineers who know Git from engineers who master it: - When a secret gets committed you don't just delete the file. You rewrite every commit in history and treat the key as compromised from the second it was pushed. No exceptions. - When history disappears after a force push you don't panic. You open git reflog and recover every commit from the object store. Nothing is truly gone until garbage collection runs. -When a bug appears in production you don't read through 30 commits one by one. You run git bisect and let binary search find the exact commit, the exact line, the exact author. In five steps. - When you need to undo on a shared branch you don't reset. You revert. One rewrites history your team has already pulled. The other documents the fix and keeps everyone sane. I used to think Git was how you stored files. Now I know it's how you save production. It's how ten engineers work on the same codebase without destroying each other's work. It's how you debug live systems without bringing them down. It's the safety net under the safety net. I documented every scenario the chaos, the commands, the mindset, and the annotated terminal output proving it all worked. Because I don't just learn tools. I master them. 👇 Full article https://lnkd.in/dWDhAAFH Follow my medium for more articles on production operations. #DevOps #Git #CloudEngineering #VersionControl #SoftwareEngineering #LearningInPublic #WomenInTech #WomenInEngineering #Nairobi #Africa

𝗚𝗶𝘁 - 𝗧𝗵𝗲 𝗱𝗮𝗶𝗹𝘆 𝗧𝗶𝗽 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.

Git conventional commits. feat, fix, docs, refactor, chore Honestly, these feel pointless when you're working alone. Nobody's going to review your commits. But I've been in enough team codebases to know what happens when nobody enforces this: "fix stuff" "changes" "wip" "asdfghjk" (we've all done it) Six months later, you're doing git log trying to find where a bug was introduced, and every commit is useless. Conventional commits solve three real things in teams: → Code reviews: the reviewer knows the intent before reading a single line of diff → Changelogs: feat and fix commits can generate release notes automatically → Debugging: git bisect becomes actually useful when messages are meaningful The format is simple: type(scope): description feat(auth): add Google OAuth login fix(api): handle null user on signup chore: upgrade Spring Boot 3.2 Building the habit now while it's just me, so it's second nature when it's not. Do you enforce conventional commits on your team — or is it a free-for-all?

Here is a test I use to understand someone's Git fluency. Two developers. Three years into their careers. Both use Git daily. Developer 1 learned by doing. Commands discovered as needed. Habits picked up from colleagues. When something goes wrong: searches Stack Overflow. Git feels, at times, like a system with its own agenda. Developer 2 learned differently. They know what a branch actually is: a file containing a 40-character hash. They know why rebase rewrites commits: new objects, new hashes. They know why the reflog means almost nothing is permanently lost. When something goes wrong: they reason about what happened. Git feels like a system they understand. Same commands. Completely different relationship with the tool. The gap is not experience. It is not time. It is mental models. The four models that make the difference: 1. HCAT: every Git feature solves one of four problems 2. Object model: four types, content-addressed, linked by hash 3. Three-state: working tree, staging area, repository 4. Reflog: the safety net is real Understand these four things and Git stops being surprising. Which developer are you right now? Be honest. Drop 1 or 2 in the comments.     Drop 1 or 2. No judgment. Tell me one thing you want to understand better about Git.     #Git #SoftwareDevelopment #TechLearning #CareerGrowth #SoftwareEngineering

Every repo in my portfolio follows the same git workflow. Conventional commits. Branch-per-issue. Squash-and-merge to main. It's not because I read a blog post about best practices. It's because git discipline is a compliance habit. Conventional commits mean every change is categorized before it's made. feat, fix, docs, refactor, chore. When you prefix a commit with its type, you're forced to answer: what kind of change is this? That question matters more in compliance than it does in software. CM-3 requires documenting the type, scope, and rationale of configuration changes. A clean commit history does that by default. Branch-per-issue means every change is scoped to one problem. No mixed changes. No "fixed a few things" commits. One issue, one branch, one PR, one squash-merged commit on main. When an auditor asks what changed and why, the answer is one click away. Squash-and-merge keeps main readable. The messy work happens on the branch. What lands on main is one commit per completed issue with a clear message. The git log reads like a changelog, not a stream of consciousness. None of this is required for personal projects. Nobody is auditing my repos. But if you want your portfolio to demonstrate how you think about traceability, auditability, and change control, the git log is the first place a technical hiring manager will look. And it either shows discipline or it doesn't. The work speaks. But the git history shows how the work was done. AJ Yawn GRC Engineering Club #GRCBuilderChallenge #GRCEngineering

🔀 Git Best Practices Every Developer Must Know Git is not just a backup tool. It's how your team communicates through code history. Here's what separates a clean repo from a messy one ✍️ Write Meaningful Commits feat: add user authentication ✅ Not "fix stuff" or "update" ❌ Your commit message is a message to your future self. 🌿 Branch for Every Feature git checkout -b feat/login Never commit directly to main — always work in a branch. 🔍 Review Before You Push git diff --staged Take 60 seconds to review what you're about to push. Catch mistakes before your teammates do. 🔄 Rebase to Stay Updated git pull --rebase origin main Keeps your history clean — no unnecessary merge commits cluttering the log. 💾 Stash Before Switching git stash / git stash pop Save your work-in-progress without making a dirty commit. 🚑 Undo Your Last Commit git reset --soft HEAD~1 Keeps your changes staged — use this before pushing, not after. 💡 A clean Git history tells the story of your project. Make it worth reading. Which Git command do you use the most? #Git #BackendDevelopment #SoftwareEngineering #DevOps #CleanCode #Programming #CSharp