Git Cherry-Pick: Applying Specific Commits Daily

In my circles, surprisingly few people use git worktree — even though it’s been one of the most useful workflow changes I’ve made when working with coding agents. I use a simple hub + spokes setup: one central repo as the hub, with each branch checked out into its own “spoke” directory. Instead of constantly switching branches and stashing, you check out each branch into its own directory. They share the same Git history, but each has its own clean working copy. That means you can run a separate agent in each — one on an auth refactor, another on a new endpoint, a third writing tests — all in parallel, without collisions. Your main checkout stays untouched. A few things that surprised me: • In my experience, agents produce better output starting from a clean state • When one goes sideways, I just remove the worktree (after pushing anything useful) and start over • Same branch point, two worktrees, two agents — diff the results, keep the better one I wrote up the full workflow here: https://lnkd.in/dDD6V6w5 I’m curious: how are you handling parallel development with agents today? Do you use worktrees, separate clones, or something else? Feel free to share in the comments. #AIEngineering #AIAssistedDevelopment #EngineeringWorkflows

How do you resolve a Git knot? Every developer eventually hits that moment. 👉 You pull the latest changes… 👉 Try to merge your branch… 🔥 And suddenly Git throws a wall of conflicts at you. Files everywhere. Markers like <<<<<<, ======, >>>>>>. 😂 Nothing compiles anymore. Welcome to what I call a Git knot. It usually happens when multiple developers modify the same areas of the codebase, and the histories diverge. At this point, Git can’t decide which change should win — so the decision moves to you. Here’s the approach that has saved me many times: 1️⃣ Don’t panic — inspect the history. Run git log, git diff, or check the commit history on your branch and the target branch. Understanding why the conflict exists is half the solution. 2️⃣ Resolve conflicts intentionally. Open the conflicting files and carefully decide: Keep your change Keep the incoming change Combine both logically The goal isn’t just to make Git happy — it’s to preserve the correct behavior of the system. 3️⃣ Compile and test immediately. After resolving conflicts, always run the application or test suite. Conflicts resolved incorrectly often introduce subtle bugs. 4️⃣ Commit the resolution clearly. A clean commit message like "Resolve merge conflicts between feature/payment-flow and main." helps future maintainers understand what happened. 5️⃣ Prevent the next knot. Git knots happen less when teams: Pull frequently Work on smaller PRs Keep branches short-lived Communicate about overlapping changes Version control is not just a tool — it’s a collaboration system. And the more people touching the codebase, the more important that discipline becomes. Curious how others handle this. 🤔 When you hit a Git knot, what’s your first move? 😊 #SoftwareEngineering #Git #VersionControl #Programming #DeveloperLife #TechTips #CodeCollaboration #BuildInPublic

Most developers can use Git. Fewer understand how it actually works internally. And that gap shows up the moment things go wrong: -> A bad git reset --hard -> A messy rebase -> Duplicate commits after rewriting history -> Lost work after a detached HEAD The turning point for me was this: Git is not a “change tracker.” It’s a content-addressable snapshot database backed by a Directed Acyclic Graph (DAG). Once you internalize that: -> A commit = snapshot + metadata + parent pointer -> A branch = mutable reference to a commit hash -> HEAD = pointer to a reference (or directly to a commit in detached mode) -> Rebase = replaying diffs to create new commits (new hashes) -> Reset = moving a branch reference -> Revert = creating inverse history without rewriting -> Reflog = reference movement journal (your real recovery tool) Git stops feeling magical. It becomes deterministic. I wrote a deep technical breakdown covering: -> How Git constructs the commit DAG -> Why rebasing changes commit identity -> What actually happens in soft vs mixed vs hard reset -> Why merge commits have two parents -> How conflicts arise from overlapping snapshots -> When history rewriting is safe vs dangerous -> How to recover “lost” commits using reflog If you care about clean history, safe collaboration, and understanding what your tooling is doing under the hood — this is for you. 🔗 Read the full guide here: https://lnkd.in/dYWjk3g9 For the engineers here — what’s your rule around rebase vs merge on shared branches? #git #distributedversioncontrol #softwareengineering #devops #backend #engineering

𝐆𝐢𝐭 𝐅𝐞𝐭𝐜𝐡 𝐯𝐬 𝐆𝐢𝐭 𝐏𝐮𝐥𝐥 — 𝐎𝐧𝐞 𝐒𝐦𝐚𝐥𝐥 𝐃𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐜𝐞, 𝐁𝐢𝐠 𝐈𝐦𝐩𝐚𝐜𝐭 A lot of Git confusion starts right here. Many developers assume 𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡 and 𝐠𝐢𝐭 𝐩𝐮𝐥𝐥 do the same thing. But They don’t — and that misunderstanding causes most Git-related issues in teams. When you run 𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡, Git only communicates with the remote repository. It downloads the latest commits and updates your local reference (origin/main). Your working code remains untouched. No files change. No conflicts. No surprises. Now comes 𝐠𝐢𝐭 𝐩𝐮𝐥𝐥. 𝐠𝐢𝐭 𝐩𝐮𝐥𝐥 goes a step further. It fetches the changes and immediately merges them into your current branch. 𝐓𝐡𝐚𝐭’𝐬 𝐰𝐡𝐲: • Files suddenly change • Merge conflicts appear • People feel Git is unpredictable In reality, Git is being precise — not random. The key line every engineer should remember: 𝐠𝐢𝐭 𝐩𝐮𝐥𝐥 = 𝐠𝐢𝐭 𝐟𝐞𝐭𝐜𝐡 + 𝐠𝐢𝐭 𝐦𝐞𝐫𝐠𝐞 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐰𝐡𝐲 𝐦𝐚𝐧𝐲 𝐞𝐱𝐩𝐞𝐫𝐢𝐞𝐧𝐜𝐞𝐝 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐬 𝐩𝐫𝐞𝐟𝐞𝐫 𝐭𝐨: • Run git fetch • Review the incoming changes • Merge only when they’re ready Same commands. Different level of control. Once this concept is clear, Git stops feeling confusing and starts feeling reliable. #Git #DevOps #SoftwareEngineering #VersionControl #Engineering #Tech

🧠 A Git Trick That Can Save Your Commit History You push a few commits and then notice the problems: • A terrible commit message • A debug file accidentally committed • Two commits that should have been one Most developers just move on and leave the history messy. But Git actually gives you a way to rewrite recent history cleanly. git rebase -i HEAD~3 This tells Git: "Let me interactively modify the last 3 commits." Git opens an editor that lets you do things like: reword → fix a bad commit message squash → combine commits into one clean change edit → pause the rebase so you can modify files in that commit drop → completely remove a commit For example, if you choose edit, Git pauses at that commit and lets you fix things: git add . git commit --amend git rebase --continue And just like that, the commit is rewritten. Instead of a messy history like this: fix fix again oops forgot file another fix You end up with: feat: add payment service validation logic Clean history isn't just aesthetic. It makes code reviews easier, debugging faster, and collaboration smoother. One small Git command — massive improvement in developer workflow. #Git #DevOps #DeveloperTips #SoftwareEngineering

Many developers know git merge. Many use git rebase. But git cherry-pick is one of the most useful Git commands when working with multiple branches. What git cherry-pick actually does: It lets you apply a specific commit from one branch to another. Instead of merging the whole branch, you pick only the commit you need. Real Situation Where git cherry-pick Saves You Imagine this happens: You were working on a feature branch, but while committing you forgot to switch branches. So your commits went to main instead. main ├─ commit A ├─ commit B ├─ commit C ← these should be in feature branch You actually wanted those commits in: feature/new-feature Now what do you do? Step 1 — Create / switch to the correct branch git checkout -b feature/new-feature (or switch if it already exists) git checkout feature/new-feature Step 2 — Cherry-pick the commits from main Find the commit hashes: git log Example: abc123 commit A def456 commit B ghi789 commit C Then cherry-pick them: git cherry-pick ghi789 git cherry-pick def456 git cherry-pick abc123 Now those commits are in your feature branch. Note: cherry-pick should be applied oldest → newest (same order they were originally created) Step 3 — Clean up main Switch back to main: git checkout main Remove the last 3 commits: git reset --hard HEAD~3 Now main is clean again. Result: main └─ clean history feature/new-feature ├─ commit A ├─ commit B └─ commit C Exactly where they were supposed to be. Another Example Imagine this situation: You have two branches: => main => develop You fixed a critical bug in develop, but that fix is also needed in main immediately. You don’t want to merge the whole develop branch because it contains unfinished features. So you simply do: git cherry-pick <commit-hash> Now: => Only that bug fix commit moves to main => No unfinished features are included Clean. Safe. Fast. Why git cherry-pick is powerful? Because mistakes like committing to the wrong branch happen all the time. Instead of panicking, you can just pick the exact commits you need and move them to the correct branch. This is one of those Git commands that saves you in real-world development. #git #github

Git commits: one per task or multiple small commits? This is a common debate in many development teams: 👉 One commit per task vs 👉 Multiple commits with a single responsibility Some teams prefer one commit per task to simplify cherry-picking and releases. Others advocate for multiple small commits, each representing one logical change, which makes reviews, debugging, and reverting much easier. In practice, small focused commits usually lead to better collaboration. This approach aligns with the Single Responsibility Principle (SRP) — applied to commits. **Example** Task: Add customer discount feature **Bad practice — One big commit per task** Single commit: Added discount feature But inside this commit, changes include: - Database schema - API logic - UI forms - Bug fixes - Refactoring - Formatting changes **Problems:** - Hard to review - Hard to revert partially - Hard to debug later - Git history becomes unclear - One commit ≠ One responsibility **Better practice — Split commits by responsibility** Same task, structured commits: - feat(db): add Discount column to Customer table - feat(api): implement discount calculation logic - feat(ui): show discount in customer form - test: add tests for discount calculation - refactor: simplify invoice total calculation Now each commit: - Has one clear responsibility - Is easy to review - Can be reverted safely - Has clear intent - Reduces cherry-pick conflicts Small commits make reviews easier, debugging faster, and collaboration smoother. Clean commit history isn’t just about Git — it’s about helping your future self and your teammates understand what really changed. #Git #SoftwareEngineering #CleanCode #DevWorkflow #VersionControl #Developers

This is good starting point! Another good idea is WIP: End Of Day commits, many times i've seen people crushed over "system updates" or "lost progress" simply because they relied on the stability of their working environments =) Works 99% but that 1% stings...

"I just lost 3 days of work." No, you didn't. You just don't know git reflog. Most developers panic when things go wrong in Git. Senior engineers open reflog. Here's how to undo almost anything: Accidentally committed to the wrong branch? → git reset HEAD~1 → git stash → git checkout correct-branch → git stash pop Force pushed and lost commits? → git reflog → git reset --hard <sha> Need to undo a merge? → git revert -m 1 <merge-commit> Deleted a branch with unmerged work? → git reflog → git checkout -b recovered-branch <sha> The secret most people miss: Git almost never actually deletes anything. git reflog is your time machine. It tracks every HEAD movement for 90 days — even after reset, rebase, or branch deletion. Every "oh no" moment has a recovery path. The difference between a junior panicking and a senior recovering in 30 seconds? One command: git reflog. What's the worst Git disaster you've recovered from? #Git #SoftwareDevelopment #DevOps #Programming #CodingTips #VersionControl #DeveloperTools

⚠️ I thought I just deleted hours of work. Turns out… Git saved me. I had just committed some code, but commit message wasn’t right. Usually, my flow is: git stash git reset --soft HEAD~1 git stash apply Recommit with a better message But this time, I skipped the stash step and ran git reset --hard HEAD~1 And immediately realised — the commit wasn’t pushed, and I hadn’t stashed anything. 😅 That’s when the panic started. Then I remembered: Git almost never truly deletes things immediately. I ran: git reflog And there it was — the “lost” commit. I restored it with: git reset --hard <commit-hash> Crisis avoided. 📚 But the bigger lesson wasn’t recovery, it was understanding Git more deeply. After restoring the commit, I also learned how to properly edit history: git commit --amend → modify the last commit message No stashing. No resetting. No unnecessary risk. 🛠️  Sometimes growth as a developer isn’t about writing more code. It’s about understanding the tools better #developers #git #versioncontrol #webdevelopment #shopifydeveloper #learninginpublic