How to remove a commit from Atlassian Bitbucket

Hello!

In this article I will show you how to delete a commit from a Bitbucket repository.

Why would we need to delete a commit?

It can happen if you accidentally pushed sensitive information into your Bitbucket repository.

For example, you forgot to exclude a file with passwords from adding to git or you provided your password in one of the source files to test how the program works and then you forgot to remove your password from this source file. You pushed commits from your local repo to your Bitbucket repo and that is it. Your sensitive information is there. Everyone with access to this repository can see your password, for example. How to remove this sensitive information?

You can delete your repository and create a new one. But it would make you apply all settings from the deleted repo back and warn your mates, that you created a new repo. It sounds too complicated.

A simpler way would be to remove the wrong commit.

In this tutorial I will show you step by step how to do it.

Create a Bitbucket repo

First I will create a Bitbucket repository:

Screenshot 2020-05-31 at 10.47.30.png

Create a local repository, make changes, push to Bitbucket

I will create a new folder for my repository:

mkdir bitbucket-tutorial
cd bitbucket-tutorial/

I will initialise the git repository and add the remote for my Bitbucket repository:

git init
git remote add origin https://alex1mmm@bitbucket.org/alex1mmm/bitbucket-repo-article.git

I will create a new file and add some contents:

touch mynewfile.txt

Here is the contents of mynewfile.txt:

this line is initial commit

I will commit the changes and push the changes into Bibucket:

git add *
git commit -m "initial"
git push origin master

I will make changes to mynewfile.txt:

this line is initial commit
I added my password info here

I will commit changes and push to Bitbucket:

git add *
git commit -m "sensitive info"
git push origin master

If we have a look at our Bitbucket now we will see two commits:

Screenshot 2020-05-31 at 11.08.11.png

And our commit with sensitive information contains our password line:

Screenshot 2020-05-31 at 11.09.25.png

Even if we remove our password from mynewfile.txt, commit changes and push to Bitbucket, we will still be able to see our commit with sensitive info and hence our password.

We need to remove this commit completely from our Bitbucket repo

Remove commit with password

Let's first find the id of our commit:

git log --oneline --graph --decorate

Here is the output:

Screenshot 2020-05-31 at 11.18.31.png

I marked the id of our commit with a red rectangle.

Now let's remove this commit. We need to reset our git repository to the commit which took place before our wrong commit. The id of the previous comment is 3e90065:

Screenshot 2020-05-31 at 11.23.08.png

Now let's reset our repository

git reset --hard 3e90065

Now mytextfile.txt looks like this:

this line is initial commit

Correct! We do not have our information about the password.

Our commit history looks like this:

Screenshot 2020-05-31 at 11.26.25.png

We do not have our comment with sensitive information. Also correct!

But if we look at our Bitbucket repository, we still have our sensitive info comment:

Screenshot 2020-05-31 at 11.28.11.png

That is because we did not push our changes form our local repository to our Bitbucket repository. Let's do it:

git push --force origin master

Screenshot 2020-05-31 at 11.31.53.png

And now if you have a look at our repository in Bitbucket we will have only our initial commit:

Screenshot 2020-05-31 at 11.33.19.png

Success! We removed the commit with our password from our Bitbucket repository.

18 comments

Kirill July 28, 2020

Thank you very much for a very clear explanation!

Anthony Uk October 14, 2020

I tried this on our Bitbucket and it did not truly work.

Although the commit disappears from the list, if you know the commit ID you can still look at it and see the password file by manually entering the URL.

Like # people like this
Dariusz February 18, 2021

Simple explanation, great result !!! THX

KamyFC March 9, 2021

Thanks this worked. I had to get rid of a rouge commit from a rogue dev!

eric-914 September 3, 2021

Will this work if the commit in question is not the last, most recent commit?

Christian Avila October 18, 2021

will this work if the commit in question is not the last one?

innovatesol7 December 13, 2021

Hi, this worked great to rewind back several commits, just add in any id in the reset command (see below) - the id does not have to be the last one (to answer previous questions above) :) 

git reset --hard <commit id here> 
michael_glenn_williams February 7, 2022

What if you created the commit using the Bitbucket website? Can we delete it without having to pull it down to a local and delete it using the local CLI ?

Like Lonnie likes this
Mohamed Hussein February 24, 2022

Thank You, it worked with me

abreton March 14, 2022

Biggest issue is that if you know the commit's URL, you will still be able to access all the information, even after removing said commit and force pushing.

Like # people like this
MrAtheist June 16, 2022

This definitely doesnt work in a PR since it would show all the commit trail... which i dont think github does this at all

Bhavesh Prajapati November 2, 2022

Thank you it is very useful for all.

git push --force origin master

why use --force ?


 

AfrozBasha Arab January 2, 2023

@Alexey Matveev  it was good but a easy one.

what if the sensitive information was in the initial commit ?

my use case has sensitive information in the very first commit and there are lot of commits happened on that, now I want to remove the sensitive information from the first commit.

Please help me on this

Patrick Nelson January 6, 2023

A simple force-push doesn't seem to really kill commits like these (at least not immediately).

I found a commit with credentials in it so I was forced to fix it. After force-pushing my rebase/rewrite to each of the affected branches, I double checked the offending original commit has to make absolutely sure that it was removed, but alas... that's not really the case. I figured that might happen because, even locally, you still have to garbage collect to remove "unreachable" commits like these, e.g.:

git reflog expire --expire-unreachable=now --all
git gc --prune=now

However, if you go directly to the commit hash URL in Bitbucket it still shows with this banner which tells me that it needs to be garbage collected on Bitbucket's side. Does that happen? Oh lordy I hope so...

This commit is unreachable from any branch or tag in this repository. It may be from a fork outside of this repository.

2023-01-06_20-14-17.png

Like Martin PIRON likes this
Kuldeep Chaudhary February 27, 2023

This worked but what for overview page there i can see he changes like in this SS i removed 'second commit' but it is appearing as a activity and changes can also be found. Is there any way to remove completely and no activity appears?
Screenshot 2023-02-28 at 10.12.11 AM.png

Like Martin PIRON likes this
Steffen Schreiber May 5, 2023

@Bhavesh Prajapati

If you remove a commit which was commited already, the chain of predecessor and successor commit (id) (or HEAD) would be invalid. This "-f"/"--force" will trigger a rebase of your targeted branch.

Steffen Schreiber May 5, 2023

If you want to remove serveral commits which are not your latest ones you case use the (interactive) rebase:

$ git rebase -i HEAD~20

Use this to modify one/multiple/all last 20 commits.

$ git rebase -i <commit-id> 

Use this to modify one/multiple/all back until this commit.

The '-i' will open your default git editor (by default Vim) and will list you all relevant commits. For the use case that you want to delete a commit, replace the "pick" prefix with a "drop" in front of the specific commit id at your listing. Then save the listing and push it to your remote repository using the '--force' argument as decribed by @Alexey Matveev.

Phil Slawson August 29, 2023

be careful using this with branches.  It made a complete mess of my repository.  I commited to the wrong branch, and realized I needed to roll that one back.  First, I commited my changes to the correct branch, then I went back to the original branch, and attempted to use these commands to fix it.  Now the head of both branches are in the same, hodgepodge state with some files at the former commit, and some at the most recent (which was supposed to be deleted).  Lost a bunch of work.

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events