如何在多次推送后，重新设置Git历史记录的基准点并推送更新后的历史记录？

Question

如何在多次推送后，重新设置Git历史记录的基准点并推送更新后的历史记录？

githerokugit-rebasegit-commit

3

我经常使用Heroku，项目接近尾声时，我需要提交几个小的修复bug的commit。这会导致10个小的diff commits，我希望将它们合并成一个。问题在于，这些历史记录已经被推送了。我该如何解决这些问题？

- dougvk

这些提交是其他人正在获取/拉取的吗？换句话说，它是一个共享存储库，还是只有您自己使用的部署？ - wadesworld

根据下面两个答案，@wadesworld，即使这不是一个共享存储库，这也是一个坏主意。这是一个不好的习惯，如果我发现自己认为需要这样做，我会质疑导致我得出这个结论的前提。 - tjarratt

有趣。我的问题不常见吗？人们是不是只能忍受多次提交？ - dougvk

@dougvk 是的，人们通常只保留多个提交。在部署后推送多个修复通常都很有趣。rebase 的主要用例是在你推送之前重写历史记录，比如当你正在开发一个功能时。 - tjarratt

4个回答

5

如果您真的想推送一个被变基的分支（Git默认会拒绝），您可以使用以下命令：

git push --force heroku master

请注意，一般来说，这是一个非常糟糕的想法，因为其他人已经提到的原因。

- dhwthompson

2

在你push后不应该修改（变基）历史记录。如果其他人从远程库拉取代码，而你进行了变基并且推送，那么你将会遇到非常糟糕的合并冲突。

- tjarratt

1

这并不是太糟糕，但如果你与单个代码库中的其他人合作，会变得更加困难。 - tjarratt

0

从git-rebase手册中：重新设置基于其他人工作的分支（或任何其他形式的重写）是一个坏主意。下游的任何人都被迫手动修复他们的历史记录。因此通常情况下，在推送任何内容之后不要进行Rebase操作。

- Mariusz Sakowski

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Norman Richards · Accepted Answer

你想做的事情并不像人们所说的那样糟糕。确实，你不想将更改推送到共享主分支进行变基，但是将更改发送到非共享/工作分支或非共享存储库进行变基是非常常见的。许多人认为这比用毫无意义（可能不完整/不可行）的提交来混乱项目历史记录要好得多。

要问自己的问题是“是否有人会从我正在推送的分支中拉取”。如果答案是否定的，那么这样做的问题只是理论上的，并且远远超过了杂乱的历史记录的问题。如果答案是肯定的，那么当然你不想这样做。但是，在这种情况下，你应该问自己是否可以从该存储库的非共享分支部署。创建一个正在进行测试的工作进展分支，自由地提交和变基。当你完成工作时，随心所欲地进行变基，然后将好的提交推送到共享分支。