Git - Merge vs. Rebase

Commit History: Accuracy vs. Clarity

After experiencing both merging and rebasing in action, we may be wondering which is preferable.

But let's consider why commit history matters before making a decision.

The Preservers of History:

According to one perspective.

• Our commit history is an accurate account of what occurred.

• Similar to a historical record, it is significant for its accuracy and should not to be altered.

• From this perspective, altering history amounts to rewriting the past.

  Messy merge commits are a fact of life and should remain.

Another perspective.

• Our commit history as a story of our project's development.

• We wouldn't release a rough draft, so why display messy work?

• It's critical to record errors and dead ends during development.

• However, a brief story that follows our work from beginning to end has greater effect when shared.

• Before their commits are merged into the main branch, members of this group rework them using tools like rebase and filter-branch.

• They convey the story in a style that will be most appropriate for readers in the future, thereby managing the development story.

• This method makes sure that the history is clear and linear, which facilitates understanding of the project's development by others.

The question arises: Should we merge or rebase?

There's no straightforward answer.

There are many ways to change history using Git, but each team and project is special.

With knowledge of both approaches, we can make a smart choice.

Conclusion

Of course, we can utilize both! Before pushing, use rebase to clean up our local work.

However, do not rebase anything that has already been shared with others.