null
July 25, 2018

Git Rebase vs. Merge: Which Is Better?

Git at Scale
Version Control

The Git community is divided as to which is better for your workflow – Git rebase vs. Git merge. Advocates of Git rebase like it because it simplifies their review process. Advocates of Git merge like it because it preserves the history of a branch. So, what is the best solution for you and your team?

Merging is a common practice for developers using version control systems. Whether branches are created for testing, bug fixes, or other reasons, merging commits changes to another location. To be more specific, merging takes the contents of a source branch and integrates it with a target branch. In this process, only the target branch is changed. The source branch history remains.

However with Git, there is the second option of rebasing. This is another way to integrate changes from one branch to another. Rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch. Unlike merging, rebasing flattens history because it transfers the completed work from one branch to another. In the process, unwanted history is eliminated. 

The Great Git Rebase vs. Merge Divide

This question has split the Git community. Some believe you should always rebase and others that you should always merge. Each side has some convincing benefits.

Git Rebase

  • Streamlines a potentially complex history
  • Avoids merge commit “noise” in busy repos with busy branches
  • Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams

Git Merge

  • Simple and familiar
  • Preserves complete history and chronological order
  • Maintains the context of the branch

So which one should your team use?

Git Rebase Makes Sense for Individuals – The Jury Is Out for Teams

Like so many other things in life, the answer to the Git rebase vs. merge workflow question is “it depends.” At Perforce, we believe neither the “always merge” nor “always rebase” extreme is necessary. There can be space for both.

Let’s review Git rebase issues:

  • Rebasing privately affects only the individual (prior to work being pushed)
  • Rebasing publicly impacts others
  • Rebase simplicity and elegance end where teams begin
  • Team policies are essential and supersede individual preferences
  • History is an essential component for other teams, regulatory compliance, supportability, and more

For individuals, rebasing makes a lot of sense. The beauty of Git is the ability to branch for every unit of work, as often as you like. Also, you can and should commit often when working locally (individually). Rebasing allows you to clean up prior to review. But when working with others, we recommend sticking with merge to avoid confusion.

Merging and Rebasing Strategies

Teams need to consider several questions when setting their Git rebase vs. merge policies. Because as it turns out, one workflow strategy is not better than the other. It is dependent on your team. Consider the level of rebase and Git competence across your organization. Determine the degree to which you value the simplicity of rebasing as compared to the traceability and history of merging.

Finally, decisions on merging and rebasing should be considered in the context of a clear branching strategy. A successful branching strategy is designed around the organization of your teams. Developers should be organized in parallel teams, allowing them work at their own pace and not be impacted by others.

For example, you could have a development branch where each team is isolated. Work would be delivered only when it makes sense. This makes it possible to clearly isolate units of work from the main branch. It is also keeps it isolated from QA, which is isolated from pre-production, and so on. In short, your branching strategy should reflect the shape, roles, and goals of your organization.

Perforce Improves Your Git Strategy

Perforce solutions allow developers to use Git the way they want to, while improving productivity. They can merge or rebase without delays.

With Perforce’s Git Platform, Helix4Git, you can easily scale Git to handle large file sizes and global teams. Helix4Git unites multi-repo projects under a single pane of glass for improved security, faster Continuous Integration/Continuous Delivery (CI/CD) performance, and up to 80% faster builds.

For more information on how to scale your Git development and build process, check out 5 Ways to Scale Git for Enterprise DevOps.