Question

我们使用Git来管理和部署代码。我在Ops团队，我做部署。我们的开发人员进行更改并将代码推送到Github，我们（Ops）使用一些托管流程来提取生产代码并进行部署。

这个过程是这样的：

背景

开发人员做的事。那些东西最终在Github和Devs告诉我们。
我们有一个本地“临时”克隆，以及一个本地“部署”裸git repo。本地git clone有两个遥控器，Github是“origin”，本地裸仓就是“deploy”
我们使用网络服务器上的厨师通过从“部署”远程控制中提取的厨师git资源实际部署代码
我们有“部署”遥控器，因此在Dev整理和我们的部署时间之间有一个门控机制。（而不是直接从Github部署）

实际部署流程

cd into local clone
git checkout branchname
git pull origin branchname
git push deploy branchname

所有这些都是部分自动化的，并且正在转向全自动化。因此，我们小心不要对暂存克隆进行本地更改，并且我们希望该克隆中git status的输出只能是nothing to commit (working directory clean)

然而，我们本周有一个奇怪的消息。部署克隆表明它是 80提交的原点！尽管它也说nothing to commit。

# On branch branchname
# Your branch is ahead of 'origin/branchname' by 80 commits.
#
nothing to commit (working directory clean)

最后，本身并没有什么问题。此克隆中的提交SHA256哈希匹配，以及所有Web服务器上的已部署代码。我没有进行实际的rsync比较，但我非常确信实际的代码本身已正确部署。

我想知道这是怎么发生的，如果它是坏的，以及如何清除它，除了删除本地克隆并重新开始。

Answer 1

如果同一个“deploy”（GitHub）克隆了local和origin repos，则您的流程会显示只有local正在执行{{1} }}。

回购git pull origin永远不会从deploy获取任何内容（它只接收来自origin的提交）。
这意味着local仍然相信不会在原点上提交（至少它知道的来源）从deploy repo执行的简单git fetch origin会使该状态更加清晰。

Answer 2

可能有多种原因可能发生这种情况，例如origin/branchname已被重置为先前的提交，或者有人在本地仓库中错误地提取了another_repo/branchname。但是，您似乎误解了消息的实际含义。

想象一下以下提交：

A -- B -- C -- D                origin/branchname
      \         \
        E ------ F -- G -- H    branchname

现在，如果你还没有触及本地存储库，那么很明显它很干净，你得到nothing to commit (working directory clean)消息。但是，branchname确实领先于origin/branchname 3次提交。这只是意味着您在origin/branchname的头部后面的当前分支中有3个提交。当然，仍然没有什么可承诺的！（虽然是要推送的东西。这两个是不同的）

这是一种可能发生这种情况的可能情景：

                  E -- F        origin/otherbranch
                /       \
A -- B -- C -- D         \      origin/branchname
                \         \
                 --------- G    branchname

如果你（例如错误地）说：

git checkout branchname
git pull origin otherbranch

然后，branchname中有2个提交位于origin/branchname之前。

同样，您需要更多分析才能知道究竟发生了什么。也许git log --pretty=oneline --graph可以帮助找到问题。完成后，您可以尝试重置回适当的先前状态。

即使没有进行本地更改，本地git clone仍然是原产地

2 个答案: