DEV Community: Matías Denda

What actually happens when you `git merge --no-ff`

Matías Denda — Tue, 21 Apr 2026 14:48:28 +0000

Most developers use git merge without ever thinking about what's happening internally. Then one day they see --no-ff in a team's workflow documentation, Google it, read three Stack Overflow answers, and walk away with a vague sense that "it creates a merge commit or something."

This post is the version I wish I'd read earlier. Two diagrams, one clear distinction, and why it actually matters for your team.

The setup

You're on main. Your coworker merged their feature. You branched off, added two commits, and now it's time to merge your branch back. What happens next depends on one flag.

# You're here
git checkout main
git merge feature

Git has two ways to integrate your feature branch into main. The one it picks by default depends on whether the branches have diverged.

Case 1: Fast-forward (the default, when possible)

If main hasn't moved since you branched off, Git doesn't create a new commit. It just moves the main pointer forward to the tip of your feature branch.

That's it. No merge commit. The feature branch and main now point to the same commit. If you look at git log on main, it reads like D and E were always there. The branch effectively disappears from history.

Case 2: `--no-ff` (always create a merge commit)

With --no-ff, Git creates an explicit merge commit even when a fast-forward was possible:

M is a new commit whose parents are C (the previous tip of main) and E (the tip of feature). It has no code changes of its own — its diff is empty — but it records that these commits were integrated together at this point.

Why this distinction matters

The two histories above contain the same code. So does it matter? Yes, and here's where it bites real teams.

It matters for `git bisect`

git bisect helps you find which commit introduced a bug by doing a binary search through history. With fast-forward merges, the search descends into individual feature commits — you might land on a half-finished refactor where the bug is genuinely present but so is a broken test, making the bisect useless.

With --no-ff, you can run git bisect --first-parent and bisect merge commits only, treating each feature as an atomic unit. Found the regression? You know which feature to revert, not which arbitrary mid-feature commit to blame.

It matters for `git revert`

If you merged with --no-ff and need to roll back the feature, you revert the single merge commit:

git revert -m 1 <merge-commit-hash>

That undoes all of D and E in one go. With fast-forward, you'd need to revert each commit individually — or figure out which commits belonged to the feature in the first place.

It matters for reading history

git log --graph --first-parent main with --no-ff merges shows you a clean list of features integrated into main, one per line. Without merge commits, the log is a flat stream of every individual commit ever made. For a large team, the difference is between "I can see what shipped last week" and "good luck."

What GitHub and GitLab do

When you click "Merge pull request" on GitHub or GitLab, they default to creating a merge commit (--no-ff behavior). The "Rebase and merge" and "Squash and merge" options exist too, but the default merge commit exists precisely because of the benefits above.

This is why teams that use the GitHub/GitLab UI religiously often have cleaner history than teams that merge locally on the command line — the UI forces a pattern that the command line leaves optional.

When fast-forward is fine

For throwaway branches, personal experiments, or single-commit fixes where the commit already tells the whole story, fast-forward is perfectly appropriate. The rule of thumb I use:

Single commit fix → fast-forward is fine
Feature branch with 2+ commits → --no-ff preserves the grouping
Release branch merge → always --no-ff
Hotfix branch merge → always --no-ff (you want revertability)

Making it a team default

If you want the team to use --no-ff consistently, either set it at the repo level:

git config --global merge.ff false

Or — better — require it via branch protection rules on your hosting platform. That way nobody's local config can bypass it.

This post is adapted from a chapter of Git in Depth: From Solo Developer to Engineering Teams, a 658-page book I just released on Git for working developers — from day-to-day tools to CI/CD, branching strategies, and Git at organizational scale. Launch price $29 with code EARLYBIRD (first 100 copies).

Next week: git worktree — the stash replacement nobody teaches you.

Automatic Node.js Version Switching Across Projects

Matías Denda — Fri, 07 Nov 2025 21:21:15 +0000

The Challenge

Modern JavaScript development often involves working on multiple projects simultaneously. Each project may require a different Node.js version:

Legacy project: Node 14
Production app: Node 18 LTS
New experimental project: Node 20

Manually switching versions between projects adds friction to your workflow. You need to remember which version each project uses and run the appropriate commands when switching contexts.

What is AutoNode?

AutoNode is a CLI tool that automatically detects and switches to the correct Node.js version when you navigate between projects. It works seamlessly with your existing version manager (nvm, nvs, or Volta).

Key features:

🔍 Automatic version detection from multiple sources
⚡ Zero runtime dependencies (single native binary)
🔄 Works with your existing version manager
🌍 Cross-platform (macOS, Linux, Windows)
📦 Under 6MB with everything included

How It Works

Version Detection

AutoNode reads version requirements from multiple sources (in priority order):

.nvmrc - Standard nvm configuration file
.node-version - Alternative version file format
package.json - Reads engines.node field
Dockerfile - Parses FROM node:X declarations

This multi-source approach ensures compatibility with different project conventions.

Shell Integration

When you cd into a project directory, AutoNode:

Detects the required Node.js version
Checks which version manager you have installed
Switches to the appropriate version automatically

The integration works through a shell hook similar to other developer tools like direnv or starship.

Installation

One-line install:

  curl -fsSL https://raw.githubusercontent.com/matutetandil/autonode/main/install.sh | bash

The installer will:

Detect your platform and architecture
Download the appropriate binary
Install to a standard location
Configure shell integration for bash/zsh/fish

Manual Commands

You can also use AutoNode manually:

Check detected version without switching

autonode --check

Force reinstall detected version

autonode --force

Update AutoNode itself

  autonode update

Real-World Use Cases

Development Teams

Ensure all team members use consistent Node.js versions across projects without manual intervention.

CI/CD Pipelines

Automatically use the correct Node version in build scripts without hardcoding version numbers.

Monorepo Management

Different packages in a monorepo can specify different Node requirements, and AutoNode handles transitions seamlessly.

Docker Development

Parse Node versions directly from Dockerfiles to match your local environment with production.

Compatibility

Operating Systems:

macOS (Intel & Apple Silicon)
Linux (AMD64 & ARM64)
Windows (AMD64)

Version Managers:

nvm (Node Version Manager)
nvs (Node Version Switcher)
Volta

Shells:

bash
zsh
fish

Roadmap

Planned improvements:

Additional version manager support (fnm, asdf)
Configuration file for custom behavior
Shell completion scripts
Package manager distribution (Homebrew, apt)
Pre-commit hooks integration
CI/CD action/workflow templates

Contributing

AutoNode is open source and welcomes contributions. Whether it's:

Bug reports and fixes
New version detector implementations
Version manager integrations
Documentation improvements
Feature requests

Check out the https://github.com/matutetandil/autonode to get involved.

Try It Out

Installation:

curl -fsSL https://raw.githubusercontent.com/matutetandil/autonode/main/install.sh | bash

Quick test:

  mkdir test-project && cd test-project
  echo "18.17.0" > .nvmrc
  # AutoNode switches automatically
  node --version

Feedback Wanted:

I'm actively looking for feedback on:

Does it work reliably with your setup?
Any edge cases in version detection?
Performance in large monorepos?
Installation experience on different platforms?

Feel free to open an issue or start a discussion on GitHub!

Resources

GitHub Repository: https://github.com/matutetandil/autonode
Documentation: Full setup and usage guide in the README
Installation Script: Direct download and shell integration
Releases: Pre-built binaries for all platforms

AutoNode aims to simplify Node.js version management across projects. If you find it useful or have suggestions, I'd love to hear from you!