I’ve committed and pushed a sensitive password file into our remote repo azure dev ops.

However, right now, it’s only on my remote branch. It’s not merged into main yet. Can I somehow delete this file/even the whole commit I did from azure dev ops?

CodePudding user response：

ASAP: The first thing I would do is make a copy of your local branch for sanity sake, reset to the commit before the bad commit, and then force push out your branch. This will minimize the chances of someone else seeing your password file, and you can fix up your branch afterwards. Here are the commands you need (assuming the bad commit is on a branch called my-branch:

git checkout my-branch # just in case it isn't checked out already
git status # make sure your status is clean, if not, stash or commit or delete the changes
git branch my-branch-bad # make a copy of it
git reset <commit-id-before-bad-commit> # put branch back to before the bad commit
git push --force-with-lease # push out the branch to AzDev

At this point the password file is no longer (easily) available on AzDev. Now let's figure out how best to recover your branch, if needed.

If the bad commit was your latest commit, then you could be done, since you mentioned you were willing to lose that commit completely. Or, note that I purposefully suggested git reset without specifying a type, such as --soft, --mixed, or --hard, and the default is --mixed. This means that all of your changes will still be in your working folder. If you wish to recreate the commit, stage all of the pending files except the password file and redo the commit. Then you can push that commit out and your branch will look like how you wanted it to be in the first place.

If the bad commit was not your latest commit, and you had other commits you wanted to keep after the commit you reset to, then reset your branch back to where it was before (by using the copied branch), and then interactive rebase to drop the bad commit:

git reset --hard my-branch-bad # put branch back to how it was with the bad commit
git rebase -i @{u} # start an interactive rebase from the tip of the remote branch

The cryptic @{u} is shorthand for your upstream branch, which we know is currently the first commit before the bad commit because that's what we last pushed out in the first step. When the interactive rebase comes up, it will display all of the commits after what you pushed out, and the first one will be the commit you wish to drop. You can change the pick in the first line to either drop or d, or you can even just delete the first line, and then save and exit the file. Now continue the rebase with git rebase --continue. As long as the rest of the first commit you just dropped didn't have something that later commits needed, then you won't have any conflicts and the rebase will continue and finish. Your end result is the original branch except with the one bad commit omitted. You can now push out your latest version of the branch. You can also delete your copy of the bad branch since you no longer need it: git branch -D my-branch-bad.

Now your branch is fixed up and you need to determine if the password file is still accessible. Since it hadn't been merged yet anywhere, I believe the answer depends on whether or not you had a PR setup on your branch yet. If you did have a PR on your branch, then unfortunately AFAIK the PR history will always contain that file in the specific Update. If there wasn't a PR on the branch, then you may be safe (enough) to not have to continue worrying about it. You (and anyone) can probably still see the commit in AzDev by directly navigating to the commit ID url, however, I can't think of any reason for someone to know that ID other than you, at this point. However, anyone who fetched during the time the bad commit was on your remote branch, would have a copy of the commit in their local copy of the repo, and could see the file if they choose to look at it.

All that being said, if the repo is public, I wouldn't risk it, and your safest approach would be to change all of your passwords found in that file. It the repo is private, depending on who might possibly have access to the repo, I would at least change the passwords that you wouldn't want others in your organization to know.