您可以看到网络上的所有人都建议不要在公共分支中使用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'
如果你改变，你重写历史。就像在现实世界中一样，如果你想改写历史，你需要一个阴谋：每个人都必须“参与”这个阴谋（至少每个知道历史的人，即每个曾经从分支机构撤出的人） 。
只要从分支机构中拉出来的人群受到严格控制，就可以很容易地获得阴谋，但是，一旦你发布了这段历史，就会变得更加困难。但这并非不可能：例如，Junio C Hamano的Git存储库中的pu分支在每次发布后都会被重新定位，这是一个广泛发布的存储库。这种方法的工作方式是，分支机构经常被重新定位，以及发生这种情况的时间，在Git网站，Git wiki和Git邮件列表中广泛记录，并且每个rebase都会在邮件列表中提前公布，所以人们可以为此做好准备。
当你反对公共分支时，这是完全可以的。
但是当你改变公共分支本身时，对那些也在使用它的人来说并不好。
加成：
当rebase打破单位测试时，你将没有机会git bisect错误的修订。
更多细节：