Why I Stopped Using Git Merge and Started Rebasing Everything

Recent Trends in Git Workflows

Over the past few years, many development teams have shifted toward rebase-first strategies, especially in projects with long-running feature branches or continuous integration pipelines. Public discussions on developer blogs and forums show increasing frustration with merge commits cluttering history. Tools like interactive rebase, --force-with-lease, and Git’s built-in conflict handling improvements have lowered the barrier to adopting rebasing as a daily practice. At the same time, platforms such as GitHub and GitLab introduced options to require linear history for pull requests, nudging teams away from default merge commits.

Background: Merge vs. Rebase

Git offers two primary ways to integrate changes from one branch into another: merge and rebase. A merge creates a new commit that ties together the divergent histories, preserving the exact timeline of when commits were made. Rebase takes the commits from one branch and replays them on top of another, producing a linear sequence. While both achieve the same end state—combining work—they differ in how they represent the project’s story. Proponents of rebase argue that a clean, linear history makes debugging and code review easier; critics counter that rebasing rewrites history and can cause confusion for collaborators.

• Merge commits retain every branch and the precise moment of integration, giving a faithful record of parallel development.
• Rebasing produces a straight timeline, which simplifies navigation but discards the context of when branches diverged.
• Interactive rebase allows squashing, reordering, and editing commits—useful for polishing a branch before sharing.

Common User Concerns

Developers who switch to rebasing often report these recurring worries:

• Losing work. Improper use of git rebase or forced pushes can overwrite commits others depend on.
• Conflict repetition. Every rebase may force the same conflict resolution multiple times if commits are replayed again.
• Team coordination. If multiple developers work on the same branch, rebasing can cause confusion when histories diverge.
• Tooling inconsistency. Some GUI clients handle rebase poorly, leaving developers reliant on command-line expertise.

Many blog posts advocating rebasing acknowledge these issues but stress that disciplined conventions—like never rebasing public branches and using --force-with-lease—can mitigate most risks.

Likely Impact on Team Practices

Adopting a rebase-first workflow tends to produce these changes:

• Cleaner commit logs that support easier bisecting and blame navigation.
• Simpler code review. Reviewers see a linear series of atomic changes rather than merge-confused diffs.
• Fewer “merge hell” situations when conflicting PRs accumulate, because rebasing encourages frequent integration.
• Increased reliance on squash merges as a middle ground—teams rebase locally but use merge-on-accept on the remote to maintain some merge context.

However, teams with junior developers or less Git experience may face a steeper learning curve, and projects with long-lived branches (e.g., release candidates) often find rebasing impractical. The impact varies by team maturity and project lifecycle.

What to Watch Next

The discussion around rebase vs. merge continues to evolve. Several developments are worth monitoring:

• Improved IDE integration. As editors adopt better visual rebase tools, the cognitive overhead of rebasing may drop.
• Automated rebase policies. CI systems now can automatically rebase feature branches onto the target branch, reducing manual steps.
• Alternative history models. Some new version control systems (e.g., Jujutsu, Sapling) experiment with snapshot-based workflows that avoid the merge/rebase trade-off entirely.
• Professional opinion shifts. As more senior engineers publish detailed post-mortems, the industry may converge on hybrid approaches rather than all-or-nothing stances.

For now, the trend toward rebasing reflects a broader desire for maintainable history, but its adoption will likely remain a team-level decision rather than a universal best practice.