Question

我正在寻找一个简单的示例，说明当有多个人在处理项目时，为什么应该避免在已推送的分支上使用rebase命令。我已经读过它使其他开发人员感到困惑，但是一个简单的示例可以帮助我直观地了解为什么这是一个问题。

Answer 1

简而言之，因为重新设置会更改sha1的提交ID，就像重写历史一样。这是一个示例：

说，您的主服务器具有提交A1和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'

请注意，此时A3变为A3'（其sha1已更改），而A4变为A4' 现在，您可以强制推送此历史记录（一个新的历史记录，该历史记录使用原始的A3和A4提交重写了该历史记录）。 git push -- force mybranch

但是，您的同事此时会做什么？如果他们用mybranch结帐git pull mybranch，是否应该同时获得A3和A3'（A4和A4'也是一样）？

除非他们删除mybranch的本地副本并像在其本地计算机上不存在一样进行拉动，否则这是非常有问题的。

Answer 2

据我了解，如果您是该分支机构中唯一的员工，那么重新定级应该不会有任何问题。如果该分支中有多个人员在工作，那么重新定基可能会带来很多麻烦。

this文章结尾处有一个简单的例子，对我有很大帮助。

为什么我们要避免在已推送的分支上使用rebase命令？

2 个答案: