When cloning, you can specify the depth, as follows, if it is 1, it means only clone the latest commit.

git clone git://xxoo --depth 1

Use git rebase to modify the submission history.

For example, merging the first two commits: http://stackoverflow.com/questions/59...

Make good use of rebase, in addition to deleting certain commits, you can also modify the commit log; split commits that contain multiple functions at a time; merge several commits with the same function to keep the code base history clean.

If it is a web project created in Java, it is not too big if you add ssh or something else.
Or you can consider stripping out all public jars and not placing them directly in the project.

.jar files obviously do not belong to your own front-end code, but to third-party dependencies and should not be placed in the code base. It is recommended to use a script to manage the version of third-party dependencies in the early stage of the project and remove the .jar file from the code base.

Git can change history
You can try merging the useless history locally first and then force push it up

.git is your local warehouse, which records all git commit history information,
Specifying depth when cloning can avoid downloading too much historical commit information.

But your question seems to be how to handle it when publishing,
It's simple, just delete the .git directory when publishing.

Use git lfs
https://git-lfs.github.com/