Question

GitHub是否可以使repo的最新pull / fetch / clone可用（至少对那些对repo有写访问权限的人）？

当然，对这些信息的兴趣来自于想要衡量在repo上执行git push -f的安全性，这将基本上覆盖最后几次提交：如果没有pull / fetch / clone自从最早被提交被覆盖被推送到GitHub之后发生了，那么覆盖可能没问题......

或许一个例子可以澄清我的问题。为简单起见，我们假设只有一个本地分支（master）和一个远程分支（origin/master）。（IOW，远程仓库只有一个分支，我用我们唯一的本地分支跟踪它。）

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

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

如果我是这个repo的唯一用户，那么我可以像以前一样在本地覆盖提交，然后使用git push -f ...覆盖远程（GitHub）仓库中的错误提交。

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

最小化这种可能性的一种方法是检查自从我将错误提交推送到远程仓库以来对远程仓库执行的所有pull，fetch和clone操作的记录。如果此记录至少显示其中一个此类操作，那么这将意味着我们确实存在上一段中描述的有问题的情况。

另一方面，如果记录显示没有这样的操作，那么仍然有一些希望我可以覆盖远程仓库中的错误提交而不会引起前面描述的有问题的情况。（当然，这是竞争条件，所以没有100％保证。）

然而，所有这些都取决于远程仓库上的拉，抓取和克隆操作记录的可用性。我怀疑GitHub是否提供了这样的记录，至少对那些对repo有写访问权限的人来说。

Answer 1

对于user's repositories：

，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的分支上的最后一次提交。

然而，没有记录最新的拉动，克隆，特别是考虑到上游回购不知道有多少下游回购正在访问它以及何时访问它。

请参阅“Definition of “downstream” and “upstream””。

GitHub可以记录这些信息：它是一个上游回购，但管理自己的基础设施和访问机制，所以是的，它可以记录所述访问。
但我不相信用户可以看到那种信息。

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>

这有助于防止--rebase master上需要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

然后你的历史将如下所示：

--rebase

如果您真的考虑使用此方法，那么如果您需要向bug_fix分支{{1}}添加提交，我将编写清理步骤。

如何从GitHub仓库中找到最新的clone / fetch / pull？

2 个答案: