I am using git flow. I made some rules how to keep git history clean because I am generating changelog from these commits.
But some old commits (made directly to develop) or merged feature branches are not following these rules. Is it some easy way to squash these old commits without affecting all current branches (master, version tags, etc...)?
I am familiar with rebase inside feature branches, but I cannot imagine how to do it inside develop/master branch.
No. Git is a simple blockchain, in that each block (commit) contains within it a reference to the previous block's Id. In Git, block Ids are simply a hash of their contents, so when you change the contents, even a little bit, the hash changes and thus so does the Id. Since the parent Id is part of a block's contents, you can't change those early blocks without also changing all of the following blocks. Changing the parent means you need to change the child, which means you need to change the child's children, etc.
This is totally possible, but it will cause major headaches for everyone who is working on a feature branch based off the old commits. It will also break all of your tags which will continue to point to the original commits unless you delete and re-create each of them, which may break anyone who was doing builds, etc, off the old tag pointers.
Basically, you're just going to have to live with a messy history that refuses to conform to more modern principles. Kind of like real life.
The only exception to this rule is if you could find some way of hacking those original commits so as to generate hash collisions. This would trick the following commits into thinking they're still pointing to the original commits. This would not be easy to pull off and is almost certainly not desirable as the hacked commits would look like a mess, but Git uses SHA-1 which has been cracked, so it's technically possible.