即使没有进行本地更改，本地git克隆仍然领先于原产。
我们使用Git来管理和部署代码。我是行动组的我负责部署。我们的开发人员进行更改，并将代码推入Github中，我们(Ops)使用一些托管过程来提取生产代码并进行部署。
这一过程如下：
背景
- 开发人员会做一些事情。那些东西最后都在吉特布，德维兹告诉我们。
- 我们有一个本地的“暂存”克隆，和一个本地的“部署”裸git回购。本地git克隆有两个遥控器，Github作为“原始”，本地裸回购作为“部署”。
- 我们使用web服务器上的厨师通过从“部署”远程获取的厨师git资源实际部署代码。
- 我们有“部署”远程，以便在开发完成和部署时间之间有一个门控机制。(而不是直接从吉突布部署)
实际部署过程
cd into local clonegit checkout branchnamegit pull origin branchnamegit 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比较，但我很有信心实际代码本身的部署是正确的。
我想知道如果它是坏的，它是如何发生的，以及如何清理它，除非删除本地克隆并重新开始.。
回答 2
Stack Overflow用户
发布于 2013-02-12 15:12:09
如果deploy和local repos都是从相同的“origin”(GitHub)中克隆出来的，则您的过程显示只有local在执行git pull origin。
回购deploy从不从origin获取任何东西(它只接收来自local的提交)。
这意味着deploy仍然相信提交不会发生在原点上(至少它所知道的起源)。
从git fetch origin回购中执行一个简单的deploy将使状态更加清晰。
Stack Overflow用户
发布于 2013-02-12 15:20:16
可能发生这种情况的原因有很多，例如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提交。这仅仅意味着您在当前分支中有3次提交，位于origin/branchname的头之后。当然，还是没有什么可做的！(虽然有东西要推。这两者是不同的)
这是一种可能发生的情况：
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会帮助发现问题。一旦您这样做了，您可以尝试重置回一个适当的先前状态。
https://stackoverflow.com/questions/14835515
复制相似问题
腾讯云开发者
