<p>When working in a Git-based development team, especially in real-world projects, understanding how to manage branches and history is essential. This post explains the practical use of <code>merge</code>, <code>rebase</code>, and <code>squash</code>, as well as how to use <code>demo</code> or <code>staging</code> branches for safer and more flexible workflows.</p><figure class="image"><img src="https://images.unsplash.com/photo-1584786379647-c10852954d2b?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw4fHxtZXJnZXxlbnwwfHx8fDE3NDY4NDMxMzd8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@lg17?utm_source=DNX&amp;utm_medium=referral">Lance Grandahl</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>Merge, Rebase, and Squash: What's the Difference?</h2><h3>1. <strong>Merge</strong></h3><p>A <code>git merge</code> preserves full commit history by combining branches using a new <strong>merge commit</strong>. This creates a non-linear history with visible branch structure.</p><h4>Example:</h4><pre><code class="language-css">*   Merge branch 'feature/login'
|\
| * Add login UI
| * Hook up auth
* | Update README
|/
* Initial commit
</code></pre><ul><li>✅ Preserves all commits</li><li>✅ Safe for shared branches</li><li>❌ Creates a messier history</li></ul><h3>2. <strong>Rebase</strong></h3><p><code>git rebase</code> moves your feature branch commits on top of the latest <code>main</code>, effectively rewriting history to make it look like your work was created linearly.</p><h4>Example:</h4><pre><code class="language-css">* Add login UI
* Hook up auth
* Update README
* Initial commit
</code></pre><ul><li>✅ Linear, clean history</li><li>✅ Great for solo or short-lived branches</li><li>❌ Rewrites commit hashes — dangerous on shared branches</li><li>✅ Still preserves each individual commit</li></ul><h3>3. <strong>Squash</strong></h3><p>Squashing combines all your commits into a single one during merge (e.g. GitHub's "Squash and merge").</p><h4>Example:</h4><pre><code class="language-css">* Add login feature (squashed)
* Update README
* Initial commit
</code></pre><ul><li>✅ Very clean history (1 commit per feature)</li><li>❌ Original commits are lost</li><li>✅ Ideal for small PRs or open source contributions</li></ul><h2>Resolving Conflicts: Merge vs Rebase</h2><p>When <code>main</code> has moved ahead and your feature branch is behind, you must resolve conflicts <i>before</i> merging.</p><h3>🔁 Option 1: Merge <code>main</code> into your feature branch</h3><pre><code class="language-css">git checkout feature/login
git merge origin/main
</code></pre><p>✅ Safe, preserves history<br>❌ Will create a merge commit</p><h3>🔁 Option 2: Rebase your feature onto <code>main</code></h3><pre><code class="language-css">git checkout feature/login
git rebase origin/main
</code></pre><p>✅ Cleaner history<br>⚠️ Requires force-push if already pushed</p><blockquote><p>Always resolve conflicts <strong>inside your feature branch</strong>, not on <code>main</code>.</p></blockquote><h2>What If You Resolve a Conflict Incorrectly?</h2><p>Git has no way to know if your conflict resolution is <i>logically wrong</i>. If you accidentally delete part of a previously merged feature during rebase/merge, Git will accept it as valid. That’s why it's important to:</p><ul><li>✅ Carefully review changes (<code>git diff</code> / <code>git log -p</code>)</li><li>✅ Run tests or QA before merging</li><li>✅ Use code reviews to catch errors</li></ul><h2>The Role of a <code>demo</code> or <code>staging</code> Branch</h2><p>Many teams use a branch like <code>demo</code>, <code>staging</code>, or <code>dev</code> as an intermediate testing environment.</p><h3>✅ Why Use a Staging Branch</h3><ul><li>Combine multiple feature branches for QA or demos</li><li>Catch integration issues early</li><li>Test experimental features without affecting <code>main</code></li></ul><h3>🔄 Typical Workflow</h3><pre><code class="language-css">git checkout demo
git merge feature/login
git merge feature/auth
</code></pre><p>If a feature is later rejected, you can simply reset <code>demo</code>:</p><pre><code class="language-css">git checkout demo
git reset --hard origin/main
</code></pre><p>✅ Keeps <code>main</code> clean<br>✅ Allows testing in parallel</p><h3>❌ Don't merge <code>demo</code> back into <code>main</code></h3><ul><li>Doing so could bring in unreviewed or abandoned features</li><li>Always merge reviewed features directly into <code>main</code> from their respective branches</li></ul><h2>Summary</h2><figure class="table"><table class="ui table celled"><thead><tr><th>Strategy</th><th>History</th><th>Keeps Commits?</th><th>Clean?</th><th>Safe on Shared Branch?</th></tr></thead><tbody><tr><td>Merge</td><td>Non-linear</td><td>✅ Yes</td><td>❌</td><td>✅ Yes</td></tr><tr><td>Rebase</td><td>Linear</td><td>✅ Yes</td><td>✅</td><td>⚠️ Risky if shared</td></tr><tr><td>Squash</td><td>Linear</td><td>❌ No</td><td>✅✅</td><td>✅ Yes</td></tr></tbody></table></figure><p>When used wisely, these strategies give you the best of both worlds: clean, readable history and safe, flexible workflows.</p><p>If you're managing features across multiple environments, introducing a <code>demo</code> or <code>staging</code> branch lets you test without polluting your production history.</p><p>Use <code>merge</code> for safety, <code>rebase</code> for clarity, and <code>squash</code> for simplicity. Just be deliberate — and communicate with your team.</p>

When working in a Git-based development team, especially in real-world projects, understanding how to manage branches and history is essential. This post explains the practical use of merge, rebase, and squash, as well as how to use demo or staging branches for safer and more flexible workflows.

Understanding Git Merge Strategies: Merge, Rebase, Squash, and the Role of Staging Branches

<p>When working with Git, merging branches is a fundamental part of collaboration. But not all merges are the same. There are <strong>three main merge strategies</strong> you can use, and each one impacts your repository history differently.</p><figure class="image"><img src="https://images.unsplash.com/photo-1621165755630-367fc1c27da4?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxN3x8bWVyZ2V8ZW58MHx8fHwxNzQ2ODQzMTM3fDA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@raimondklavins?utm_source=DNX&amp;utm_medium=referral">Raimond Klavins</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>Here’s a clear breakdown of each method:</p><h2>✅ 1. Fast-Forward Merge (when possible)</h2><p>This is the cleanest type of merge. Git simply <strong>moves the pointer</strong> of the current branch forward — no new commit is created.</p><pre><code class="language-plaintext">git merge feature-branch              # if fast-forward is possible
git merge --ff-only feature-branch    # enforce fast-forward only
</code></pre><p><strong>What happens:</strong></p><p>No new commit is created</p><p>Branch history remains linear</p><p>It looks like all work was done directly on <code>main</code></p><p><strong>Use when:</strong> <code>main</code> hasn’t changed since <code>feature-branch</code> was created.</p><h2>🔁 2. Merge Commit (default when branches diverge)</h2><p>This is Git’s default behavior when branches have diverged.</p><pre><code class="language-plaintext">git merge feature-branch
</code></pre><p><strong>What happens:</strong></p><p>Git creates a new <strong>merge commit</strong></p><p>Both branches' histories are preserved</p><p>The history becomes <strong>non-linear</strong>, with a visible merge point</p><p><strong>Use when:</strong> You want to retain the full commit history of both branches.</p><h2>🧱 3. Squash Merge (<code>--squash</code>)</h2><p>This strategy takes all the changes in the feature branch and <strong>squashes them into a single commit</strong>.</p><pre><code class="language-plaintext">git merge --squash feature-branch
git commit -m "Add feature"
</code></pre><p><strong>What happens:</strong></p><p>All commits in the branch are combined into one</p><p>No merge commit is created automatically</p><p>The branch structure is not recorded in history</p><p><strong>Use when:</strong> You want a <strong>clean, one-commit-per-feature</strong> history (e.g., for open-source projects or public repos).</p><h2>⚙️ Other Merge-related Options</h2><figure class="table"><table class="ui table celled"><thead><tr><th>Option</th><th>What it does</th></tr></thead><tbody><tr><td><code>--no-ff</code></td><td>Forces a merge commit even if fast-forward is possible</td></tr><tr><td><code>--ff-only</code></td><td>Fails the merge if fast-forward isn’t possible</td></tr><tr><td><code>--squash</code></td><td>Combines all changes into one new commit</td></tr><tr><td><code>--no-commit</code></td><td>Prepares the merge but doesn’t commit it (review first)</td></tr></tbody></table></figure><h2>🔁 Summary Table</h2><figure class="table"><table class="ui table celled"><thead><tr><th>Strategy</th><th>Command</th><th>New Commit?</th><th>Keeps History?</th><th>Clean?</th><th>Notes</th></tr></thead><tbody><tr><td>Fast-forward</td><td><code>git merge</code> or <code>--ff-only</code></td><td>❌ No</td><td>✅ Yes</td><td>✅ Yes</td><td>Pointer move only</td></tr><tr><td>Merge commit</td><td><code>git merge</code> or <code>--no-ff</code></td><td>✅ Yes</td><td>✅ Yes</td><td>❌ No</td><td>Default if divergent</td></tr><tr><td>Squash</td><td><code>git merge --squash</code></td><td>✅ Yes</td><td>❌ No</td><td>✅ Yes</td><td>Flattens to one commit</td></tr></tbody></table></figure><p>For public projects like <strong>SwimSnap</strong>, adopting <code>--ff-only</code> or squash merges ensures a readable, maintainable Git history. It helps contributors and maintainers stay focused on features, not merge clutter.</p><p>Want help automating your merge strategy or enforcing it on GitHub? Just ask!</p>

When working with Git, merging branches is a fundamental part of collaboration. But not all merges are the same. There are three main merge strategies you can use, and each one impacts your repository history differently.

All Posts In Git