在pull-request中添加提交

Question

让我们假设我在git中从master分支了一个功能分支。现在我对这个分支进行了一些更改，我认为它已经为master分支做好了准备。所以我推送到远程存储库并使用github UI从我的功能分支向主分支发出拉取请求。

现在，由于pull请求中的反馈，我需要更改功能分支中的一些内容。我现在是将更改作为新提交提交并推送它的简单选项。如果此分支现在稍后合并，我的功能将分为多个提交。

如果我想避免多次提交，有什么可能性？我看到了以下几种可能性：

1. 使用git commit --ammend并将更改附加到当前提交
2. 使用git rebase -i并将更改压缩成一个提交

这两种解决方案都有一个很大的问题：如果没有push -f，我就不能再做了。

问题：

1. 这个工作流程有点错吗？聚合提交是否错误，我应该将它们作为单独的提交保留吗？
2. 如果不是，可以在这里使用push -f吗？
3. 如果是，我怎样才能确保我不做任何非常糟糕的事情？我能以某种方式将效果仅限制到我的远程分支而不会影响其他任何东西吗？摧毁我自己的功能分支并不是那么糟糕，但是摧毁主人并不好。
4. 是否有其他可能性避免push -f？

Answer 1

1. 由于它是您的分支，您可以重写历史记录，工作流程是正确的，最终比单独的提交更容易混淆。
2. 1的答案是肯定的git push -f。
3. 在推送之前，您可以观察当地分支的样子。 gitk和git log等工具可以提供帮助。
4. 由于这是您的分支git push -f并不错，但如果您想保留旧分支，则可以随时创建新分支。

Answer 2

1. 可能令人困惑。仅在合并时进行压扁/修改可能比在开发时压缩更好。这应该由合并在公关的人来完成。
2. 当您更改历史记录时，这是必需的：）
3. git push -f <remove> <branch>只强制推动一个分支。
4. 制作一个单独的分支。但这需要一个新的PR，所以它通常是不值得的，除非变化如此之大，你想重新开始讨论。

Answer 3

1. 基本上它是不对的，但如果你确定没有其他人拉过那个分支，你可以自由地重写它的历史。你不应该重写远程拉分支的历史记录，因为这样的操作会导致本地存储库出现问题，这可能会重新引入你重写的历史。
2. 如上所述，只需在推送到遥控器之前重写本地历史记录。
3. 第3点。

Answer 4

如果您的拉取请求未被接受，并且讨论已导致您收到反馈，我会说您的原始拉取请求已被拒绝，如果您是项目，则应准备新请求对拉取请求有一些更严格的要求。

否则，您需要向分支添加新提交，而不是重新定位或修改已经存在的提交，将它们推送到github并让pull请求更新。

通过这种方式，您最终会得到一个至少有两次提交的pull请求：已经讨论过的原始提交，以及提交反馈的提交。

如果项目要求拉取请求仅为一次提交，则必须创建一个新的拉取请求，将所有已更改的压缩压缩为一次提交，并且可能已重新定位到新的当前开发头。