0

I am looking for a simple example on why should we avoid using the rebase command on a branch that has been pushed when there are multiple people working with the project. I have read that it confuses the other developers, but a simple exaple would help me to visualize why this is a problem.

variable
  • 8,262
  • 9
  • 95
  • 215
  • Does this answer your question? [Git workflow and rebase vs merge questions](https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions) – Croolman Jan 27 '20 at 09:14
  • 1
    See the related questions, but note also the rule I like to use here: *Rebasing commits that have been shared with others (e.g., pushed) is OK if and only if all of those Others have agreed in advance to said rebasing.* This applies even when you're the only one using the branch, as you merely have to agree with yourself that rebasing is OK. – torek Jan 27 '20 at 09:47
  • Why is this a duplicate question. Why cant there be a simple answer for a straight-forward question like this? – variable Jan 27 '20 at 10:15
  • @variable It's not a duplicate. But there is no simple answer because though the question looks like a straightforward one the answer is rather complex and requires understanding of git DAG. – phd Jan 27 '20 at 10:57

2 Answers2

1

In short because the rebase changes sha1 ids of commits, its like rewriting the history. Here is an example:

Say, you have master that has commits A1 and A2.

>> git log master
 => A1, A2
>> git checkout -b mybranch 
>>> work..work..work
>> git commit mybranch
>>> work..work..work
>> git commit mybranch
// at this point mybranch contains A1, A2, A3, A4
>> git log mybranch
=> A1, A2, A3,A4


>> git push mybranch origin/mybranch

// now (its critical ! ) other users __checkout__ mybranch on their machines (and get commits A1, A2, A3, A4) of course
//////// 
// a couple of hours/days later ...
// ...meanwhile other people worked on master so now it looks like this:
>> git checkout master
>> git log
=> A1, A2, B1,B2 // commits B1 and B2 are new!!!
// and now let rebase:
>> git checkout mybranch
>> git rebase master
>> git log mybranch
=> A1, A2, B1, B2, A3', A4'

Note at this point A3 went to be A3' (its sha1 has changed), and A4 went to be A4' Now you can forcefully push this history (a new history that rewrote the history with original A3 and A4 commits). git push -- force mybranch

However, what will your colleagues do at this point? If they checkout mybranch by git pull mybranch are they supposed to get both A3 and A3' (the same goes for A4 and A4')?

This is very problematic unless they delete their local copy of mybranch and pull as if has never existed on their local machines.

Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
0

As far as I understand, there shouldn't be any issues with rebasing if you're the only one working on that branch. There can be quite a few complications with rebasing if there is more than one person working in that branch.

There is a simple example near the end of this article that helped me a lot.

jpirzent
  • 25
  • 6