Question

我将存储库克隆到本地计算机。然后，我使用master（从当前git checkout -b dev/abc/test1）创建了一个新分支。我是该分支机构中唯一的工作人员。我在该分支上工作了几个小时，然后进行提交并进行了git push并创建了请求请求。审阅者对此请求请求发表了一些评论。

在开始处理这些评论之前，我做了git checkout master，然后git pull更新了master分支。后来，我想将这些更改（自从我上次更新以来，master中有很多更改）合并到我的分支dev/abc/test1中。

因此，我做了git checkout dev/abc/test1。然后我先做git reset --hard origin/master，然后再做git merge origin/master。因此，我对该分支所做的所有更改均按预期丢失。我手动复制粘贴了我从拉取请求中所做的更改。现在，我开始处理那些审阅者的评论，并修复了所有评论，先进行了git commit和git push的操作，但只是看到了消息

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

为避免这种情况，我继续使用git push --force。

这会产生负面影响吗？我在其中 Cannot push to GitHub - keeps saying need merge 看到其中的一条评论'forcing' is most of the time, if not always, the wrong answer。我的方法会对存储库产生任何负面影响吗？（请注意，我是分支dev/abc/test1的唯一个人贡献者）

Answer 1

在这种情况下，您将重写dev/abc/test1分支的历史记录。只要没有其他人正在使用此分支，那就应该可以。

我建议使用以下工作流程，这意味着您下次无需强制执行推送。

git checkout --branch dev/abc/test1
git checkout master
git pull
git checkout dev/abc/test1
git merge master
## Resolve merge conflicts
git commit
git push

这将具有相同的结果，而不会重写历史记录。

Answer 2

如果您正在GitHub拉取请求审核过程中，则可以使用强制推送。这样做将自动更新您的拉取请求，并且GitHub将检测到更改了。

审查流程的另一个常见工作流程是仅 add 提交可解决反馈的提交。因此，您可以直接推动它们（无需用力）。最后，通常由负责合并的人员来压缩这些提交，以使最初的PR之上的各个修订不会单独出现。

通常不赞成强制推送，因为它通常意味着您正在重写历史记录（重新编制的内容）。发布重写的历史记录是与所有团队成员打交道的一种很好的方法，因此您应该不惜一切代价避免这种情况。但是，拉动请求始终被认为处于不稳定状态（通常需要重新调整基础以匹配基础分支上正在进行的开发），因此人们不太可能期望其具有一致的历史记录。

Answer 3

完成git push --force后，您将强制覆盖远程dev/abc/test1分支。这意味着以前的远程分支可能会永久删除。在这种情况下，应该没有副作用，因为您是使用分支的唯一人。强制推送通常不好的原因是，通常，远程分支一次由多个开发人员共享。重写远程分支的历史记录时，可能会给共享该分支的其他任何人造成破坏。另一个人去git pull时，他们会看到一个新的历史记录。

请注意，也许具有讽刺意味的是，您要做的最好的事情就是用远程分支替换dev/abc/test1的本地副本。因此，您可以通过以下方式对master跟踪分支进行硬重置，而不是进行硬重置：

dev/abc/test1

这将撤消您在本地所做的所有操作，这可能会提示您重置为git reset --hard origin/dev/abc/test1。

关于git force push

3 个答案: