Here is the scenario:
I have updated a PHP CMS to a new version. In doing so, the guides recommend to keep the old files before replacing them with the new ones. Yes, this is dumb, because I could've time traveled using Git. I didn't.
What I did:
Bang. Now, git has a few very large commits, because of all the files actually being duplicated. I do not need those steps to be in the history. I do want to keep the current state of things, so: I want to keep the file structure exactly as it is under step 7. I want to dump steps 2 and 4.
Extra info: the difference in files between step 1 and step 7 is only about 1 or 2%, at the most. But because of the steps I took, Git thought all of those were new files, I think.
When I now try to push the commits to a remote, the changes to push are suddenly 3.54 GB, up from a couple hundred MB.
What you want to achieve here is an interactive rebase. You will tell Git "I want to rewrite my history between commit x and commit z". Then git will show you a text file, like a script you can edit to indicate what you want to do with each commit (update its message, delete it, merge with previous, etc.). Then, when you finished, save the file, and let the magic happen.
The base command is:
git rebase -i
I strongly suggest to study how this command work, and maybe perform some tests on another repository to understand well. When you will manage this command, you will understand how powerful it is. And this completely match you current need.
The doc: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
Good luck ;)
Note: the action to "merge" some commits into 1 is named "Squashing Commits"