The Ultimate Guide to Git Merge and Git Rebase

Merging and rebasing are fundamental skills for any developer working with Git. While both are used to integrate changes between branches, they work in very different ways. Mastering these commands enables efficient, organized workflows and keeps your repository in top shape. In this comprehensive guide, we‘ll explore the intricacies of git merge and git rebase, dive into advanced techniques, and lay out best practices that every developer should know.

What is git merge?

Merging is Git‘s way of putting a forked history back together. The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch ^1.

The most common merge scenario is a 3-way merge. Git performs a 3-way merge when the commit history has diverged – i.e. both the source and target branch have new commits. Git uses the common ancestor commit as a reference to generate a new "merge commit" that results in a combining of the changes ^2.

For example:

  A---B---C topic
 /         \
D---E---F---G---H master

Running git merge topic from the master branch will create a new merge commit H that brings in the changes from C.

Git also supports fast-forward merges. If the source branch‘s history contains the entirety of the target branch, Git can simply move the target branch ref forward to the latest commit, skipping the creation of a merge commit ^1.

In terms of merge strategies, the default is the "recursive" strategy which handles complex cases with more than one common ancestor. There‘s also the "octopus" strategy for merging multiple branches at once, and the "ours" and "subtree" strategies for specific merge situations ^3.

Merge drivers allow for defining custom merge strategies for specific files. These can be used to handle merging of binary assets, or to enforce formatting and style standards on merge ^4.

When to use git merge

Merging is the right choice when you want to permanently combine changes from one branch into another. It‘s well-suited for bringing together long-running features into main branches. Merging also works well in busy repositories with many contributors, since merge conflicts will only affect the developer currently merging ^5.

What is git rebase?

Rebasing is Git‘s way of moving branches around. The git rebase command lets you change which commit a branch is based on, as if you had created the branch from a different commit originally ^6. Rebasing replays the commits from the source branch on top of the specified base.

Here‘s a simple example:

A---B---C topic
         \
          D---E---F master  

After running git rebase master from topic, the commit history will look like:

A---B---C topic
         \
          D---E---F master
                   \
                    A‘--B‘--C‘ topic

Git accomplished this by:

1. Saving off the commits from topic (A, B, C)
2. Re-setting topic to the same commit as master (F)
3. Replaying the saved commits on top of topic (A‘, B‘, C‘)

This creates new commits with potentially different SHAs than before. That means you should never rebase commits that have been pushed to a public repository! Doing so would require all other developers to re-synchronize their local repos.

Interactive rebasing via git rebase -i allows surgical editing of commits. You can clean up history by removing, splitting, and combining commits before sharing your changes ^7. The rebase "todo" list controls the process:

pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick fa39187 something to add to patch A
pick 4ca2acc i cant‘ typ goods
pick 7b36971 something to move before patch B

The rebase command also supports moving branches "atomically" with the –onto flag ^6:

git rebase --onto master~4 master~2 topic  

This rebases the topic branch so that it‘s based off master~4 instead of master~2, effectively removing the commits between 4 and 2 from topic.

The key principle to always remember is: never rebase shared history. As long as you follow this Golden Rule of Rebasing, feel free to reorder, edit, and clean up commits as much as you‘d like before sharing them!

Merge vs Rebase: Statistics & Use Cases

Curious how merge and rebase stack up? Let‘s look at some statistics.

In an analysis of popular open source projects, 59% of integrations were done with merge, while 33% used rebase ^8. Merging was more common for larger projects with more contributors, likely because it‘s a simpler, safer operation.

Teams that favored rebasing tended to have stricter commit history standards, or used rebase as a way to keep long-running feature branches up to date. One workflow sees developers rebasing their own changes to clean up history, then merging the final result into a shared main branch.

For pull requests on Github, 54% use merging, while 45% rebase or squash commits before integrating changes ^8. This shows the power of rebase for keeping a tidy commit record before contributions are finalized.

Here are some common use cases for merge and rebase ^5:

Merge:

• Bringing long-running features into main release branches
• Busy projects with many developers contributing
• Repositories where accurate history is favored over cleanliness
• Integrating changes from a shared branch

Rebase:

• Keeping feature branches up-to-date with a moving main branch
• Cleaning up local commits before pushing
• Maintaining clean, linear history on long-running branches
• Applying hotfixes to multiple release branches

Resolving Conflicts & Maintaining History

Merge conflicts are an unavoidable part of working with Git. Both merging and rebasing may require you to manually resolve conflicts if the same lines were changed in both branches.

When a conflict happens, Git marks the affected files and pauses the merge/rebase process. Resolving a conflict involves:

1. Examining the files to find the marked conflict sections
2. Editing the code to the desired final state
3. Marking the files as resolved via git add
4. Continuing the original merge/rebase operation

There are many tools available to assist in resolving tricky conflicts ^10. Graphical "diff" tools like KDiff3, Beyond Compare, and Meld provide intuitive interfaces for examining and resolving differences. Modern Git GUIs like Tower and GitKraken have excellent built-in conflict resolution features.

Git itself offers the often-overlooked git rerere (reuse recorded resolution) feature ^11. When enabled, rerere saves how you resolved a conflicting hunk, and can automatically reapply that resolution if the same conflict crops up again. This is especially handy if you find yourself rebasing the same changes often.

The best way to handle conflicts is to prevent them in the first place. Regularly merging changes from the main development branch into your feature branches (and vice versa) prevents large divergences from building up ^12. Keeping branches small and focused on specific changes also minimizes the chances of overlapping edits.

Large files and binary assets can cause merge headaches since Git can‘t cleanly combine differences. Git LFS (Large File Storage) alleviates this by replacing large files in your repository with text pointers ^13. The actual file contents are stored on a remote server. This keeps your repository lean while still letting you version large assets.

Enforcing Standards with Hooks & Policies

Maintaining consistent merging and rebasing standards, especially on a large team, is crucial for keeping a repository in good shape. Fortunately, Git offers several mechanisms for encouraging good behavior.

Git hooks are custom scripts that run in response to certain Git events ^14. For merging and rebasing, useful hooks include:

• pre-commit: Examine the changes about to be committed, reject or warn if standards are violated
• pre-merge-commit: Inspect the merge result, reject if there are unresolved conflicts
• pre-rebase: Prevent rebasing specific branches or into a protected branch

Hooks can be set up locally on each developer‘s machine, or can be distributed with the repository for consistent team-wide usage.

Branch naming conventions are another good way to communicate intent. Prefixes like feature/, bugfix/, and hotfix/ make it clear what kind of changes a branch contains ^15. Branches with a shared/ prefix could indicate that rebasing that history is not allowed.

Protected branches are a feature offered by repository hosting services like Github and Gitlab ^16. You can specify certain branches as read-only, preventing direct modification. This is useful for ensuring main release branches only receive changes via proper merge requests.

Commit message formatting standards ensure consistency and make it easier to generate changelogs. Many teams adopt a style like:

type(scope): Capitalized, short (50 chars or less) summary
More detailed explanatory text. Wrap it to about 72 characters. 
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how.
Resolves: #123
See also: #456, #789

Following a template like this keeps messages readable and expressive. Linters can automatically check messages and reject commits that don‘t follow the standard ^17.

Recommendations & Best Practices

We‘ve covered a lot! Here‘s a condensed set of recommendations for merging and rebasing on any project.

Use merge for:

• Pulling in changes to a shared main branch
• Bringing long-running feature branches up to date
• Busy repositories where many developers are actively committing
• Incorporating branches after code reviews

Use the –no-ff flag to always generate a merge commit. This preserves history and makes it clear where changes were brought in.

Use rebase for:

• Cleaning up local commits before pushing
• Keeping feature branches up-to-date with main branch changes
• Applying bug fixes to multiple branches
• Ensuring topic branches have a logical, focused commit history

Interactive rebase is a power tool – don‘t be afraid to split, rename, and reorder commits to craft a clear story for your changes.

In general:

• Rebase local changes, merge shared ones
• Merge main release branches, don‘t rebase them
• Avoid "merge loops" by always pulling with –rebase
• Define and enforce team-wide merge/rebase policies
• Keep branches short-lived and focused on specific features/fixes

By keeping these guidelines in mind and taking advantage of Git‘s extensive toolset, your repositories will stay well-organized and be a pleasure to work with.

Conclusion

In this guide, we‘ve taken a comprehensive look at the subtle but significant differences between merging and rebasing in Git. Far from an academic distinction, adopting a clear strategy around these operations has real impact on the clarity of a repository‘s history and its resilience in the face of conflicts.

Merging, the simpler of the two, unifies branches in a non-destructive way. It‘s well-suited for reconciling long-running branches and always leaves a clear record of when and where changes were incorporated.

Rebasing offers the chance to clean up history by curating commits into a coherent narrative. Interactive rebasing is a potent tool for maintaining focused, logically structured changes. The tradeoff is that it rewrites past commits, so it must be used with extreme care on any public branches.

By understanding the nuances of merging and rebasing, you can employ them to maximal effect on your projects. Adopt the workflow patterns covered here and you‘ll avoid many common Git pitfalls. Encourage your team to follow thoughtful, consistent standards around branching and commit history.

Above all, remember that these tools exist to make development more efficient and understandable. Git is immensely powerful, but that power is only realized by wielding it with intent and insight. Here‘s to cleaner merges, revelatory rebases, and repos that are a pleasure to work with!