<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.

All Posts In Rebase