Question

我只是有一个有趣的git体验。我作为我的分支机构my-branch上唯一的开发人员工作，我最近从我的队友的分支机构分支：her-branch。我已经成功地将几个提交推送到我的分支机构。但是当我去推动我的最后一个分支时，发生了以下情况：

$ git push
To git@url/repo.git
 ! [rejected]      her-branch -> her-branch (non-fast-forward)
error: failed to push some refs to 'git@url/repo.git'
hint: Updates were rejecetd because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes.
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

我觉得很奇怪，即使我向my-branch推送消息说因为her-branch而失败了。我不知道出了什么问题，但我按照消息建议拉了一下：

$ git pull
Already up-to-date.

我想确认我在我的分店......

$ git checkout my-branch
Already on 'my-branch'
Your branch is up-to-date with 'origin/my-branch'.

所以最后我强迫推动。

$ git push -f
Total 0 (delta 0), reused 0 (delta 0)
To git@url/repo.git
+ 9b3232c..d35fe86 her-branch -> her-branch (forced update)

这成功推送my-branch并更新了遥控器。但它发送了her-branch及时，我所有的队友的提交，因为我从她的分支被删除。她的历史完全从遥远的地方消失了。

幸运的是，她没有拉，并且能够强行推动她的分支恢复她的代码的最新版本，但我很困惑。

你能解释一下这里发生了什么吗？

Answer 1

听起来您的git config push.default设置为matching。这曾经是默认行为，但是您遇到的可能不是大多数git工作流所需的。您可以通过运行git config --get push.default

来检查当前设置

请参阅https://git-scm.com/docs/git-config

push.default

定义git push在没有refspec的情况下应该采取的操作   明确给出。不同的值非常适合特定的   工作流程;例如，在纯粹的中心工作流程中（即获取   source等于推送目的地），上游可能是什么   你要。可能的值有：

没有 - 除非refspec是，否则不要推送任何内容（错误输出）   明确给出。这主要是针对想要避免的人   总是明确的错误。

当前 - 推送当前分支以使用相同的更新分支   接收端的名称。适用于中央和非中央   工作流程。

上游 - 将当前分支推回到其更改的分支   通常集成到当前分支（称为   @{上游}）。这种模式只有在你推动时才有意义   您通常会从中获取相同的存储库（即中央工作流程）。

简单 - 在集中式工作流程中，像上游一样添加工作   如果上游分支的名称不同，则拒绝推送的安全性   来自当地的。

当推到与遥控器不同的遥控器时   通常来自，作为当前工作。这是最安全的选择   适合初学者。

此模式已成为Git 2.0中的默认模式。

匹配 - 推送两端具有相同名称的所有分支。这个   使您正在推动的存储库记住分支集   这将被推出（例如，如果你总是推动maint和master   那里没有其他分支，你推送的存储库将有   这两个分支，你的当地maint和master将被推动   有）。

要有效地使用此模式，您必须确保所有分支   在推出git push之前你会推出准备推出的，   因为这种模式的重点是允许你推动所有的   分店一气呵成。如果你通常只在一个分支上完成工作   推出结果，而其他分支未完成，这种模式是   不适合你。此模式也不适合推入共享   中央存储库，因为其他人可能会在那里添加新的分支，或   更新您控制之外的现有分支的提示。

这曾经是默认设置，但不是自Git 2.0以来（简单就是新版本）   默认值）。

Answer 2

git pull只是一个建议，在你的情况下无法解决问题，因为her_branch不是my_branch的上游。它只是用自己的上游更新my_branch。相反，您应该运行git pull --rebase <remote> her_branch。 <remote>可以是origin或引用her_branch所属的远程仓库网址的正确远程。

此外，-f中的选项git push是您在推送到远程仓库中的已发布分支时应始终避免的。

另一个建议是始终使用完整的命令，例如git push origin HEAD:her_branch而不是git push，git pull origin her_branch而不是git pull，除非您确切知道在{{1}之后会发生什么}或git push。

Git Time Travel

2 个答案: