Tag Archives: coding

You’re working on a feature branch. Your teammate just merged a big update to main. Do you git merge or git rebase? Both integrate changes – but they tell very different stories.

Let’s settle the debate once and for all.

The Short Answer

· Use merge on public/shared branches (e.g., main, develop)
· Use rebase on private feature branches before opening a pull request
· Never rebase a branch someone else might be working on

What Actually Happens?

Merge creates a new “merge commit” that ties together the histories of both branches. Your branch’s commits stay exactly where they were – just with an extra junction point.git checkout feature git merge main

Result: A true, non-linear history. Safe, simple, but adds one extra commit.

Rebase rewrites your branch’s commits as if they started from the tip of main. No merge commit – just a clean, linear line.git checkout feature git rebase main

Result: Beautiful straight history. But you’re changing commit hashes (dangerous if pushed).

Before & After ExampleBefore rebase/merge: A---B---C feature / D---E---F---G main After merge: A---B---C feature / \ D---E---F---G---H main (H = merge commit) After rebase: A'--B'--C' feature / D---E---F---G main

Which One Breaks Things?

· Merge: never breaks existing commits. Always safe.
· Rebase: if you’ve already pushed feature, rebasing forces others to do a messy git pull –force. Don’t do it.

Pro Workflow (Team-Approved)

1. git checkout feature
2. git rebase main (clean up local history)
3. Force push to your personal feature branch (only if no teammates share it)
4. Open a pull request – GitHub/GitLab will merge cleanly with –no-ff (merge commit)

Rebase Interactive: Clean Before You Share

Use git rebase -i HEAD~3 to squash, reword, or drop messy commits. Your reviewer will thank you.pick 1234567 fix typo squash 89abcde oops another fix # combines into previous commit reword def0123 add login feature # changes commit message

Common Mistake: Rebasing main onto feature

Don’t do git rebase feature main. That rewrites main – instant team chaos.

Summary Table

Merge Rebase
History Preserves actual timeline Linear, looks like all commits were made now
Safety 100% safe on shared branches Dangerous if branch is shared
Best for Integrating main into a shared branch Cleaning up private feature branches before PR
Extra commits Adds one merge commit None

Bottom line: Rebase locally, merge publicly. Your team will keep their sanity – and their commits.

You’ve seen the signs: your Node.js API starts fast, but after a few hours, response times creep up. Then the container restarts. You’ve got a memory leak.

The good news? Modern tools make tracking it down far easier than you think.

What You’ll Learn

· How to confirm it’s a leak, not normal growth
· Capturing heap snapshots without stopping your app
· Finding the guilty object in Chrome DevTools

Step 1: Prove It’s a Leak

Run your process with:node --inspect app.js

Open chrome://inspect, attach to your process, and take a heap snapshot. Then force a garbage collection (click the trash can icon), wait 30 seconds, and take another snapshot. If memory doesn’t return to baseline, you have a leak.

Step 2: Compare Snapshots

In DevTools, switch to Comparison view. Look for “size delta” – large positive numbers mean objects aren’t being freed. Expand the constructor list and focus on your own classes or large arrays.

Step 3: Trace the Retainer

Click on a suspicious object. The retainers panel shows why it’s still referenced – often a forgotten event listener, a growing array in a closure, or a global variable.

Common real-world culprits:

· Missing .removeListener() on long-lived EventEmitters
· Caching user data without a TTL or size limit
· Accidentally adding variables to global

Step 4: Fix and Verify

Add process.memoryUsage().heapUsed to a /health endpoint, then load test with autocannon or k6. The fix is confirmed when memory stabilizes after multiple GC cycles.

Pro Tips for Production

· Use node –inspect only temporarily – it has overhead
· For always-on monitoring, try clinic or prom-client with Grafana
· Set up a CI test that fails if heap grows >10% after 1000 requests

Summary

Memory leaks aren’t magic. Heap snapshots + comparison view reveal exactly what’s stuck in memory. Next time your Node.js app gets sluggish, you’ll know exactly where to start.