假设我有两个分支 - master 和 feature。 feature 被推送到原点，多个开发人员正在处理。所有开发人员都完成了他们的工作，提交并推送到共享分支。我将所有更改提取到我的本地 feature checkout 中，因此它是最新的。
我运行 git merge-base master feature，它给了我 433c4d34e86c3997ffc0ab1b42bb27acce09b2a6。
我只想做一次提交，所以我运行 git rebase -i 433c4d34e86c3997ffc0ab1b42bb27acce09b2a6。对于第一次提交，我使用 reword，其余的我使用 fixup。 rebase 完成，正如预期的那样，它告诉我我的分支和 origin/feature 已经分歧。 我不勉强。
我 git checkout master 然后是 git pull 最后是 git rebase master feature。最后，我再次 git checkout master 然后 git merge feature。
git status 现在告诉我:
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)
此时，推送到原点是否安全？请记住，功能分支将被删除并且不再使用，因此我们不担心其他开发人员从这个角度重写他们的历史。
或者我在这里遗漏了其他关于为什么这不好的东西？也许是一种更好的方法？
最佳答案
我认为这里有两点混淆。
首先，听起来您很关心永远不要对已推送的分支进行 rebase 的一般建议，但您不确定您是否理解该建议的原因。
其他开发人员必须清理其分支副本状态的可能性是制定此准则的原因；因此，更好的建议形式是，如果你想对已推送/与他人共享的分支进行 rebase ，你需要得到拥有该分支副本的每个人的同意。
如果每个人都同意他们不再在 feature 上做任何工作，并且在 feature 上完成的所有工作都已经推送，并且他们只是要删除 feature ；那么通过 rebase feature 就不会为任何人创建额外的工作，并且没有人会对此有任何问题。
但即使这样也没关系，因为您已经描述了您准备好推送 master 的情况。以上仅适用于您要推送 feature ... 如果它只是一个您要删除的分支，您为什么要这样做？如果有的话，你会在本地删除 feature 并推送删除。
所以我假设您认为分支与分支现在可以到达或过去可以到达的提交之间存在某种内部关系。没有。您要推送到 master 的提交来自 feature 的 rebase 这一事实对 git 没有任何意义。它仍然只是 master 上的新提交。
(这引起了对另一点的注意:您通过交互式 rebase 走了很长的路。也许意图是操纵默认提交消息或其他东西？但是如果您想应用 feature 中的所有更改一次提交到 master ，最简单的事情是
git checkout master
git merge --squash feature
这就像您的过程一样，有时会引起头痛，但如果您无论如何都打算丢弃 feature，通常没问题。)
关于git - 如果我要删除共享分支，是否可以 rebase ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48745140/