你可以看到网络上的所有人都建议不要在公共分支中使用git rebase，但是如果你总是要修改一个功能分支，我就看不出有什么问题。
我的团队总是使用分支功能（哇），我们习惯只在本地使用它，所以rebase不是问题，但有时我们想向其他开发人员展示部分完成功能的代码，所以我们只是宣传它，但后来我们失去了git rebase的所有优点，或者至少是你在网上可以阅读的内容。
我不明白是什么问题，如果在同一个公共分支工作的开发人员从未将它合并到任何分支（当该分支上仍有开发时），并且当他们拉动它时，他们使用rebase操作。对分支所做的任何更改都将始终在远程分支的顶部进行rebase，因此永远不会丢失，并且您不会遇到重复相同提交的问题。
直到现在，没有一个答案显示会发生的问题及其发生的方式，所以我会尽量让自己更清楚。
我将举例说明使用rebase的工作流程（在前面的段落中描述得很糟糕，抱歉）我没有看到任何问题。
初始状态：
master ==========A
origin/feature +=====AB
feature user A +=====AB
feature user B +=====AB
master获得一些提交，用户A做了一些提交：
master ==========A=====C
origin/feature +=====AB
feature user A +=====AB====D
feature user B +=====AB
用户A执行git pull --rebase（他总是这样做）来更新他的分支，没有新的东西，然后他重新掌握并推送：
master ==========A=====C
origin/feature +=====ACB'=====ACB'D
feature user A +=====ACB'=====ACB'D
feature user B +=====AB
（注意B'是仍然代表变化B的新提交）
然后用户B做了一些提交：
master ==========A=====C
origin/feature +=====ACB'=====ACB'D
feature user A +=====ACB'=====ACB'D
feature user B +=====AB======E
用户B最后一如既往地执行git pull --rebase，没有必要对master进行rebase，所以他只是推动：
master ==========A=====C
origin/feature +=====ACB'=====ACB'D======E'
feature user A +=====ACB'=====ACB'D
feature user B +=====ACB'=====ACB'D======E'
答案 0 :(得分：32)
如果您改变，则重写历史记录。就像在现实世界中一样，如果你想改写历史，你需要一个阴谋：每个人都必须“参与”这个阴谋（至少每个知道历史的人，即每个曾经从分支机构撤出的人）
只要从分支机构中拉出来的人群受到严格控制，就可以很容易地获得阴谋，但是，只要您发布该历史记录，就会变成批次更难。但这并非不可能：例如，Junio C Hamano的Git存储库中的pu分支在每次发布后都会被重新定位，这是一个广泛发布的存储库。这种方法的工作方式是，分支机构经常被重新定位，以及发生这种情况的时间，在Git网站，Git wiki和Git邮件列表中广泛记录，并且每个rebase都会在邮件列表中提前公布，所以人们可以为此做好准备。
答案 1 :(得分：6)
当你反对公共分支时，它完全没问题。
但是，当你修改公共分支本身时，对于那些也在使用它的人来说这是不好的。
<强>增加：
当rebase中断单元测试时，您将无法git bisect错误修订。
更多细节：
答案 2 :(得分：2)