从 git 中提取特定文件或特定文件夹

Question

I want to know that is there any way in the git by which we can pull a particular folder or a particular file from the git.

Thanks in advance.

Answer 1

For now, you have to fetch everything, and:

• either do a shallow clone
• or copy what you need from the cloned repo in another working folder.

But that won't always be the case.
A future 2.16.x/2.17 Q2 2018 Git will introduce what is called a partial clone (or narrow clone)

See See commit 3aa6694 , commit aa57b87 , commit 35a7ae9 , commit 1e1e39b , commit acb0c57 , commit bc2d0c3 , commit 640d8b7 , commit 10ac85c (08 Dec 2017) by Jeff Hostetler ( jeffhostetler ) .
See commit a1c6d7c , commit c0c578b , commit 548719f , commit a174334 , commit 0b6069f (08 Dec 2017) by Jonathan Tan ( jhowtan ) .
^{(Merged by Junio C Hamano -- gitster -- in commit 6bed209 , 13 Feb 2018)}

See the tests for a partial clone here :

git clone --no-checkout --filter=blob:none "file://$(pwd)/srv.bare" pc1 

---

Combine that with the Git 2.25 (Q1 2020) git sparse-checkout command .

See more with " Bring your monorepo down to size with sparse-checkout " from Derrick Stolee

Pairing sparse-checkout with the partial clone feature accelerates these workflows even more.
This combination speeds up the data transfer process since you don't need every reachable Git object, and instead, can download only those you need to populate your cone of the working directory

$ git clone --filter=blob:none --no-checkout https://github.com/derrickstolee/sparse-checkout-example
Cloning into 'sparse-checkout-example'...
Receiving objects: 100% (373/373), 75.98 KiB | 2.71 MiB/s, done.
Resolving deltas: 100% (23/23), done.
 
$ cd sparse-checkout-example/
 
$ git sparse-checkout init --cone
Receiving objects: 100% (3/3), 1.41 KiB | 1.41 MiB/s, done.
 
$ git sparse-checkout set client/android
Receiving objects: 100% (26/26), 985.91 KiB | 5.76 MiB/s, done.

---

With Git 2.31 (Q1 2021), fix in passing custom args from " git clone " ^{( man )} to upload-pack on the other side.

See commit ad6b5fe (02 Feb 2021), and commit ad5df6b (28 Jan 2021) by Jacob Vosmaer ( jacobvosmaer ) .
^{(Merged by Junio C Hamano -- gitster -- in commit 60f8121 , 12 Feb 2021)}

upload-pack.c : fix filter spec quoting bug

^{Signed-off-by: Jacob Vosmaer}

Fix a bug in upload-pack.c that occurs when you combine partial clone and uploadpack.packObjectsHook.
You can reproduce it as follows:

 git clone -u 'git -c uploadpack.allowfilter '\\ uploadpack.packobjectshook=env '\\ load-pack' --filter=blob:none --no-local \\ .git dst.git

Be careful with the line endings because this has a long quoted string as the -u argument.

The error I get when I run this is:

 Cloning into '/tmp/broken'... remote: fatal: invalid filter-spec ''blob:none'' error: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed

The problem is caused by unneeded quoting.

This bug was already present in 10ac85c (" upload-pack : add object filtering for partial clone", 2017-12-08, Git v2.17.0-rc0 -- merge listed in batch #2 ) when the server side filter support was introduced.
In fact, in 10ac85c this was broken regardless of uploadpack.packObjectsHook.
Then in 0b6069f (" fetch-pack : test support excluding large blobs", 2017-12-08, Git v2.17.0-rc0 -- merge listed in batch #2 ) the quoting was removed but only behind a conditional that depends on whether uploadpack.packObjectsHook is set.

Because uploadpack.packObjectsHook is apparently rarely used, nobody noticed the problematic quoting could still happen.

Remove the conditional quoting.

Answer 2

If you want to update particular file to origin state do:

git fetch origin
git checkout  origin/[yourbranch] -- [path_to_your_files]