Git 文件完整性
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/964331/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git File Integrity
提问by Hamza Yerlikaya
Recently my main machine i use for development started overheating. I started to get 4 or 5 lockups per day. Everything freezes. All my projects are under version control using git.
最近我用于开发的主机开始过热。我开始每天有 4 到 5 次锁定。一切都冻结了。我所有的项目都使用 git 进行版本控制。
I remember watching Linus' talk at Google saying git will ensure that the files are not corrupt. In my situation is it safe to assume that git will warn me if one of the source files gets corrupt.
我记得在 Google 上看过 Linus 的演讲，他说 git 将确保文件不会损坏。在我的情况下，如果源文件之一被损坏，git 会警告我是安全的。
OS is Mac OS X 10.4 file system is HFS+.
操作系统是 Mac OS X 10.4 文件系统是 HFS+。
回答by Esko Luontola
You can force Git to check the whole repository with git fsck. If a Git repository gets corrupted, you should get a new clone from a non-corrupted repository.
您可以强制 Git 检查整个存储库git fsck。如果 Git 存储库损坏，您应该从未损坏的存储库获取新的克隆。
Under normal operation Git should check parts of the repository as they are read, so it might take longer to notice some corruption, but it willbe noticed the first time that you try to access the corrupt data.
在正常操作下，Git 应该在读取存储库的部分内容时对其进行检查，因此可能需要更长的时间才能注意到某些损坏，但是当您第一次尝试访问损坏的数据时就会注意到。
回答by Matt Enright
What Linus meant when he said that Git ensures the files are not corrupted, he was referring to the fact that when you refer to a particular commit (identified by its hash), you are guaranteedthat it will alwaysrefer to the exact same repository state. If you and pull the linux kernel from Linus' tree, and he refers to some commit ae6bcd1..., there is nothing that you can do (even in your local repository) to ever make commit ae6bcd1... look any different from the commit Linus is looking at when he refers to it.
当 Linus 说 Git 确保文件没有损坏时，他指的是这样一个事实，即当您引用特定提交（由其哈希标识）时，您可以保证它始终引用完全相同的存储库状态. 如果您从 Linus 的树中提取 linux 内核，并且他指的是某个提交 ae6bcd1...，则您无能为力（即使在您的本地存储库中）使提交 ae6bcd1... 看起来与提交 Linus 在提到它时正在查看。
Furthermore, because a commit object contains references to (all of) its parent commit(s), when you refer to a commit you are guaranteeing its complete history in the DAG as well.
此外，因为提交对象包含对其父提交（所有）的引用，所以当您引用提交时，您也保证了其在 DAG 中的完整历史记录。
As far as file corruption, its sort of an independent issue; but without corrupting the actual blob objects (ie .git/objects/ob/ject_hashname) if one of your working tree files gets corrupted, you will be able to restore from a previous commit state or from an index/cached state.
至于文件损坏，这是一个独立的问题；但是如果您的工作树文件之一被损坏，则不会损坏实际的 blob 对象（即 .git/objects/ob/ject_hashname），您将能够从先前的提交状态或索引/缓存状态恢复。
You will never be able to corrupt a remote in this case unless you are doing forced pushes (which overwrite history on remotes), since push ensures the commit objects form a continuous history graph.
在这种情况下，除非您进行强制推送（覆盖远程上的历史记录），否则您将永远无法破坏遥控器，因为推送确保提交对象形成连续的历史图。
回答by Jamie
Recently I had to verify the repos on a server that crashed, I used the following command:
最近我不得不验证崩溃的服务器上的 repos，我使用了以下命令：
for gitdir in $(sudo find / -name ".git" -type d -printf "%h "); do
cd $gitdir && ( git fsck && echo "${gitdir} - "'HAPPY !' ) \
|| echo "${gitdir} - "'ERROR !';
done
