如何從GitHub倉庫中找到最新的clone / fetch / pull？

Question

GitHub是否可以使repo的最新pull / fetch / clone可用（至少對那些對repo有寫訪問權限的人）？

當然，對這些信息的興趣來自於想要評估在repo上執行git push -f安全性，這將基本上覆蓋最后幾次提交：如果最早沒有發生pull / fetch / clone提交被覆蓋被推送到GitHub，然后覆蓋可能沒問題......

---

也許一個例子將澄清我的問題。 為簡單起見，我們假設只有一個本地分支（ master ）和一個遠程分支（ origin/master ）。 （IOW，遠程倉庫只有一個分支，我用我們唯一的本地分支跟蹤它。）

首先考慮一個完全本地的場景：我做了一個提交，不久之后意識到這個提交有問題。 在這種情況下，我只使用git commit --amend ... 覆蓋正確的git commit --amend ... 。

現在想象完全相同的場景，區別在於，在注意到提交問題之前，我將錯誤提交推送到遠程（GitHub）repo。

如果我是這個repo的唯一用戶，那么我可以像以前一樣在本地覆蓋提交，然后使用git push -f ...來覆蓋遠程（GitHub）repo中的錯誤提交。

但是，如果我不是這個repo的唯一用戶，那么上面的過程是有問題的，因為在推送錯誤的提交之后的某個時刻，在我覆蓋之前，不同的用戶可以從遠程（GitHub）repo克隆或獲取遠程倉庫中的錯誤提交。

最小化這種可能性的一種方法是檢查自從我將錯誤提交推送到遠程倉庫以來在遠程倉庫上執行的所有pull，fetch和clone操作的記錄。 如果此記錄至少顯示其中一個此類操作，那么這意味着我們確實存在前一段中描述的有問題的情況。

另一方面，如果記錄顯示沒有這樣的操作，那么仍然有一些希望我可以覆蓋遠程倉庫中的錯誤提交而不會引起前面描述的有問題的情況。 （當然，這是競爭條件，所以沒有100％保證。）

然而，所有這些都取決於遠程倉庫上的拉，取和克隆操作記錄的可用性。 我懷疑GitHub是否提供了這樣的記錄，至少對那些具有對repo的寫訪問權限的人來說是這樣。

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

然而， 沒有記錄最新的拉取，克隆 ，特別是考慮到上游回購不知道有多少下游回購正在訪問它以及何時訪問它。

參見“ 下游”和“上游”的定義 。

GitHub可以記錄這些信息：它是一個上游倉庫，但管理自己的基礎設施和訪問機制，所以是的，它可以記錄所述訪問。
但我不相信用戶可以看到那種信息。

Answer 2

因為在您的問題中，您發布的真實意圖是：

..想要衡量一下git push -f的安全性...

我認為改變工作流程會讓生活變得更輕松。 我建議做以下事情：

不要直接向master提交非平凡的更改（基本上您可能希望稍后更改）。 一旦改變已經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 on 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我將編寫清理步驟。