4

GitHub 是否提供 repo 的最新 pull/fetch/clone 的时间（至少对于那些对 repo 具有写访问权限的人）？

当然，对这些信息的兴趣来自于想要衡量git push -f在 repo 上做一个基本上会覆盖最后几个提交的安全性：如果自最早的提交以来没有发生拉/取/克隆 - be-overwritten 被推送到 GitHub，那么覆盖可能就OK了……

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

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

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

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

但是，如果我不是这个 repo 的唯一用户，那么上述过程是有问题的，因为在我推送错误提交之后但在我覆盖之前，其他用户可能已经从远程 (GitHub) repo 克隆或获取远程仓库中的错误提交。

将这种可能性降到最低的一种方法是检查自我将错误提交推送到远程存储库以来在远程存储库上执行的所有拉取、获取和克隆操作的记录。如果这个记录至少显示了一个这样的操作，那么这意味着我们正好遇到了上一段中描述的问题场景。

另一方面，如果记录显示没有这样的操作，那么我仍然有希望覆盖远程 repo 中的错误提交，而不会导致前面描述的问题场景。（当然，这是一个竞争条件，所以没有 100% 的保证。）

然而，所有这一切都取决于远程仓库上此类拉取、获取和克隆操作记录的可用性。我的问题是 GitHub 是否提供这样的记录，至少对于那些对 repo 有写访问权限的人。

4

2 回答 2

1
于 2013-03-17T19:04:48.680 回答
0

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

..来自想要衡量执行 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>

这应该有助于防止需要--rebaseon 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。

于 2013-03-17T21:09:42.273 回答