假设我有两个分支 - master和feature。 feature被推向原点，多个开发人员正在努力。所有开发人员都完成了他们的工作，提交了它并推送到共享分支。我将所有更改都放入feature的本地结帐中，以便更新。
我运行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)
此时，可以安全地推送到原点吗？请记住，功能分支将被删除，并且永远不会再次使用，所以我们不担心其他开发人员从这个角度重写他们的历史。
或者我在这里错过了其他的东西，为什么这很糟糕？也许是更好的方式完成它？
答案 0 :(得分：3)
我认为这里存在两点混淆。
首先，听起来你一直担心永远不会改变被推动的分支的一般建议，但你不确定你是否理解这个建议的原因。
其他开发人员必须清理其分支副本的状态才是本指南的原因;所以一个更好的建议形式是，如果你想改变一个已经推送/与他人共享的分支，你需要拥有该分支副本的每个人的协议。
如果每个人都同意他们没有在feature上再做任何工作，并且feature已完成的所有工作已经被推动，并且他们只是要删除{{1 }};那么通过重新定位feature没有为任何人创造额外的工作，没有人应该对它有任何问题。
但即便如此也无关紧要，因为你已经描述了你准备推动feature的情况。以上只适用于你要推master ...为什么你会这样做，如果它只是你正在删除的分支？如果有任何问题，您可以在本地删除feature并推送删除。
所以我假设你认为分支与分支现在可以达到或者过去可能达到的提交之间存在一些内部关系。没有。您想要推送到feature的提交来自master的rebase这一事实对git毫无意义。它仍然是feature上的新提交。
（这引起了另一个观点：你通过做一个交互式rebase已经走了很长一段路。也许意图是操纵默认提交消息或者什么？但是如果你想应用来自{{{}的所有更改1}}在master的单个提交中，最简单的是
feature，就像你的程序一样，有时候会引起头痛，但如果你打算放弃master，通常会很好。）