為什么我的git master分支當前的HEAD不是最近推送的文件？

Question

如果已經被問過，請道歉。 我花了很長時間瀏覽Git上的舊SO帖子，但還沒有找到一個真正符合這個案例的帖子。

我是一個由5名開發人員組成的團隊，他們在項目中使用Git。 我們一直在使用它而沒有任何實際問題。 我們在共享服務器上設置了Gitosis，並在master分支中完成了大部分工作，盡管我們經常將它們拆分為側分支以用於新功能等。

本周我看到了一些我不了解的主分支的奇怪行為 - 行為實際上失去了提交並導致開發人員重新修復並重新進行了已經做出的更改。 我第一次看到它時，我把它歸結為人為錯誤，並假設我沒有按照我的想法推到主分支。 我第二次看到這個問題，我們能夠收集更多的信息，看起來系統很混亂，或者我們的開發人員錯誤地告訴git做了一些他們不理解的事情。

這是我們看到的：如果我查看一個git日志，我可以看到所有提交。 它們是有序的，並且提交差異都是正確的。 但是，如果我查看該文件的當前版本，它不包含最近提交的所有更改。 IE，日志顯示提交，但文件中沒有這些提交。 當我查看Web界面上的文件歷史記錄（我相信我們正在使用GitWeb）時，GitWeb確實知道最新文件與最新文件不同。 也就是說，在最近的提交旁邊，它會添加一個“diff to current”的鏈接。 兩個或三個提交返回沒有“diff to current”鏈接，因此很明顯該文件的當前版本是日志/最近提交后面的一些提交。

1）如何/會導致什么？ 如果我們自己用錯誤的命令做到這一點，我們很想知道將來如何避免它。

2）如何修復？ 我的猜測是，如果可以明確地抓住最近的提交但是誰說這樣做我們沒有以類似的方式丟失其他文件中的工作。 整件事情讓人感到非常不安，因為我們真的不確定此時失去了什么。

非常感謝任何建議。

Answer 1

就在我的頭頂，您推動的存儲庫是否有工作空間？ 也就是說，如果你去repo所在的目錄，你真的看到你修改過的文件嗎？ 如果是這樣，那可能是一個不好的跡象。 你應該只推送到裸存儲庫。 如果有人確實推送到非裸存儲庫，您可以通過執行git reset --hard將工作空間重置為當前頭。