4

A few people at work swear by git pull --rebase. In fact, they won't git pull without it, even when several people are working on a shared branch.

It is my understanding that this rewrites history. In fact, I have seen it said that one should never rebase on a public/shared branch.

My question:

  • What is a concrete example of the way rebasing "rewrites history"?
  • What are some concrete examples of Bad Things that could occur if you violate the "Golden Rule of Rebasing"?

Possible difference with suggested dupe:

I'm not talking about rebasing master into a feature branch. I am talking about several developers working on the same feature branch, doing a git pull --rebase, making some changes, pushing (doing another pull --rebase if the push is rejected), etc.

Two-Bit Alchemist
  • 17,966
  • 6
  • 47
  • 82
  • Possible duplicate of [git workflow and rebase vs merge questions](http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions) – Ewan Mellor Apr 21 '16 at 18:54

2 Answers2

3

We use this in our workflows.

If you only use it on short-lived branches it's relatively safe. You're replaying your local commits (rewriting that history) on top of the pushed commits of your coworkers.

If you're rebasing the entire collaboration branch it is in your best interests to carefully coordinate with your coworkers. Otherwise it's easy for someone to lose work. With pull -r, it's pretty hard.

TrueWill
  • 25,132
  • 10
  • 101
  • 150
  • I edited my question to make it a little more clear that I'm talking about multiple devs working on the same feature branch, not just (say) merging master into a feature branch which is shared. Does the new workflow I'm suggesting sound problematic? If so, why? If not, why not? – Two-Bit Alchemist Apr 21 '16 at 18:57
  • @Two-BitAlchemist That's exactly what our team does (multiple developers doing `pull --rebase` on feature branches). The only time it's painful is when you have to resolve merge conflicts (such as when two people edited the same source line). – TrueWill Apr 21 '16 at 19:01
1

We use this in our workflows.

As long as you only rebase your un-pushed changes, you're only rewriting your own history and that's fine.

As I see it:

  • Advantage of rebase - History is much clearer because it is linear. The more developers you have working on a branch, the more visible this will be.
  • Disadvantage of rebase - There is no tracking of conflict resolution. Suppose you have everything working. Then you fetch and merge and there are merge conflicts. You resolve them incorrectly and push your changes. When the CI system detects an error, you can track it down to improper conflict resolution (or perhaps improper testing after conflict resolution) rather than improper initial coding/testing. If fetch and then rebase, the conflict resolution is lost, embedded in one or more of your commits.

I'm sure people have lots of other reasons for or against one side or another, but to me it comes down to these two as the most important.

Note to anybody who's about to yell and scream that I miss some point completely. I am addressing the micro "developers doing their day to day commits and feature work"-level of workflow for rebases vs merges. I'm not addressing this from a macro "how to handle whole large branches"-level workflow. I believe the micro is what the OP is asking about.

Mort
  • 3,379
  • 1
  • 25
  • 40