在 git 中获取/拉取时如何忽略其他目录？

Question

Originally, our git repository had one subdirectory in it. This was the code to our website. Now we want to include associated files and keep it all in one repository, but for our production server, we just want to git pull/fetch that original subdirectory (ie code/ ).

How do I configure git to ignore all other directories when doing a git fetch or git pull ?

I don't want to reclone; most of the solutions I've found assume that I'm starting from scratch.

Answer 1

First, a word of caution: Each of the first two comments on the question has bad advice[1].

So... fetch does not update working files. pull does a fetch and then a merge to HEAD (roughly), and really its the checkout of the updated HEAD that normally updates the working directories.

You can set up "sparse checkout", but paths are still relative to the worktree root. That is, if you have

/
  /other-artifacts
  /website
  file

and you have your repo on the production server at /repo , you can set up a sparse checkout to give you /repo/website/* , but if you want the contents of website to appear directly in /repo that's another story.

The statement "I don't want to re-clone" may or may not constrain your options; without better understanding the reason, I can't really address that. Assuming the repo worktree currently is the production website directory, recloning to a new location is likely (a part of) the easiest way to get from where you are to where you want to be, though moving and/or reconfiguring the existing repo might be doable.

What I'm getting at is, if the production directory is to be a subtree of the repo's worktree, then you probably need your repo worktree to be somewhere else on the file system. Then the production directory could be replaced with a symlink to the correct part of the worktree; or you could udpate it after each checkout (using a post-checkout hook).

Another fundamentally different approach would be to put the website itself in a separate repo and make it a submodule of the broader repo. Many people get nervous when you start talking about submodules, and this would be considerable rework - more than just recloning for sure.

It may seem like using a separate branch for the production site (as suggested in comments) would be a "poor man's" approach to approximating a submodule; but doing something like that is just asking for trouble, as any commit on the 'production only' branch would be seen as having deleted everything outside the website folder, relative to any reachable commit from the master branch.

---

[1] I can only assume the authors know that they aren't really giving well-thought-out advice, since they've opted to "answer" in comments rather than come down here in the answer section where they're subject to voting.