Push and fetch are not file based, they're commit based.
When you connect your client Git to a server Git, you choose whether you are doing this to get commits (git fetch), or to give them commits (git push). But what you get or give is whole commits, never "a file" or "a folder" (directory). Thus, your examples are wrong.
Note that any one commit always contains a complete snapshot of its tree. That is, if you have a/file1.txt, a/file2.txt, b/file3.txt, and c/file4.txt in your repository, and you touch one of these files and make a commit, the new commit has copies of all four files. (To save space, it re-uses the unmodified originals, but the commit really does contain all four files.) When you send this commit to another Git, you send the whole commit, not just part of the commit.
If you put the file in, they can get the file out—and by default, they will get all the files. Git does support something called a "sparse checkout", which you can (ab?)use for this kind of purpose, but chances are good that this is the wrong way to go about this.
People who ask this question are, about 93.4% of the time,1 trying to store configuration files in their repository, but don't want those configuration files copied out to clients (except, sometimes, as initial default configurations). Again, this is the wrong way to do this: instead of storing the configuration files, have your system store default configuration files. Clients will pick up these default files as usual; clients who set up their own actual configurations will use their configuration instead of, or overriding, the defaults; and there will be no conflict between "my local configuration"—which is never checked in to this repository at all—and "the sample and/or default configurations", which are checked into this repository.
1This statistic made up on the spot, just like 42.7% of all statistics.
