0

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

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

如果我想避免多次提交,有哪些可能性?我看到以下可能性:

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

这两种解决方案都有一个大问题:没有push -f.

问题:

  1. 这个工作流程有什么问题吗?汇总提交是否错误,我应该将它们作为单独的提交简单地保留吗?
  2. 如果没有,可以在这里使用push -f吗?
  3. 如果是,我怎样才能确保我没有做任何非常糟糕的事情?我可以以某种方式将影响仅限于我的远程分支而不影响其他任何东西吗?销毁自己的特性分支还不错,但是销毁master就不好了。
  4. 有没有其他可能避免的push -f
4

4 回答 4

1
  1. 由于它是您的分支,因此您可以重写历史记录并且工作流程是正确的,并且最终比单独的提交更容易混淆。
  2. 1的答案是肯定git push -f的。
  3. 在推送之前,您可以观察本地分支的外观。gitk类似的工具git log可以提供帮助。
  4. 由于这是您的分支git push -f,因此还不错,但是如果您想保持旧分支不变,您可以随时创建一个新分支。
于 2013-06-06T10:00:35.157 回答
0
  1. 基本上是不对的,但是如果你确定没有其他人拉过那个分支,你可以自由地重写它的历史。您不应该重写远程拉取分支的历史记录,因为这样的操作会导致本地存储库出现问题,这可能会重新引入您重写的历史记录。
  2. 如前所述,只需在推送到远程之前重写您的本地历史记录。
  3. 第 3 点。
于 2013-06-06T10:40:34.007 回答
0
  1. 这可能会令人困惑。仅在合并时压缩/修改可能比在开发时压缩更好。这应该由合并 PR 的人来完成。
  2. 更改历史记录时需要它:)
  3. git push -f <remove> <branch>只强制推动一个分支。
  4. 建立一个单独的分支。但这需要一个新的 PR,因此通常不值得这样做,除非更改如此之大以至于您想重新开始讨论。
于 2013-06-06T08:55:54.380 回答
0

如果您的拉取请求未被接受,并且讨论导致您合并反馈,我会说您的原始拉取请求已被拒绝,如果您参与的项目有,您应该准备一个新的拉取请求对拉取请求的一些更严格的要求。

否则,您应该向您的分支添加新的提交,而不是对现有的提交进行变基或修改,将它们推送到 github 并更新拉取请求。

这样,您最终会得到一个至少有两个提交的拉取请求:讨论过的原始提交,以及带有反馈更改的提交。

如果项目要求拉取请求仅是一次提交,则您必须创建一个新的拉取请求,并将所有更改压缩到一次提交中,并且可能重新定位到新的当前开发负责人。

于 2013-06-06T10:58:34.307 回答