git - 由于主服务器中的异常更改，无法推送分支

Question

我在分支上工作，将其命名为mybranch。我不修改master。
我想在origin/feature/mybranch上推送更改，但是我有一些问题。奇怪的是我已经做过几次了，而且没有任何问题。

$ git branch
develop
* feature/mybranch
master


$ git push
To http://......
! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'http://....'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you did not intend to push that branch, you may want to
hint: specify branches to push or set the 'push.default' configuration variable
hint: to 'simple', 'current' or 'upstream' to push only the current branch.

什么？主？!因此，让我们检查 master。

$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
 (use "git pull" to update your local branch)


$ git pull
Updating 45c7319..f6b8e97
error: Your local changes to the following files would be overwritten by merge:
    platform/....java
    services/....java
    ...

Please, commit your changes or stash them before you can merge.
Aborting

这显示了7个修改后的文件。

$ git status
# On branch master
# Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

#   (use "git pull" to update your local branch)
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   platform/....java
#       modified:   algorithms/....java
#       ...
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       algorithms/.../
#       and over 1100 files in bin folder. I don't know why gitignore doesn't work now.

这显示了17个(不是上面的7个)修改文件。奇怪...没关系。这些不是我的更改，我想放弃它们。

$ git checkout -f
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

而且我在 master中仍然有这些奇怪的变化...

Answer 1

第1部分:完成推送而无需担心master
(注意:实际上，它已经完成了。请参阅第1部分底部的注释。)

您正在运行的git push没有其他参数。

如果您使用另外两个参数运行git push，则它们将确切指定要推送到哪里。 git文档将它们称为<repository>和<refspec>。

在您的情况下，存储库始终为origin(这是您克隆某些内容时git设置的通常标准)。因此，refspec是更有趣的部分。

这是long1形式:

git push origin feature/mybranch:feature/mybranch

这将git限制为仅尝试推送分支 feature/mybranch，告诉远程 origin，它也应该在其一侧更新分支 feature/mybranch。

如果省略了 :<same-name>部分，则默认为使用冒号左侧的分支名称，因此:

git push origin feature/mybranch

执行完全相同的操作，只是命令键入少了一点。

现在，当您删除 <refspec>时会发生什么？答案在 git push和 git config文档中，尽管在我的1.8.4.3文本版本中确实很难阅读，而且我上面链接的在线版本如果有的话，更糟糕::-)

当命令行未指定使用<refspec>推送的内容时...
参数或--all，--mirror，--tags选项，该命令将找到
通过咨询remote。*。push配置(如果有)来进行默认设置
找不到，使用push.default配置决定要推送的内容
(有关push.default的含义，请参见gitlink:git-config [1])。

为简化起见，我可以告诉2您没有设置 remote.origin.push或 push.default，所以您得到的是“默认默认值”，称为 matching，这意味着您的 git push在隐喻的互联网电话上调用 origin并说

嘿，您获得了哪些分支？

它说:

我有 master和 feature/mybranch。

因此，您的git然后说:

好的，这是我认为 master应该是的，这也是我认为 feature/mybranch应该是的。

他说:

哇，伙计，这会使 master退了几转!

...那就是当你得到 ! [rejected] master -> master (non-fast-forward)的时候。

因此，有几个非常简单的解决方案。

解决方案＃0:不执行任何操作

如果仍然有原始的 push输出可用，则应该可以看到类似以下内容:

   a430f6d..676699a  feature/mybranch -> feature/mybranch
 ! [rejected]        master -> master (non-fast-forward)

这意味着即使 master -> master的更改被拒绝，但 feature/mybranch -> feature/mybranch的更改也被接受。您想推送的分支，您做到了!您刚刚收到了这个令人讨厌的错误消息，它伴随着成功(现在您想知道如何处理分支 master)。

解决方案＃1:在 push中明确

如果您运行:

git push origin feature/mybranch

您的Git和来源的Git会进行较短的对话。而不是您的Git问他“嘿，whaddaya到那里了吗？”然后尝试推送所有“匹配”的分支，您的分支只会说:“我对 feature/mybranch进行了一些更新”。您在 master上落后的事实将是无关紧要的。您，您的Git和远程Git都不会出现在那里。

解决方案2:更改您的 push.default
这仅在您的git足够新的情况下才有效，尽管到目前为止，大多数是:

git config --global push.default simple

Git的人们正计划将更改(从Git 2.0版开始)更改为“默认默认值”，因为 matching经常会比帮助有用多烦人。新的“默认默认值”将为 simple。 (有关这意味着什么的详细信息，请参见 the git config documentation。)

(设置 --global版本将更改您的默认默认设置，但不会更改其他用户的默认默认设置。如果任何存储库(您自己的存储库或其他存储库)具有本地 push.default设置，它将覆盖您的个人全局设置，而对于那些没有的存储库，您的全局设置就是git会使用的设置。您可以选择改为在每个存储库中设置本地设置，这会影响您以及使用您自己的存储库的其他任何人，但是您需要记住在所有存储库中进行设置)

1实际上，这只是半长格式:您可以在每个分支名称的前面添加 refs/heads/以使其更长。那只是为了炫耀。 :-)

2我只是在猜测，真的，但这是一个非常安全的选择。配置 remote.origin.push和 push.default的人可能已经知道所有这些内容。

第2部分: master为什么不更新？

我对此不太确定，但是似乎有人不小心将一堆(17) .java二进制文件提交给 master分支，可能是由于没有正确的 .gitignore造成的。

在某些时候，他们注意到了，哎呀，不需要所有这些二进制文件!因此，他们更新了 .gitignore并提交了该文件，但实际上可能并没有全部对它们进行 git rm --cached，因此仍在跟踪中。如果以前提交了现在被列为“忽略”的文件，则git“遵循该提交”而不是“ignore”指令，您会得到很多:

# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   bin/b1

根据 git add的方式以及 .gitignore中的内容，可以添加存储库中跟踪的文件(覆盖了ignore条目)，并使它们“已暂存以提交”并提交它们。

无论如何，您的 master落后两个版本，并且肯定包含一些二进制文件，并且您的 feature/mybranch分支可能包含“错误”的 .gitignore(它的某些变化形式)，并且它也不会忽略二进制文件的“正确集合” 。

Git注意到您的7个二进制文件(可能是使用feature分支功能重建的)与 master分支上签入的内容不匹配。这些将被“不安全地”破坏(至少，就git所知)。如果/当您执行 git checkout -f master(或类似的操作)时，git毕竟会破坏它们，但是您仍然留下“未跟踪”的文件，这意味着 .gitignore不好。

一旦确定可以安全地删除工作树中的所有内容(所有工作都被保存了)，就可以将 master重新同步到 origin/master了:

git checkout -f master
git fetch   # resync with origin in case they've fixed more stuff
git reset --hard origin/master

假设您不想在分支中使用二进制文件，请检查各种 .gitignore文件并确保它们正确无误-您可能需要修复一些文件。然后，使用 git ls-files和/或 git ls-tree查看索引和存储库中的内容( git ls-tree要求您指定特定的树对象，例如 git ls-tree HEAD:bin，以查看 bin树中的内容(如果存在)。

删除已提交(即使被忽略)的文件，例如，删除 bin中的所有内容:

git rm --cached -r bin

( --cached说仅删除索引中的内容)，或者您可以允许git删除二进制文件。一旦您拥有正确的东西“git rm” -ed并添加了任何更新的 .gitignore文件，就用 git commit进行更改:

$ cat bin/.gitignore
*
!.gitignore
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   bin/.gitignore
#   deleted:    bin/b1
#   deleted:    bin/b2
#
$ git commit -m 'remove binaries, ignore them in the future'
[master ac60888] remove binaries, ignore them in the future
 3 files changed, 1 insertion(+)
 create mode 100644 bin/.gitignore
 delete mode 100644 bin/b1
 delete mode 100644 bin/b2

(最后，根据需要重建所有删除的二进制文件，运行测试，在适当的情况下执行推送等)。

(很可能您确实希望在分支中使用 .java二进制文件，或者您不想这样做，但是还没有人修复任何 .gitignore条目，等等；所以这就是为什么我对此不太确定的原因。)