Git is not a deployment mechanism. It is a distributed source control tool. You are creatively using the “distributed” part to manage and deploy your artefacts, but that is not playing to Git's strength. Instead, storage of binary assets is a weakness of Git, because
- this results in a very large history, and
- no meaningful diffs are possible.
I have worked with large repos containing binary assets. This was unavoidable (because the collection of binaries had to be version-controlled), but it's an experience I don't recommend.
It is possible to do a shallow clone where you only download the top few commits rather than the complete history, but that complicates the Git usage, and means that you don't have a fully functional repo available.
Git is also a really bad deployment tool, because Git is concerned about files, not about processes or services running on the production system. You will typically want to setup script that can stop and restart relevant services.
If copying files into a particular folder is sufficient, then write a script that
- builds a release, then
- copies the release to the production environment with an FTP-like program. (But not literally FTP, because it transmits passwords in plaintext.)
If you need a more sophisticated deployment, write a script that
- builds a release,
- remotes into the production environment,
- uploads the new release,
- stops the old processes and restarts from the new release, and
- cleans up old releases.
Maybe there is a friendly Sysadmin or DevOps person around who can assist with these issues. There are also a ton of existing solutions specifically for managing your artefacts. I think in the .NET world, hosting your own NuGet repository is a common and definitively superior approach.