Rotate the credential first. Before rewriting history, before amending the commit, before anything else. This is the step that actually ends the exposure, and every other step is housekeeping by comparison.
The reason is simple: removing a secret from a file does not revoke it. The value remains valid at the provider until someone revokes it there. A key deleted from your repository and left active is exactly as compromised as one still sitting in the file, but harder to remember to deal with.
If the commit reached a remote, assume the value has been read. Public repositories are scanned continuously by automated systems, and the window between pushing a key and it being used can be measured in minutes. Private repositories are safer but not safe: anyone with access has seen it, and it now exists in every clone, every fork, and any CI cache that fetched the repository.
Once rotated, clean up in a sensible order. Replace the credential with an environment variable reference. Add the file to your ignore rules if it should never have been tracked. Then, if you need to, rewrite history — accepting that this requires everyone with a clone to re-fetch, and that any fork or mirror keeps the old object regardless.
Check what else was exposed while you are there. A committed environment file rarely contains only one secret, and the one you noticed is often not the most sensitive. Scan the whole file rather than fixing the line that caught your eye.
Finally, work out how it happened. A key in a commit is usually a process gap rather than carelessness: a file that should have been ignored, a config pasted in for debugging, a test fixture that acquired a real value. Fixing the process is what stops the second occurrence.