代码之家  ›  专栏  ›  技术社区  ›  Aftermathew

为什么我的git主分支的当前头不是最近推送的文件?

  •  3
  • Aftermathew  · 技术社区  · 16 年前

    如果你已经问过了,请道歉。我花了很长时间浏览git上的旧so帖子,但还没有找到一个与本例真正匹配的帖子。

    我是一个由5名开发人员组成的团队,他们在一个项目中使用git。一年来我们一直在使用它,没有任何实际问题。我们在一个共享服务器上建立了gitosis,并在master分支中完成了大部分工作,尽管我们经常为了新的特性而分成分支。

    本周,我看到了一些我不理解的主分支的奇怪行为,这些行为实际上是丢失提交,导致开发人员重新修复和重新执行已经做的更改。我第一次看到它,就把它归咎于人为的错误,以为我并没有像我想的那样被推到主枝上。第二次我看到这个问题时,我们能够收集更多的信息,这似乎是因为系统混乱,或者是我们的一个开发人员错误地告诉git做一些他们不理解的事情。

    我们看到的是: 如果我查看git日志,我可以看到所有提交。它们是有序的,提交差异都是正确的。但是,如果我查看文件的当前版本,它不包含最近提交的所有更改。即,日志显示提交,但文件中没有这些提交。当我查看web界面上的文件历史记录(我相信我们正在使用gitweb)时,很明显gitweb知道最新的文件与最新的文件不同。也就是说,在最近的提交旁边,它会添加一个链接,上面写着“diff to current”。后面的两三次提交没有“diff to current”链接,因此很明显,文件的当前版本是在日志/最新提交之后的几次提交。

    1)如何/什么会导致这种情况?如果我们自己用错误的命令来做这件事,我们很想知道今后如何避免。

    2)如何修复?我的猜测是,if可以显式地获取最新的提交,但是谁能说,这样做的话,我们不会以类似的方式丢失其他文件中的工作。整件事相当令人不安,因为我们真的不知道在这一点上失去了什么。

    非常感谢你的建议。

    1 回复  |  直到 16 年前
        1
  •  1
  •   kenm    16 年前

    就在我的头顶上,你要推的存储库是否有一个工作区?也就是说,如果你转到repo所在的目录,你真的看到你修改过的文件了吗?如果是的话,那可能是个坏兆头。您应该只推到裸存储库。如果有人确实推送到了一个非裸存储库,您可以通过执行 git reset --hard 在那里。