The general solution to this is to store larger files—often binary assets and the like—outside the repository. This can be anywhere, even in some other Git repository on GitHub if you like, or on some Git-LFS hosting site, or whatever, as long as there's some way for your users to retrieve the files. You then have your software store the URL (or URLs) by which it can retrieve the files; that's what goes into the Git repository, which makes for a small (or at least smaller) repository that fits within the usual GitHub limits.
You can either replace the binary files at the storage site in-place, keeping the URLs, or come up with new, slightly-different URLs so that it becomes possible to tell that some old checkout no longer has the binary assets available. The latter system is equivalent to using Git-LFS, which consists of install-able pieces of software that "wrap" your Git system and do this kind of file-shuffling for you semi-automatically, making whoever uses the Git repository "see" the large files as long as they have installed and use Git-LFS themselves. Those who haven't installed Git-LFS see instead the "pointer files" (which consist of URLs and hash-ID checksums), which is what really do end up in your repository.
(GitHub do support Git-LFS themselves, but you'll generally need to pay for it, as the initial storage limits are tiny, as these things go.)