Version control - Advanced Techniques and Tooling

Advanced Practices and Tools Understanding Rebase and Merge Strategies When you have divergent branches in Git—where work has progressed separately on different branches—you eventually need to combine them back together. There are two fundamentally different approaches to do this: rebasing and merging. Understanding the difference between them is crucial because they produce different commit histories and serve different purposes. What is Merging? Merging creates a new commit (called a merge commit) that combines the work from two branches. When you merge branch B into branch A, Git creates a single commit that has two parent commits: the tip of branch A and the tip of branch B. This new commit represents the point where the branches came together. The key characteristic of merging is that it preserves the complete history of both branches. Every commit that was made on either branch remains in the repository exactly as it was. The merge commit simply connects the two histories together. What is Rebasing? Rebasing takes a different approach: it rewrites the commit history by moving your commits to a new base. When you rebase branch B onto branch A, Git essentially replays the commits from branch B on top of the current state of branch A. This produces a linear, sequential history where all commits appear to have been made one after another in a straight line. Rebasing is powerful because it produces a clean, easy-to-follow commit history. Instead of seeing branches split and merge, you see a single sequence of commits. However, this comes with an important caveat: rebasing changes commit hashes, which means the commits are technically different objects in Git's database, even though they contain the same code changes. Comparing the Two Approaches The choice between rebasing and merging depends on your workflow and goals: Use merging when: You want to preserve the complete history of how work progressed, including when branches were created and merged. Merging is also safer for shared branches because it doesn't rewrite history. Use rebasing when: You want a clean, linear history that's easy to follow. Rebasing is excellent for cleaning up local work before sharing it, but should be used carefully on shared branches since it rewrites history. The diagram above illustrates these concepts: the trunks (green) represent main branches, branches (yellow) show divergent work, and merges (red) show where histories come together. Notice how merging creates a visible join point, while rebasing would instead replay those commits sequentially. Squash Commits Before merging your work into a shared branch, you may have several commits on your feature branch that represent your development process—some might fix bugs in earlier work, some might be experimental, or some might just be "works in progress." While this history is fine for your local development, sharing many small commits can clutter the project's history. Squashing is the process of combining multiple commits into a single commit. This is particularly useful before merging because it allows you to present your feature as a clean, single unit of work rather than a sequence of intermediate steps. How Squashing Works When you squash commits, Git combines all the changes from multiple commits into one. The new commit contains all the code changes but has a cleaner, combined commit message. For example, if you had three commits like: "Add search function" "Fix typo in search function" "Improve search performance" You could squash these into a single commit: "Add search function with performance improvements." The result is a single, polished commit that represents the completed feature. When to Squash Squashing is most valuable in these situations: Before merging a feature branch: It presents your feature as one complete addition rather than showing the messy development process. Cleaning up local history: When you have many small "checkpoint" commits that don't add meaningful information, squashing reduces clutter. Following project conventions: Some teams require squashing to keep the main branch's history clean and readable. <extrainfo> When Not to Squash While squashing is useful, you shouldn't always do it. Avoid squashing if: The commits represent logically distinct changes that should be understood separately You're on a shared branch (squashing rewrites history, which can cause problems for other developers) Each commit in the sequence has value for understanding how a complex feature was built </extrainfo>