Git history duplicated, is squashing commits possible?

Question

Help: Git History Duplicated (O_O)

I tried to get ride of a file which contains an API key so researched about the remove a file from git history and used the command provided here: https://youtu.be/Bo-8EfDpKxA

I used the commands

git filter-branch --index-filter 'git rm --cached --ignore-unmatch .env.development' HEAD git filter-branch --index-filter 'git rm --cached --ignore-unmatch .env.production' HEAD

Which worked fine, but I think I've messed up when pulling the changed history into a 2nd local repo to test the changes. I would have had to rebase on the 2nd repo to make sure the old history is gone. But I think I've repushed (fast-forward merge or what ever), so now I having loads of commits duplicated! (O_O) They are identical code changes and timestamp but the commit Id is different.

Question

Is there a way to fix the duplication of the history? How about a history rewrite which would squash every commits which have an identical timestamp?

Or a rebase which I would manually drop (almost) every 2nd commit?

2nd Question

I did theses changes on the develop branch and the remove of the file did work. However merging the develop into the master didn't do the trick (of course). So I guess I have do write the history of the master as well?

But now I'm afraid I would again duplicate the commits in the master branch history...

Answer 1

I tried to get ride of a file which contains an API key so researched about the remove a file from git history and used the command provided here

What you should do is revoke the API key and issue a new one. Anything sort of that is a risk if the repo is in several computers, used by different people, backed up, etc.

Is there a way to fix it?

I am not sure what you want to fix, exactly. Anything that changes anything in a commit will change the hash. Thus if you successfully removed the thing you wanted to remove, and now you have a branch with the old commits and a branch with the new ones, what you need to do is remove the branch pointing to the old chain of commits and garbage collect the repository to ensure the old ones are really gone.

So I guess I have do write the history of the master as well?

Branches are just pointers to a commit. If you still have several branches that contain the file, you need to move those branches to point to a chain of commits that is fixed. So what you have to do depends. If your master branch also had the mistake, independently, then you also have to rewrite the history of master.