阅读git工作流程，我想知道历史重写的适当性。我的工作流程，我想象其他许多工作流程，是：
当我得到反馈时，似乎我想要做一些变相和压力，因为反馈往往是一些小问题，比如重写评论或者本来应该有所不同的事情，并且不值得他们自己承诺。
但是从文档来看，似乎我不应该在rep2上改变历史记录，事实上像--ammend这样的东西在这种情况下不起作用。我的工作流程是错误的，还是我误解了有关改变历史的警告？
答案 0 :(得分：5)
一般经验法则：从不重写已发布的历史记录。有可能有人已经提交了你的提交;如果你改写历史记录，这些人一旦撤回重写的历史记录就会陷入困境。
不太严格的经验法则：在某些情况下，当您完全确定您是唯一正在处理该历史记录时，可以认为重写已发布的历史记录是可以的。分支。
就个人而言，我认为可以在GitHub存储库的invidivual fork中重写已经推送的功能分支的历史记录，因为我不希望其他任何人在该分支上工作。不过，这只是个人意见。
答案 1 :(得分：2)
关于rebase的规则是这样的：你应该只改变你的本地分支一旦分支是一个公共分支，任何人都可以抓住它，你不应该再次在这个分支上重新绑定，或者你可以破坏已经克隆过这个分支的所有其他回购。
如果由于某种原因您决定rebase公开（推送分支），您必须确保所有撤消此分支的用户都知道您的rebase。
你可以使用git pre-rebase hook来检查它以拒绝rebase或在这种情况下显示警告或错误