In theory In Git you can have
sub projects that are actually other Git repos. But I don't know how you handle that on Github, and professionally I had at least one project where the whole repo was completely FUBAR because of problems with sub-projects.
You are efficient in Git only if you use the CLI or your IDE. The web thingy is only for trivial interactions (updating the readme...). When you are the only one on a project you only need to know "git commit" and perhaps "git tag". Then you only copy the .c files to each project (with a script or else) and then "git commit" each project (if you are in Linux or a Mac, you can instead make a links so the very same files appears in all projects , but you have to make sure that your editor/IDE handle this properly).
The real question is why you have several projects if you have dependencies across your code. Keeping the code and the publication to end users separate is always a good idea, so you can have a single project that houses all your filters, and distribute them via another site. A long time ago I wondered about distributing my scripts via Github/Gitlab and eventually decided against this.