最初，我在2012年git档案中提到(见Jared Forsyth的答案和Robert Knight的答案)，自git1.7.9.5(2012年3月)以来，Paul Brannan的答案是:

git archive --format=tar --remote=origin HEAD:path/to/directory -- filename | tar -O -xf -

但是:在2013年，这对于远程https://github.com url来说已经不可能了。 请参阅旧页面“我可以存档存储库吗?”

当前(2018)页面“关于GitHub上的内容和数据存档”建议使用第三方服务，如GHTorrent或GH Archive。

所以你也可以处理本地拷贝/克隆:

如果您有本回答中提到的裸存储库的本地副本，您也可以执行以下操作，

git --no-pager --git-dir /path/to/bar/repo.git show branch:path/to/file >file

或者你必须首先克隆回购，这意味着你得到完整的历史:

在.git回购中 在工作树中。 但是你可以做一个稀疏签出(如果你使用Git1.7+)，: 启用稀疏签出选项(git config core.)sparsecheckout真的) 在.git/info/sparse-checkout文件中添加您想要看到的内容 重新读取工作树以只显示您需要的内容

要重新阅读工作树:

$ git read-tree -m -u HEAD

这样，您就得到了一个工作树，其中精确地包含了您想要的内容(即使它只有一个文件)。

Richard Gomes指出(在评论中)“如何从git存储库中克隆、获取或稀疏签出单个目录或目录列表?”

避免下载历史记录的bash函数，它检索单个分支并检索所需的文件或目录列表。

在Git 2.40 (Q1 2023)中，通过检查稀疏模式来判断我们是否使用了“锥”模式的逻辑已经收紧，以避免将单个文件命名为指定锥的模式。

参见William Sprent (williams-unity)提交的5842710(2023年1月03日)。 (由Junio C Hamano—gitster—在commit ab85a7d中合并，2023年1月16日)

目录:检查单文件圆锥模式 署名:威廉·斯普伦特 致谢:维多利亚·戴伊

The sparse checkout documentation states that the cone mode pattern set is limited to patterns that either recursively include directories or patterns that match all files in a directory. In the sparse checkout file, the former manifest in the form: /A/B/C/ while the latter become a pair of patterns either in the form: /A/B/ !/A/B/*/ or in the special case of matching the toplevel files: /* !/*/ The 'add_pattern_to_hashsets()' function contains checks which serve to disable cone-mode when non-cone patterns are encountered. However, these do not catch when the pattern list attempts to match a single file or directory, e.g. a pattern in the form: /A/B/C This causes sparse-checkout to exhibit unexpected behaviour when such a pattern is in the sparse-checkout file and cone mode is enabled. Concretely, with the pattern like the above, sparse-checkout, in non-cone mode, will only include the directory or file located at '/A/B/C'. However, with cone mode enabled, sparse-checkout will instead just manifest the toplevel files but not any file located at '/A/B/C'. Relatedly, issues occur when supplying the same kind of filter when partial cloning with '--filter=sparse:oid=<oid>'. 'upload-pack' will correctly just include the objects that match the non-cone pattern matching. Which means that checking out the newly cloned repo with the same filter, but with cone mode enabled, fails due to missing objects. To fix these issues, add a cone mode pattern check that asserts that every pattern is either a directory match or the pattern '/*'. Add a test to verify the new pattern check and modify another to reflect that non-directory patterns are caught earlier.

在git中，你在更新文件之前不会“签出”它们-这似乎是你所追求的。

许多系统，如clearcase, csv等，都要求您在对文件进行更改之前“签出”文件。Git不需要这个。克隆存储库，然后在存储库的本地副本中进行更改。

一旦你更新了文件，你可以做:

git status

查看修改了哪些文件。你先添加你想要提交给index的对象(index就像一个要签入的列表):

git add .

or

git add blah.c

然后do git status会告诉你哪些文件被修改了，哪些文件在索引中准备提交或签入。

要将文件提交到存储库副本，请执行以下操作:

git commit -a -m "commit message here"

参见git网站上的手册和指南链接。

这听起来像是你试图从集中式版本控制中继承一个想法，而git本质上不是这样的——它是分布式的。如果你想使用git存储库，你可以克隆它。然后，您就拥有了工作树的所有内容和所有历史记录(好吧，至少是指向当前分支顶端的所有内容)，而不仅仅是单个文件或单个提交的快照。

 git clone /path/to/repo
 git clone git://url/of/repo
 git clone http://url/of/repo

你可以通过

git archive --format=tar --remote=origin HEAD | tar xf -
git archive --format=tar --remote=origin HEAD <file> | tar xf -

另一个解决方案，类似于使用——filter=blob:none的解决方案是使用——filter=tree:0(你可以在这里阅读关于区别的解释)。

这种方法通常比blob-one更快，因为它不下载树结构，但有一个缺点。考虑到您延迟了树的检索，当您进入repo目录时将受到惩罚(取决于repo的大小和结构，它可能比简单的浅克隆大许多倍)。

如果你是这种情况，你可以通过不进入回购来解决:

git clone -n --filter=tree:0 <repo_url> tgt_dir
git -C tgt_dir checkout <branch> -- <filename>
cat tgt_dir/<filename> # or move it to another place and delete tgt_dir ;)

请考虑到，如果您必须签出多个文件，树填充也会影响您的性能，因此我建议仅在回购足够大的情况下才对单个文件执行此操作。

在GIT 1.7.2.2中工作

例如，你有一个带有分支branch1和branch32的远程some_remote

所以要签出一个特定的文件，你可以调用这些命令:

git checkout remote/branch path/to/file

举个例子，大概是这样的

git checkout some_remote/branch32 conf/en/myscript.conf
git checkout some_remote/branch1 conf/fr/load.wav

这个检出命令将整个文件结构conf/en和conf/fr复制到当前目录，在这里您调用这些命令(当然，我假设您在之前的某个时候运行了git init)