这实际上是一个关于GitHub比它大约Git.
请记住，Git 本身就是关于commits。每个提交都会存储一些data— 一组文件的快照 — 以及一些metadata，包括谁进行了提交、何时以及为何进行提交等内容。每个提交都由其哈希 ID 唯一标识。分支和标签名称（如果存在）仅用于查找某些名称特别的让您或 Git 启动作为任何提交中的元数据项之一的哈希 ID 是一个列表parent哈希 ID，以便 Git 可以从last提交并向后工作。
提交及其存储的数据和元数据是 Git 存在的原因。每个 Git 存储库都是提交的集合，加上一些辅助数据来帮助find承诺。 （非裸存储库your电脑还提供you有一个工作区，您可以在其中进行新工作，但是提交和辅助数据，don't让你在这里做新工作，是最低限度。）
GitHub, on the other hand, is not about commits. GitHub is about sharing.1 This sharing uses (bare) Git repositories, but adds a ton more stuff on top of that. The Git repositories—or some kind of repository anyway2—are necessary to this, but are not the added-value part.
当 GitHub 试图增加其附加值时，他们开始添加以下内容：这是一种在一次特定提交中访问特定文件的便捷方法。你的界面toGitHub 是一个 API，该 API 通过 HTTP/HTTPS 进行编码。这意味着 URL 和 JSON 等等。
在这种情况下，GitHub 发明了一些特定的 URL 路径（请参阅URL 的剖析 https://en.wikipedia.org/wiki/URL）可以引用提交中的文件。他们提供了一种方法来使用提交哈希 ID 加上提交内的文件路径来访问该特定提交中的该文件，以及另一种使用分支名称的方法（例如master）加上提交内的文件路径来访问所识别的提交中的该文件by那个分支名称。
To do this in Git, you'd normally just git checkout the branch name—which puts the entire commit into your work-tree—and then look at the file by its OS-level path, which is derived from its in-Git-commit path.3 But perhaps your question is: How can I view one file from one commit identified by branch name? In which case, try git show:
git show master:path/to/File.ext
会让您查看以该名称存储的文件（path/to/file.ext）来自该提交（无论哈希 ID 名称master决心）。
1Sharing and and archival (off-site storage). Two! Our two principle weapons are...
2Remember that Bitbucket was once a Mercurial repository sharing site. It held Hg repos, not Git repos. Perhaps someday GitHub will hold some other kind of repository.
3The OS-level path might differ from the in-Git path in several ways. For instance, on a typical Windows system, filename case (upper or lower case) is only half-respected, so a Git file named path/to/File.ext might reside in a Windows OS file system under path/TO/file.EXT. A typical MacOS file system enforces certain decomposition rules on UTF-8 strings, so MacOS might change a Git file's path as well. Linux tends not to interpret UTF-8, so if Git uses an invalid UTF-8 byte-sequence as a file path name, Linux has no issues at all here.
