如何从 GitHub 仓库找到最新的克隆/获取/拉取？

Question

GitHub是否会将存储库最新拉取/获取/克隆的时间（至少对于具有写入访问权限的用户）公开？当然，这种信息的兴趣在于想要衡量在存储库上执行git push -f操作的安全性，该操作实际上会覆盖最近的几个提交：如果自从要被覆盖的最早提交被推送到GitHub以来没有进行过任何拉取/获取/克隆，则覆盖可能是可以接受的...

也许一个例子可以澄清我的问题。为简单起见，假设只有一个本地分支（master）和一个远程分支（origin/master）。 （也就是说，远程存储库只有一个分支，并且我正在使用唯一的本地分支跟踪它。）

首先考虑一个完全本地的场景：我进行了提交，不久之后意识到这次提交存在问题。在这种情况下，我只需使用git commit --amend ...命令用正确的提交内容覆盖此提交。

现在想象完全相同的场景，唯一的区别是，在注意到提交存在问题之前，我将错误的提交推送到了远程（GitHub）存储库。

如果我是此存储库的唯一用户，则可以像以前一样在本地覆盖提交，然后使用git push -f ...命令来覆盖远程（GitHub）存储库中的错误提交。

但是，如果我不是此存储库的唯一用户，则上述过程存在问题，因为不同的用户可能已经在我将错误的提交推送到远程存储库之后的某个时间从远程（GitHub）存储库克隆或获取了数据。

最小化此可能性的一种方法是检查自从我将错误的提交推送到该存储库以来对远程存储库执行的所有拉取、获取和克隆操作的记录。如果此记录显示其中至少有一个这样的操作，则表示我们恰好遇到了上一段中描述的问题场景。

另一方面，如果记录未显示任何此类操作，则仍然有希望在不遇到前面描述的问题场景的情况下覆盖远程存储库中的错误提交。（当然，这是一种竞争条件，因此不能保证100％。）

然而，所有这些都是基于是否有这样的拉取、获取和克隆操作记录可用。我的问题是GitHub是否会公开此类记录，至少对于具有写入访问权限的用户。

- kjo

Answer 1

GitHub V3 API提供了一个用户的仓库返回值：

...
    "pushed_at": "2011-01-26T19:06:43Z",
    "created_at": "2011-01-26T19:01:12Z",
    "updated_at": "2011-01-26T19:14:43Z"
  }

"pushed_at"字段可能是最后一次提交的时间，但不一定是您要push --force的分支上的最后一次提交。

然而，关于最新的拉取、获取或克隆，特别是考虑到上游仓库不知道有多少下游仓库正在访问它以及何时访问，没有记录。

请参见““downstream”和“upstream”的定义”。

GitHub可以记录这些信息：它是一个上游仓库，但管理自己的基础设施和访问机制，因此可以记录该访问。
但我不认为这种信息对用户来说是可见的。

- VonC

---

抱歉，我觉得有些误解：我对仓库最新的推送时间不感兴趣。我关心的是从仓库最近一次拉取、获取或克隆的时间。 - kjo

@kjo 然后不：一个上游代码库不知道下游代码库的读取/克隆活动情况。GitHub 不会发布那种日志（如果它一开始就有的话）。 - VonC

关于你的回答：我认为你把“上游仓库”和GitHub混淆了。当然，git没有任何记录谁从中拉取/获取/克隆的功能，但是网站GitHub肯定会跟踪所有访问其页面的情况，并且可以轻松地跟踪我所询问的信息。我的问题是它是否这样做，并且是否提供此信息。 - kjo

@kjo 我的回答是：据我所知，GitHub没有提供这样的记录。我已经编辑了我的回答以反映这一点。 - VonC

Answer 2

因为在您的问题中，您发布了真正的意图：

..想要衡量执行 git push -f 的安全性...

我认为改变您的工作流程会让生活更轻松。我建议按照以下步骤进行：

不要直接提交非微不足道的更改到 master 分支（基本上是您可能想要稍后更改的任何内容）。一旦更改已经落地到 master 分支，它就永远不应该被修改。这里有一个例子：

# assuming starting on master branch
git checkout -b new_cool_idea
# commit a few things
git push origin new_cool_idea
# realize there was a bug preventing you from finishing the
# implementation of new_cool_idea
git checkout -b cool_idea_bug_fix master
# commit the bug fix
# if you have any reviewers, push to remote
git push origin cool_idea_bug_fix
# when bug fix is all good, cleanup and finish new_cool_idea
git checkout master
git merge cool_idea_bug_fix
git branch -d cool_idea_bug_fix
git push origin :cool_idea_bug_fix
git checkout new_cool_idea
git rebase master
# may possibly have conflicts, go ahead and resolve
# now finish implementing new_cool_idea
# if you only want to update one remote branch add <remote> <branch>
# otherwise all remotes will be updated
git push -f <remote> <branch>

这应该有助于避免在 master 上需要执行 --rebase。 这不应该发生。 有一种更高级的技术，您可能想要使用它。 假设修复 bug_fix 分支需要一些时间，但同时您还想继续开发 new_idea 并测试错误修复。 所以我们从以下内容开始：

o-----o-----o             master
      |      \
      |       o-----o     bug_fix
       \
        o-----o           cool_idea

所以我们想要的是将 cool_idea 的更改应用到 bug_fix 上，这样我们就可以同时使用它们。以下是如何实现的方法：

git checkout cool_idea
git rebase --onto bug_fix master cool_idea

那么你的历史记录将如下所示：

o-----o-----o                   master
             \
              o-----o           bug_fix
                     \
                      o-----o   cool_idea

如果您真的考虑使用这种方法，那么我可以为您编写清理步骤，以便在需要向分支bug_fix添加提交或--rebase时进行操作。

- Trevor Norris