For read operations, you can often get what you want by passing path options.
git log -- ./the_one_folder
or
gitk -- ./the_one_folder
But for operations that write, such as rebase, there is no general way to do what you describe. If you commit everything to one big history, then that history is essentially a part of each commit. So you have a commit that changes the_one_folder, even if its parent doesn't change anything in the same folder that parent is part of the commit and you can't do a rebase "as though it weren't there".
You could do a rebase that drops all the commits you don't care about, but then those commits are removed from the branch you're rebasing. So basically you'd have to have a set of branches for your directory, and a set of branches for the next directory that the next guy works on, and on and on.
And once you do that, it starts to look like you should've put each project in its own repo. And that's a fact. In git, you shouldn't cram a bunch of projects into the same repo. If you do sometimes correlate changes across projects, there are ways to deal with that; but it sounds like at least most of the time these are independent, so if you don't want a bunch of cluttered histories you should consider moving to separate repos.
There is a way to create a history of "just your project" - realizing that this is only really useful if you are indeed migrating to separate repos (or at least separate namespaced sets of refs, but that's just a more complicated way to do the same thing so why?) because once its done changes to the separate history will no longer be reflected in the combined history.
git filter-branch --subdirectory-filter the_one_folder --prune-empty -- --all
