GitHub commit attributed to wrong account, not a bug

𝗠𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗚𝗶𝘁𝗛𝘂𝗯 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀 𝘀𝗵𝗼𝘂𝗹𝗱𝗻’𝘁 𝗯𝗲 𝘁𝗵𝗶𝘀 𝗽𝗮𝗶𝗻𝗳𝘂𝗹… 𝗯𝘂𝘁 𝗶𝘁 𝗶𝘀. Over the past few months, I kept running into a frustrating issue: using work + personal GitHub accounts on the same machine without breaking SSH or mixing identities. So I built a clean, repeatable SSH setup that solves the following: • Authentication conflicts • Wrong-account commits • Broken push/pull workflows What’s inside the guide: • Separate SSH keys per account • Smart aliasing via ~/.ssh/config • Per-repo Git identity setup • Quick debugging checks The goal was simple: 👉 Make it predictable and production-safe—not just “works on my machine." If you’ve ever pushed code from the wrong account… you know the pain. 😅 🔗 GitHub repo: https://lnkd.in/dFH75WvV If this helps, consider giving the repo a ⭐ #github #git #ssh #developers #webdev #softwareengineering #opensource

Day 9 💸 The API Key Incident (And What I Learned) I made a mistake that could have been very expensive. I committed my Anthropic API key to GitHub. Twice. The first time: I created the .env file using Windows PowerShell's echo command. It saved with null bytes AND got committed before .gitignore was properly set up. GitHub caught it instantly and blocked my push with: "Push cannot contain secrets — Anthropic API Key detected." I had to: → Immediately rotate the API key → Rewrite the entire git history to remove it → Force push to GitHub → Set up .gitignore properly The second time was the same mistake — I recreated .env locally after fixing everything, forgot to verify it was ignored, and ran git add . blindly. Lesson learned the hard way: Never run "git add ." blindly. Always run "git status" first. Keep secrets in environment variables. Never in code. Never in commits. Never. Mistakes are part of building. What matters is that you don't make the same one three times. → Day 9 of 14: The expensive lesson about secrets management. #BuildInPublic #AutoVizAI #SecurityBestPractices #Git #GitHub #DevSecOps #StudentDeveloper

Have you ever tried to pull from GitHub, but it failed because of local uncommitted changes that you still want? Or tried to switch branch, but you have uncommitted changes that are still in work, and you don't want to commit them? The quickest and easiest solution for that is to use the "git stash" command, which temporarily saves the current uncommitted changes locally, so pulling or switching will work fine, then when you need to restore those hidden changes, just use "git stash pop". Just two quick commands: > git pull = failed > git stash > git pull = works! Then: > git stash pop Note: if you have untracked new files, add "-u" flag: "git stash -u". I use these commands almost daily. Have you heard about them before? #GitHub #ProgrammingTips #DailyWork

GitHub's April availability post frames the recent pain as a capacity problem driven by agentic development workflows. That is real, but it is not the whole story. Two incidents in five days exposed different failure classes: a merge queue correctness bug that could produce wrong squash merge commits, and an Elasticsearch overload that made PR and issue views look empty while underlying data still existed. That is workflow reliability debt, not simple uptime. Developers do not care that Git operations technically work if pull request views disappear, merge queues mutate branch state, Actions queues stall, and the status page still protects the headline percentage. The key question is whether GitHub is treating merge correctness, search-coupled UI paths, feature flag hygiene, and degraded-performance reporting with the same urgency as the 30X capacity plan. https://lnkd.in/eJMnVPCt

GitHub doesn't tell you how big a repo actually is until you've already pulled it down. So you wait. You watch the progress bar. You wonder if you really needed all of it. Reposizer is a one-line npm tool that shows you the size, file count, language breakdown, and stars of any repo — public or private — before you clone.   npx reposizer owner/repo No login. No GitHub token unless the repo is private. It's the check I wish I'd had every time I've ever blindly typed git clone. 📘 Docs: https://lnkd.in/e4Zgs7EN #opensource #developertools #npm #buildInPublic

When GitHub goes down, what's truly under your control? Observing the recent GitHub multi-service incident, it's a stark reminder about the illusion of total abstraction. We build on layers of services, often assuming the base layer is infallible. But when core components falter, the question isn't just "is it back up?", but "what could I have actually done differently to maintain control?" This pushes me to double down on building systems with clear boundaries and explicit fallbacks, even for services we're deeply integrated with. The goal isn't to avoid all external dependencies, but to understand their blast radius and retain a meaningful degree of operational control over our own critical path.

GitHub just rolled out a Rule insights dashboard and a unified filter bar! This is great for anyone managing repos with complex rule sets. Finally, a clearer view on how those rules are performing and easier filtering. Little quality-of-life updates like these make a big difference in daily dev work. #GitHub #DevTools

We added native GitHub CI compliance checks to Infracodebase. When a pull request is opened, we automatically evaluate the code against your compliance rules and post the result as a GitHub Check Run. You get inline annotations showing exactly which lines triggered failures. No YAML. No API keys. No workflow setup. If your repo is already connected through the Infracodebase GitHub App, you enable this with a single toggle. The next PR runs automatically. How it works → GitHub sends a webhook on PR open → We clone the repo at the PR commit SHA → An agent evaluates the code against your rules → Results are posted as a Check Run with inline annotations → Required rulesets act as hard gates and can block merges Teams can enforce minimum compliance scores and require specific rulesets before anything is merged. This makes compliance part of the PR, not something you check after the fact. #GitHub #DevOps #Compliance #InfrastructureAsCode #CloudSecurity #CICD

Regardless of where you work, Infracodebase can perform continuous audits at a human level. This not only provides assurance, but evidence for future audits in regulated companies. If you are struggling with the gap between deterministic tests and annual audits, you should reach out.

GitHub had a clever "chicken and egg" problem: needing GitHub to deploy GitHub! 🐔🥚 They're solving tricky circular dependencies in deployments by using eBPF to selectively block problematic network calls. What's even cooler? They can trace those blocked requests back to the specific command. Super smart for safer deployments and faster incident recovery! #eBPF #DevOps