Git Cherry-Pick: Isolate Specific Commits from Other Branches

Day 2: The Workflow (The Emergency Kit) 𝐌𝐞𝐦𝐨𝐫𝐢𝐳𝐢𝐧𝐠 𝐜𝐨𝐦𝐦𝐚𝐧𝐝𝐬 𝐢𝐬 𝐮𝐬𝐞𝐥𝐞𝐬𝐬. 𝐇𝐚𝐯𝐢𝐧𝐠 𝐭𝐡𝐞 𝐫𝐢𝐠𝐡𝐭 "𝐅𝐢𝐱" 𝐫𝐞𝐚𝐝𝐲 𝐢𝐬 𝐞𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠. 🛠️ Yesterday we looked at the architecture. Today, we handle the chaos. In real DevOps work, you don't just "push code." You mess up. You commit to the wrong branch. You realize the code is broken after you commit. You need to switch contexts instantly. I used to be terrified of "breaking" my repo. I would literally copy-paste my folder to Project_V2_Final_Final just to be safe. 😅 To stop doing that, I built the "𝐆𝐢𝐭 𝐄𝐦𝐞𝐫𝐠𝐞𝐧𝐜𝐲 𝐊𝐢𝐭." This isn't just a list of commands; it is a mapping of 𝐏𝐚𝐧𝐢𝐜 → 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧. 👇 𝐒𝐚𝐯𝐞 𝐭𝐡𝐢𝐬 𝐯𝐢𝐬𝐮𝐚𝐥. It covers the 6 most common "Oh No" moments in a developer's day. 🔹 "𝐈 𝐟𝐨𝐫𝐠𝐨𝐭 𝐚 𝐟𝐢𝐥𝐞!" (𝐏𝐫𝐞-𝐏𝐮𝐬𝐡 𝐎𝐧𝐥𝐲) Don't make a "fixing typo" commit. Use git commit --amend to update the previous commit silently. ⚠️ Note: Do not do this if you have already pushed! 🔹 "𝐈 𝐧𝐞𝐞𝐝 𝐭𝐨 𝐬𝐰𝐢𝐭𝐜𝐡 𝐭𝐚𝐬𝐤𝐬 𝐍𝐎𝐖!" Don't commit broken code. Use git stash -u (to catch new, untracked files) to freeze your state and git stash pop to thaw it later. 🔹 "𝐈 𝐜𝐨𝐦𝐦𝐢𝐭𝐭𝐞𝐝 𝐭𝐨 𝐭𝐡𝐞 𝐰𝐫𝐨𝐧𝐠 𝐛𝐫𝐚𝐧𝐜𝐡!" The Sniper Approach: git checkout the correct branch, then git cherry-pick just that one commit. 🔹 "𝐈 𝐧𝐞𝐞𝐝 𝐭𝐨 𝐮𝐧𝐝𝐨 𝐭𝐡𝐞 𝐥𝐚𝐬𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 (𝐛𝐮𝐭 𝐤𝐞𝐞𝐩 𝐦𝐲 𝐰𝐨𝐫𝐤)!" The Safety Net: git reset --soft HEAD~1. It unwraps the commit back into your staging area. #DevOps #Git #Cheatsheet #SoftwareEngineering #LearningInPublic #TechCareers

🚀 Post #352 — Git beyond commit & push Most developers use Git. From developer to Engineer Very few actually understand it. This week I went deeper into Git — the commands that save you during production bugs, bad merges, and broken releases. Here’s a one-liner cheat sheet for senior folks 👇 🧠 Advanced Git commands (real-world meaning) 🔄 git rebase → Rewrite commit history to keep branches clean and linear 🎯 git cherry-pick → Apply a specific commit from another branch (no full merge) 🕵️ git reflog → Recover lost commits even after reset or rebase ⏪ git reset → Move HEAD to a previous state (soft/mixed/hard matters) 🧾 git blame → Identify who changed a line and why 🧪 git bisect → Binary search to find the commit that introduced a bug 📜 git log → Inspect commit history (filters = power) 🚫 git revert → Safely undo changes by creating a new commit 🏷️ git tag → Mark release points (v1.0.0, prod-ready, hotfix) 💡 Why this matters in real jobs Debugging production issues Handling messy merge conflicts Backporting fixes Writing clean, reviewable history Working confidently on large teams Knowing Git deeply ≠ memorizing commands. It’s about control, recovery, and confidence. 👀 Next, I’m planning to deep-dive into rebase vs merge in real production workflows. #Git #SoftwareEngineering #BackendEngineering #DevOps #EngineeringGrowth

🚀 Git Merge vs Git Rebase: When to Use Which. Both merge and rebase combine branches in Git, but they shape your project’s history differently. Choosing the right one keeps your workflow smooth and your history clean. ✅ When to Use git rebase 1. Cleaning up your local commits before merging into a main branch. * Example: Squashing multiple small commits into one meaningful commit. 2. Keeping history linear for a feature branch that only you work on. 3. Updating your branch with the latest changes from `main` (or `develop`) without creating extra merge commits. * Example: `git fetch origin && git rebase origin/main` ❌ When Not to Use `git rebase` 1. On shared branches where others also commit (like `main` or `develop`). Rewriting history here will break other developers’ work and force them to do `git pull --rebase or resolve conflicts manually`. 2. For public tags or releases — never rebase commits that are already pushed to a public repository. 3. If you need to preserve the true branch history for audit or understanding the development flow. ⚡ Rule of Thumb Solo/feature branch: Safe to rebase → keeps history clean. Shared/multi-developer branch: Use merge → safe, preserves history. #tech #git Next post will be - Linkedin doesn't have basic function - text formating, WTF ?

🙄Most developers treat git commit messages as throwaway notes: Most of the time, it looks like this: 🔹fix bug 🔹changes 🔹updated code They work until you need to understand why something changed months later. A simple structure makes commits much easier to read and search: ------------ type: short summary (≤ 50 characters) [optional longer explanation] ------------ For example[see image below] A few useful habits: 👉 Keep the first line under 50 characters so it fits cleanly in logs and UIs. 👉 Use the first line as a summary, not a story; details go in the description. 👉 Add a type for instant context, for example: 🔹feat → new feature 🔹fix → bug fix 🔹chore → maintenance 🔹refactor → behavior unchanged, code improved 🔹docs → documentation only This isn’t about strict rules. It is a small default that makes your history easier to scan for you and your team. #Git #DeveloperExperience #Engineering #CleanCode #SoftwareDevelopment

Why Conventional Commits Matter 🧑💻 While working on a project, I noticed that I was writing random git commit messages and not really following any industry standard. Sometimes the commit messages were unclear and messy. So recently, I started following Conventional Commits, a simple and industry standard way to write clean and meaningful git commit messages. Old commit message: Added login code Using Conventional Commits: feat: add user authentication flow Most commonly used commit types: feat: New feature fix: Bug fix refactor: Code improvement style: Code formatting changes docs: Documentation updates chore: Maintenance and setup tasks Building projects is not only about writing code, it is also about writing clean and meaningful git commits. A small habit, but one that reflects professional engineering practices. #LearningInPublic #BuildInPublic #ConventionalCommits #GitCommit #SoftwareEngineering #FullStackDeveloper

Git, Unlocked: The Visual Map 90% of Developers Wish They Had Sooner 🗺️⚙️ Ever use git commit and git push without truly visualizing the flow? You're not just memorizing commands—you're missing the mental model that makes Git click. Most devs jump straight to commands. The pros understand the 3-layer architecture first. Here’s the exact map I draw for every new engineer on my team: 📍 Layer 1: Workspace (Your active files) → git add → moves changes to Stage ← git reset ← brings them back 📦 Layer 2: Stage (The "loading dock") → git commit → snapshots to Local Repo 💾 Layer 3: Local Repository (Your project’s history) ↔ git push / git fetch ↔ Remote Repo 🔁 Remote Sync Simplified: git fetch = "Check what’s new" git pull = fetch + merge (Brings changes down) git push = Sends your commits up 💎 Pro Insight: git fetch is your preview button. git pull is your merge action. Using fetch first prevents unexpected merge surprises. ✅ Internalize This & You’ll: Navigate merge conflicts with clarity Choose the right command instinctively Collaborate seamlessly across GitHub, GitLab, Bitbucket ⬇️ Your turn: Which Git command confused you MOST when you started? Mine was git rebase — I avoided it for months. 😅 📌 Save this. Share with a dev who needs it. #Git #VersionControl #DevOps #SoftwareEngineering #Coding #Developer #TechTips #Programming #GitHub #WebDevelopment #SoftwareDeveloper #CodingLife #Tech #LearnToCode #DeveloperTools

🧠 One of those quiet developer moments Today I ran into a Git situation that forced me to slow down and think. A rebase surfaced a modify/delete conflict. On the surface, it was just Git asking what to do with a file. But underneath, it was really asking a deeper question: What is the source of truth now? I had intentionally removed a local database as part of a refactor — moving toward an API-driven design. Resolving that conflict meant more than just “fixing Git.” It meant clearly stating architectural intent and making sure the project’s history told the same story. Instead of forcing a push or taking shortcuts, I worked through it properly: acknowledging the change in direction resolving the conflict intentionally and preserving a clean, readable Git history It was a small moment, but it reminded me that good engineering often happens in these quiet decisions — where clarity, discipline, and patience matter more than speed. Learning to respect the why behind the change is just as important as writing the code. #LearningInPublic #SoftwareEngineering #Git #DeveloperGrowth #CleanCode #BackendDevelopment

Git's `fixup!` commits are undersold. I'm convinced most Git users have no idea this functionality exists. The workflow: push work-in-progress commits during code review so reviewers can see incremental changes. Before merge, `git rebase -i --autosquash` collapses them into clean commits automatically—no manual editing of the rebase file. I set `git config --global rebase.autoSquash true` years ago and haven't thought about it since. I wrote up the details, including gotchas with GitHub's merge options and rebasing pain: https://lnkd.in/gVj9bFwh

Day 4: The Master Guide — The Complete Git Reference 𝐖𝐞 𝐡𝐚𝐯𝐞 𝐬𝐩𝐞𝐧𝐭 𝟒 𝐝𝐚𝐲𝐬 𝐦𝐨𝐯𝐢𝐧𝐠 𝐟𝐫𝐨𝐦 “𝐉𝐮𝐧𝐢𝐨𝐫” 𝐭𝐨 “𝐒𝐞𝐧𝐢𝐨𝐫.” 𝐇𝐞𝐫𝐞 𝐢𝐬 𝐭𝐡𝐞 𝐟𝐢𝐧𝐚𝐥 𝐛𝐥𝐮𝐞𝐩𝐫𝐢𝐧𝐭. 🗺️ We started by understanding that Git isn’t a save button — it’s a data structure. We built an Emergency Kit for when things go wrong. We learned why seniors care more about history than commands. Today, I’m sharing the Git Command Center. This isn’t a random cheat sheet. It’s organized by intent — what are you actually trying to do? 📌 Setup & Config — do once 🔄 The Core Loop — do hourly 🌿 Branch Management — do daily ☁️ Sync & Share — collaborate safely 🚑 Undo & Repair — when things break Stop googling: “how to undo last commit git” Save one mental model instead. Junior engineers memorize commands. Senior engineers recognize patterns. If this helped you, save it. If you’re mentoring someone, share it. #DevOps #Git #SoftwareEngineering #CheatSheet #LearningInPublic #TechCareers

The "Branching Strategy" Stop pushing to Main. Your production server deserves better. 🛑🐙 I used to think Git was just about saving my code. Today, I learned it’s actually about Risk Management. As part of my #90DayDevOpsChallenge, I designed a Branching Strategy to handle real-world software lifecycles. 🧩 The Diagram Explained (See image): 1️⃣ The "Happy Scenario" (Feature Work): This is the standard daily flow. Feature Branch: I do my messy coding here. Dev Branch: Where we integrate everyone's code. Staging: The "Dress Rehearsal" for production. Master/Main: The Holy Grail. We never touch this directly. Code only arrives here after passing all tests. 2️⃣ The "Hotfix" Process (Emergency!): This was my biggest learning. Scenario: Production is broken, but the dev branch has half-finished features that aren't ready to release. Solution: I create a Hotfix Branch directly from master. The Fix: Patch the bug, deploy to master immediately. The Crucial Step: Sync Back. I must merge that hotfix back into dev as well. If I forget this, the bug will reappear in the next release! 😱 💡 Key Takeaway: A good branching strategy ensures that "fixing a bug" doesn't accidentally "release unfinished features." #DevOps #Git #GitHub #BranchingStrategy #ReleaseManagement #SoftwareEngineering #LearningInPublic