Merge vs Rebase: Why I Switched

"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

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

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

𝐄𝐯𝐞𝐫 𝐡𝐚𝐝 𝐆𝐢𝐭𝐇𝐮𝐛 𝐣𝐮𝐬𝐭... 𝐭𝐚𝐤𝐞 𝐚 𝐜𝐨𝐟𝐟𝐞𝐞 𝐛𝐫𝐞𝐚𝐤? ☕️ We’ve all been there. You’ve rebased, updated your baselines, and pushed the final fixes for a feature. You’re ready to merge and move on to the next task, but then you hit the dreaded: "Checking for the ability to merge automatically..." 🔄 It’s been hanging for a while now. Sometimes the simplest part of the CI/CD pipeline becomes the biggest test of patience. When the UI gets stuck in a loop, I’ve found that the most reliable way to move forward is to bypass the browser and handle the merge directly in the terminal. If you’re facing this, here is the generalised workflow to force the issue: 1️⃣ Sync your local environment: 𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡 𝐨𝐫𝐢𝐠𝐢𝐧 2️⃣ Move to your target branch (e.g., your release or main branch): 𝐠𝐢𝐭 𝐜𝐡𝐞𝐜𝐤𝐨𝐮𝐭 [𝐭𝐚𝐫𝐠𝐞𝐭-𝐛𝐫𝐚𝐧𝐜𝐡] 𝐠𝐢𝐭 𝐩𝐮𝐥𝐥 𝐨𝐫𝐢𝐠𝐢𝐧 [𝐭𝐚𝐫𝐠𝐞𝐭-𝐛𝐫𝐚𝐧𝐜𝐡] 3️⃣ Merge the remote feature branch directly: 𝐠𝐢𝐭 𝐦𝐞𝐫𝐠𝐞 𝐨𝐫𝐢𝐠𝐢𝐧/[𝐟𝐞𝐚𝐭𝐮𝐫𝐞-𝐛𝐫𝐚𝐧𝐜𝐡-𝐧𝐚𝐦𝐞] 4️⃣ Push the results to finalize the PR: 𝐠𝐢𝐭 𝐩𝐮𝐬𝐡 𝐨𝐫𝐢𝐠𝐢𝐧 [𝐭𝐚𝐫𝐠𝐞𝐭-𝐛𝐫𝐚𝐧𝐜𝐡] While the "Update branch" button is convenient, there’s a certain peace of mind that comes with seeing the merge happen in real-time in your CLI. 💻 Has anyone else encountered this persistent "checking" state on GitHub lately? Do you prefer waiting it out, or are you a "straight to the terminal" kind of developer? Drop your favorite Git "rescue" commands in the comments! 👇 #GitHub #WebDevelopment #SoftwareEngineering #GitTips #CodingLife #ProblemSolving #DevOps

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

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

Writing code is the easy part. Managing it at scale is where most engineers fail. Initially, I used Git as a "Save" button. But as my data pipelines grew, I realized that "saving" isn't enough. In a high-stakes environment, you aren't just writing scripts. You are managing a living system. When you're building real-world infrastructure: ↳ Multiple features have to move in parallel without colliding. ↳ Code changes fast, and bugs love to hide in the noise. ↳ You need a clear audit trail of why every decision was made. Without a rigorous version control strategy, you aren't building; you're just gambling. While architecting my latest pipelines, I shifted my focus from "writing code" to "managing evolution." Here is how I’ve leveled up my workflow to ensure stability: ↳ Professional Commit Standards 📝 No more "fixed bug" or "minor update." Every commit is a clear, structured record. I’m building a documentation trail that any Senior can read and trust. ↳ Isolated Feature Branching 🌿 main is sacred. Every new feature lives in its own sandbox. This keeps the core pipeline stable while allowing for high-velocity experimentation. ↳ Refactoring with Zero Fear 🛠️ I don’t just "patch" messy code. I refactor it. Because I trust my Git history, I have the leverage to clean up technical debt, knowing I can roll back in seconds if needed. ↳ The "Decision Timeline" ⏳ My Git graph isn't just a bunch of lines. It’s a strategic timeline of how the system evolved. It’s the difference between a "black box" and a transparent, scalable product. In the real world, code is never static. It’s either evolving or it's rotting. Git isn't just a tool for saving files. It’s the leverage that allows a team to move fast without breaking things. I’m no longer just writing scripts; I’m building the systems that keep them running. #Git #DataEngineering #SystemsArchitecture #CleanCode #VersionControl #SoftwareEngineering #AnalyticsEngineering

Most people use Git. Very few understand why it’s so efficient. Here’s the short explanation 👇 🧠 Git = content-based system It doesn’t store files. It stores snapshots (via hashes) Same content? → Stored once. No duplication.(deduplication) ⚙️ What happens in a commit? git commit -m "update" Behind the scenes: • Blob → file content • Tree → folder structure • Commit → snapshot + metadata Everything linked with hashes 🔗 📦 Why Git stays fast • Packfiles → bundle objects • Delta compression → store only changes Change 1 line? Git stores just that. Not the whole file. !! Without this the repose just explode !! 🔧 Hidden layer (most ignore) • Porcelain → git add, git push • Plumbing → actual engine Try this once 👇 echo "hello" | git hash-object -w --stdin You just created a Git object manually. If you understand internals → branching, rebasing, debugging becomes easy. 💡 Insight Git isn’t storing history… It’s storing connected snapshots 📚 Quick refs: https://lnkd.in/gSeM2kmA https://lnkd.in/gEMefujR Git becomes powerful the moment you stop memorizing… and start understanding ⚡ 👉 What part of Git still feels confusing to you? #Git #DevOps #Engineering #Backend — Abhishek Singh Chauhan

Day 103. Branching and pull requests. Not flashy. But this is where real team Git lives. Spent today understanding branching properly — not just git checkout -b and hoping for the best, but why branches exist in the DAG. A branch is just a pointer. A lightweight label on a commit node. That's it. Then pull requests. A PR isn't a Git feature — it's a conversation. You're not just merging code, you're saying "hey, here's what I built, here's why, review it before it touches main." The discipline of: Branching off main cleanly Making focused commits Writing a PR description that actually explains the change ...that's the difference between a codebase you can navigate and one that's a nightmare. Still sharpening. Day 103. Consistent. #Git #DevOps #100DaysOfCode #LearningInPublic #Infracodebase