linux - 错误: failed to push some refs to 'git@github.com:/.git'

Question

嗨，我是一个使用git的新手，我读了一些有关此错误的StackOverflow问答，但不明白我的问题与具有相同错误消息的其他人之间的关系。因此，我不敢碰巧，花了6个小时的工作来推进远程GitHub存储库。

。

1.)起始

因此，我在本地工作目录中的代码损坏了，我无法弄清楚问题出在哪里。所以我希望git返回项目的最新工作版本。然后，我找到了本教程，并设法使我的本地项目返回到工作版本。
https://www.git-tower.com/learn/git/faq/restore-repo-to-previous-revision

$ git reset --hard <SHA-1 HASH NUMBERS>

。

2.)尝试推送

这些是我想将本地代码推送到远程存储库时通常遵循的命令。

# Pushing Changes - Staging
$ git diff
$ git status
$ git add -A
$ git status
$ git commit -m "Modified multiply function."

# Pushing Changes - Repository
$ git pull origin master
$ git push origin master

。

3.)错误

我不明白该错误消息试图告诉我什么。有人可以通过显示需要运行哪些命令序列才能再次像往常一样推送代码来帮助我吗？

penguin@linux$ git push origin master

To git@github.com:<name>/<project>.git

 ! [rejected]        master -> master (non-fast-forward) error: failed to push some refs to 'git@github.com:<name>/<project>.git'

hint: Updates were rejected 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.

Answer 1

让我们解决这个较长的注释(我应该在另一条注释中进行此操作，但这根本不适合，因此我要回答一个不同的问题，即“分离和重新连接HEAD的工作原理”):

Tnx torek I managed to force away that error with the link you provided. I also had some detached HEAD issues which I got rid by following Razan Paul's post here Fix a Git detached head? But all my changes while in detached HEAD mode was lost after the fixes. I have copies so I can just recreate them manually I guess. So in the future when I want to go back to the latest working version on my local working directory. What procedure will suite my situation best? I see so many different suggestions I don't know what's best for me

(顺便说一句，当向特别是某人发表评论时，您可能希望使用 @<name>语法，以便使他们收到警报)。

您需要的是一本正确的Git书。我认为最好的免费软件是 Pro Git 2 book。 (这里没有很多其他的免费书，因此“最好”的书可能是虚假的。:-))我觉得有用的一个简短的非书本引用书是 Think Like (a) Git，因为Git是建立在一些非常简单的地方之上的图论—但是除非您知道这一点，并且直到您意识到这一点，否则您将陷入 this xkcd cartoon之中。

(我什至有 my own start on a book，但是最近这些时间很少用。)

您可以在Git中使用许多工作流程。不过，首先要记住的是，Git的“存储单元”(即拼命试图保护的东西，以便您可以将其取回)是提交。这就是为什么您在推送时遇到麻烦:您正在告诉其他Git:丢弃一些提交。 Git不想这样做。

提交由其哈希ID唯一标识。这些哈希ID对人类不是很有用，因此Git为我们提供了诸如分支名称之类的东西来记住特定的ID，但是在某些情况下，您可能不得不求助于原始ID，例如，您可以使用鼠标剪切和粘贴原始ID。

Git希望保持提交状态，这意味着当您使用独立的HEAD进行提交时，Git也会尝试保持提交状态。默认情况下，它将至少持续30天。您可以使用 git reflog查找哈希ID。如果您使用 git reset --hard使Git“忘记”分支(而不是分离的HEAD)上的提交，则Git还将这些ID至少保留30天，保留在分支名称的reflog上。每个分支名称都有一个reflog，而 HEAD本身有一个。

最后，一个附加的HEAD(即与detached相反的连接)在您在时，就像 git status会说的那样，在某个特定分支上:

$ git status
On branch master
...

在这种情况下，分支名称 master是Git实际如何标识您现在已 checkout 的提交的方式。并且名称 HEAD只是附加到名称 master。

为了使这一切正常， Git向后工作。

图的简要介绍

要真正理解所有这些含义，您需要绘制提交图。请记住，每个提交都有其自己的唯一哈希ID-那些丑陋的，长40个字符的十六进制数字字符串，例如 5be1f00a9a701532232f57958efab4be8c959a29-但这有点不可靠，因此您可能只想在单个小图形中使用单个字母:

A <-B <-C   <--master

这是一个非常新的存储库，其中只有三个提交。我们首先制作 A，然后制作 B，然后制作 C。 (当我们到达第27次提交时，我们将失去所有提交的名称，因此您可以看到Git为什么使用更长的哈希ID的原因。)

由于Git向后工作，因此名称 master标识而不是commit A，而是commit C。我们说名称 master指向 C。

作为我们的第三次提交，commit C在其内部具有第二次提交即commit B的名称(哈希ID)。我们说 C的父提交是 B。因此，将 C指向 B即可。同样， B内部具有提交 A的哈希ID，因此 B指向 A。

提交 A是第一次提交。它不能指向上一次提交，所以事实并非如此。这使提交 A变得特别:这是一个根提交。每个非空存储库至少有一个，这是有史以来的第一次提交。

当您运行 git log时，Git将以您当前的提交开始-在此处提交 C，然后向后工作:它向您显示 C，然后由于 C指向 B，因此Git也将显示 B。由于 B指向 A，因此Git也显示 A；但是 A是根提交，因此Git可以停止。

分支如何成长

由于我们使用的是 master，因此让我们重新提交 D。我们将对源 git add文件进行任何操作，然后运行 git commit创建 D。
D指向哪里？好吧，显然它必须指向 C。因此，Git使 D具有 C的父提交:

A <-B <-C <-D

Git的最后一步是更改名称 master，使其拥有commit D的哈希ID，为我们提供了这张图片:

A <-B <-C <-D   <--master

请注意，所有箭头都必须指向后。而且，所有提交中的箭头都会一直冻结: D指向 C，永远不会指向其他地方。唯一更改的箭头是分支名称中出现的箭头!因此，我倾向于在不使用内部箭头的情况下绘制它们，以节省空间并使其更合适:

A--B--C--D   <-- master

这是理解Git的另一个关键: 分支名称会随着时间而移动。 分支获取新的提交，并且名称指向分支上的最后一个提交-Git称为提示提交。 Git使用该提示提交来查找该分支的下一个较早的提交:提示的父级。 Git使用该提交来查找其先前的提交，依此类推，一直返回到根提交。

名称 HEAD通常仅标识一个分支名称

让我们通过添加来自 C的分支来使上述存储库复杂化:

A--B--C--D   <-- master
       \
        E   <-- develop

在这里，我们现在有两个分支。名称 develop标识提交 E，其父级为 C。如果现在运行:

git checkout master

我们将成为 on branch master，就像 git status会说的那样；如果我们现在创建一个新的提交 F，其父代将是 D。如果我们改为 git checkout develop并创建一个新的提交 F，则其父代将改为 E。所以Git需要知道:我们在哪个分支上？这是我们需要绘制名称 HEAD的地方:

A--B--C--D   <-- master (HEAD)
       \
        E   <-- develop

要么:

A--B--C--D   <-- master
       \
        E   <-- develop (HEAD)

像这样附加 HEAD时，会将其附加到分支名称。当您进行新的提交时，Git将更改分支名称，以使其指向您刚刚进行的新提交。

“分离的HEAD”仅直接保存提交哈希ID

如果您发现自己处于 detached HEAD模式，通常是因为您直接 checkout 了较早的提交。例如，让我们检查commit B，同时保留所有内容:

A--B   <-- HEAD
    \
     C--D   <-- master
      \
       E   <-- develop

我不得不弯曲图形线以适合 HEAD，但是现在 HEAD指向直接提交 B。

如果我们现在进行一个新的提交 F，它的父节点将是 B，而Git将 HEAD直接指向 F:

A--B--F   <-- HEAD
    \
     C--D   <-- master
      \
       E   <-- develop

请注意，每当Git创建一个新的提交时， HEAD指向的提交(如果是分离的，则是直接的；如果附加到分支名称，则是间接的)也将改变!新提交的父节点始终是刚才的 HEAD，现在 HEAD是新提交，这又是当前提交。

(这也是为什么 parent 不知道 child 的哈希ID，但是 child 确实知道其自己 parent 的ID的原因。Git必须向后工作，因为 child 知道他们的 parent :创建 child 时，父提交存在；但是父提交(它们是只读的，并且会及时冻结)，不知道他们将来会获得什么样的 child 。)

但是，一旦我们重新附加 HEAD，我们就会“丢失”提交F的ID:

A--B--F   <-- ???
    \
     C--D   <-- master (HEAD)
      \
       E   <-- develop

谁记得 F的ID？答案是:只有引用。

如果您想继续提交 F，则应该在您的引用日志中找到它的ID并为其附加一个名称-分支或标记名称，通常是:

A--B--F   <-- newbranch
    \
     C--D   <-- master (HEAD)
      \
       E   <-- develop

现在 newbranch会记住 F的ID。如果您有两个提交， F和 G，而您有一个分离的HEAD，则必须以某种方式找到后面的一个，并确保您的名称指向 G，这样您就可以:

        G   <-- newbranch
       /
A--B--F
    \
     C--D   <-- master (HEAD)
      \
       E   <-- develop

并不是:

        G   <-- ???
       /
A--B--F   <-- newbranch
    \
     C--D   <-- master (HEAD)
      \
       E   <-- develop

这就是为什么在分离的HEAD上进行大量提交的想法不是一个好主意:从哈希ID很难分辨哪个提交是最尖端的。