How to delete commit from github

How to completely delete a commit from GitHub?

On GitHub, I forked a repositary and cloned on my PC. Then, for testing purpose, I edited a file, made a commit and pushed it to GitHub. But now I would like to completely delete this commit.

I did the following:

It looked OK, but my commit was still accessible on GitHub by URL with SHA1 of my commit. So I deleted the repositary on GitHub, then the URL was saying Not Found.

But if I fork the same repositary again, my commit is again accessible by this URL. Please help me, how the hell I can get rid of this commit?

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

This has worked for me:

I have reset the head to the number of commits back by 2

and force pushed my branch to remote by

I could not see any traces of the commits on remote repo.

it’s important to note that those commits may still be accessible in any clones or forks of your repository, directly via their SHA-1 hashes in cached views on GitHub, and through any pull requests that reference them.
You can’t do anything about existing clones or forks of your repository, but you can permanently remove all of your repository’s cached views and pull requests on GitHub by contacting GitHub Support.

In your case, there was (hopefully) no fork/clone, but you have to contact GitHub support to request a gc on their version of the repo, in order for the commit to not be anymore available through its SHA1 URL.

Not the answer you’re looking for? Browse other questions tagged git github or ask your own question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

How to Remove a Commit From Github

Anthony Heddings is the resident cloud engineer for LifeSavvy Media, a technical writer, programmer, and an expert at Amazon’s AWS platform. He’s written hundreds of articles for How-To Geek and CloudSavvy IT that have been read millions of times. Read more.

If you accidentally committed something you shouldn’t have, and pushed it to Github, there are still ways to delete or modify it. Usually, you don’t want to mess with Git’s history, but in some cases it can be safe when done properly.

Don’t Do This If You Can Avoid It

Removing commits from Git’s history is generally a bad idea. Git is meant to track every version of your files, and there’s always alternatives to deletion, like git revert, that will keep the history intact.

Once it’s on a remote repository, like Github, it’s much harder to get rid of the commit entirely. This is because anyone else using the repo will have their own local copy of that repo, and forcibly deleting a commit will make them go out of sync.

There are still a few reasons to do this though—maybe you accidentally committed private data to a public repo, which would still be visible in the history no matter what you do. It’ll cause some issues for your coworkers, but even in this case it’s possible with a force push.

Fixing Commits Locally

If you haven’t pushed to Github yet, you can revert the most recent commit with a soft reset, which doesn’t effect your local files at all, but makes it so that you never committed the changes to Git in the first place.

If you just want to add a new file/change to the most recent commit, Git has a flag built in to do exactly that:

Reverting (Github Safe)

If you want to undo the changes from a commit you already pushed to Github, the safe way to do that is with a revert. Reverting will generate an “opposite commit,” which will basically undo all the changes from a specific commit. If you added a line, it’s removed, and if you deleted a file, it’s added back.

This is safe because it doesn’t change the history, only adds new history on top of it. You can push the revert commit to Github, and have your coworkers run git pull to get the updates.

First, run git log to get a list of commits:

Then, copy the SHA1 hash and revert the commit:

Force Reset (Unsafe)

If you really want to remove a commit, the method to do that is to remove it locally, and then force push to Github. Since this is very dangerous and can mess up your coworker’s local repositories, if you still want to, you may have to disable force push branch protection in Github’s repository settings:

Then, you can remove the commit locally, which is easiest if it’s the latest commit:

You can also do an interactive rebase, which is useful if the commit isn’t the most recent one. If the commit was, for example, 12 commits ago, you can rebase from then, remove the offending commit, and save.

Once your local repo is in working order, you can force push to Github.

Make sure your repo is up to date! If the remote branch has changes that you don’t, they will be overwritten by this push.

You may want to coordinate this with your team members, as you may have to ping them and tell them to run a fetch and reset:

Moving a Commit to a Different Branch

If you accidentally committed to the wrong branch, and want to remove the commit and move it to the correct branch, there are tools in Git to handle that. You can read our guide to moving commits around to learn more, but the same principles apply—if you need to completely remove a commit, you must force reset. If you’re fine with reverting, you can simply revert and cherry-pick.

How to git remove commit PROPERLY [Practical Examples]

Table of Contents

Getting started with git remove commit

There are many ways to achieve git remove commit. You can pick the best solution depending on the challenge you are facing. For instance, do you want to remove

Interactively rebase the branch

where N is the number of commits from the head

The challenging part about understanding git remove commits lies in having inadequate knowledge of git workflow, the reset command and branching. Here is what you should know about the three things.

Three things to understand before applying git remove commit

Git remove commit often involves the working tree, reset command and branching.

1. The working tree

Basic git workflow entails the working directory, the index and commit history. You only interact with workflow when tracking file changes. Otherwise, your project’s files and folders reside in the untracked parent directory.

Running the command git

to the parent folder takes a snapshot of the files to the index, also called the staging area.

From there, you can permanently store the changes in the git database using unique hashes called commit or history. The latest commit in the history or the one you view intending to modify is called the HEAD.

You can undo git changes at the three levels:

Since we start interacting with commit hashes past the staging area, most git remove commit actions will touch the HEAD or commit hash. The most typical commands to use then are git reset and git revert.

2. The reset command

Reset is the most familiar command to git remove commit. It occurs in three states: hard, soft and mixed. Git reset soft alters the HEAD commit, while git reset mixed unstages a file. Git reset hard entirely removes a commit from the history and deletes the associated files in the working directory.

Since deleting a commit history may cause conflict between local (not pushed) and remote (pushed) repos, it would be best to use the revert command instead of git reset to undo changes you plan to push.

3. Git branching

Other times you want to git remove commits in a different branch. A branch is a single development line. The initial branch is often referred to as the master or main.

Several developers, working on various features of the same project, can create branches, handle tasks in the branches and merge the changes back to the main branch.

While modifying the branches, the developers do commits, most of which you (as the main branch manager) are not interested in.

So, you want the commits removed at the branch level. Git rebase or merge can help restructure the history, as you will see in the practical part of this tutorial.

Lab setup to practice git remove commit

I am creating a repo called git_remove_commit on Github.

Copy the URL, clone it on the command line and cd into the repo.

We have one commit created from Github by adding the README.md file.

Add two commits in the history.

Rechecking the history

shows we have three commits to practice git remove commit from branch, last commit, or a bunch of commits.

Git remove the last commit by resetting the HEAD

It is simple to remove the last commit in history. You can reset HEAD by running the command

Git remove commit from branch

before push

We can git remove commit through interactive rebase or by squashing it.

Let us create and checkout a branch called rebased

Create three commits.

We have three new commits. Let us check out the main branch.

We lack the rebased branch’s commits

Let us update the changes in the main branch by rebasing the rebased branch.

We can remove the last three commits by interactively rebasing them.

Our default text editor opens up.

Change the first two (from the bottom) pick with squash options.

Then close the text editor.

The text editor reopens, asking for a commit message.

I am commenting out the available messages and supplying it the message, «from rebased branch«

Rechecking the history

shows our git remove commits mission on the three commits was successful, and we now have a new commit.

after push

You are free to delete the last commit from git remove from a branch before push section or proceed with it.

Let us git remove commit from branch after push by switching to rebased branch, then push the branch’s three commits to create a branch in the remote.

We will then push changes before merging the branch on the command line.

Check remote and compare & pull request the changes until the commits are reflected below.

Check out the main branch and merge the rebased branch.

Recheck the remote. The last three commits named first.. second.. third commit in rebased branch disappeared.

Git remove commit from branch by clearing the history

Lastly, you may want to remove the only commit you have or git remove the first commit in the history. Either way, the following commands will serve you.

clears all the commits and takes the changes to the staging area.

Let us commit the changes before clearing the repo.

Checking the status

confirms we removed the repo with all the commits!

Summary

You can git remove commit by resetting the head, squashing the commits on a branch, or clearing the commit history. However, you should understand the working tree, reset, and branching before that.

Use the following commands to remove target commit(s) respectively:

Related Posts

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

silent1mezzo / 0fixup.md

A git choose-your-own-adventure!

This document is an attempt to be a fairly comprehensive guide to recovering from what you did not mean to do when using git. It isn’t that git is so complicated that you need a large document to take care or your particular problem, it is more that the set of things that you might have done is so large that different techniques are needed depending on exactly what you have done and what you want to have happen.

If you have problems after clicking through this document, please document what the links you clicked on are when asking for further help (on #git or elsewhere) which will explain very precisely what you were trying to do and that you at least tried to help yourself. Sorry, due to the limitations of github we cannot gather the history for simple copy-paste.

Answer the questions posed by clicking the link for that section. A section with no links is a terminal node and you should have solved your problem by completing the suggestions posed by that node (if not, then report the chain of answers you made on #git or some other git resource and explain further why the proposed answer doesn’t help). This is not a document to read linearly.

Due to previous activities (thrashing about), you may have lost some work which you would like to find and restore. Alternately, you may have made some changes which you would like to fix.

If you have not yet committed that which you do not want, git does not know anything about what you have done yet, so it is pretty easy to undo what you have done.

So you have not yet committed, the question is now whether you want to undo everything which you have done since the last commit or just some things?

So you have not yet committed and you want to undo some things, well git status will tell you exactly what you need to do. For example:

So you have committed. However, before we go about fixing or removing whatever is wrong, you should first ensure that any uncommitted changes are safe, by either committing them ( git commit ) or by stashing them ( git stash save «message» ) or getting rid of them. git status will help you understand whether your working directory is clean or not.

So you have committed, the question is now whether you have made your changes publicly available or not. Publishing history is seminal event.

Also note that these commands will fix up the referenced commits in your repository. There will be reflog’d and dangling commits holding the state you just corrected. This is normally a good thing and it will eventually go away by itself, but if for some reason you want to cut your seat belts, you can expire the reflog now and garbage collect with immediate pruning.

There is a shortcut in case you want to discard all changes made on this branch since you have last pushed or in any event, to make your local branch identical to «upstream». Upstream, for local tracking branches, is the place you get history from when you git pull : typically for master it might be origin/master. There is a variant of this option which lets you make your local branch identical to some other branch or ref.

If instead of discarding all local commits, you can make your branch identical to some other branch, tag, ref, or SHA that exists on your system.

Once you have found the correct state of your branch, you can get to that state by running

Obviously replace «ref» in both commands with the reference or SHA you want to get back to.

While the techniques mentioned to deal with deeper commits will work on the most recent, there are some convenient shortcuts you can take with the most recent commit.

2 to remove the last two commits. You can increase the number to remove even more commits.

To update the last commit’s contents, author, or commit message for a commit which you have not pushed or otherwise published, first you need to get the index into the correct state you wish the commit to reflect. If you are changing the commit message only, you need do nothing. If you are changing the file contents, typically you would modify the working directory and use git add as normal.

» shortcuts you may use those.

Obviously replace «SHA» with the reference you want to get rid of. The «^» in that command is literal.

You have not pushed but still somehow want to change all commits in all of git’s history? Strange.

BTW, this is the one command I referred to earlier which will update all tags and branches, at least if you use the best practice arguments.

If the commit you are trying to change is a merge commit, or if there is a merge commit between the commit you are trying to change and the tip of the branch you are on, then you need to do some special handling of the situation.

» shortcuts you may use those.

Obviously replace «SHA» with the reference you want to get rid of. The «^» in that command is literal.

Oh dear. This is going to get a little complicated. It should all work out, though. You will need to use a nonce branch as a placeholder. I will call the nonce branch «nonce» in the following example. However, you may use any branch name that is not currently in use. You can delete it immediately after you are done.

Identify the SHA of the commit you wish to modify.

» shortcuts you may use those.

Remember the name of the branch you are currently on

The line with a star on it in the git branch output is the branch you are currently on. I will use «$master» in this example, but substitute your branch name for «$master» in the following commands.

Create and checkout a nonce branch pointing at that commit.

git checkout nonce SHA

Validate that the topology is still good

Delete the nonce branch

Rewriting public history is a bad idea. It requires everyone else to do special things and you must publicly announce your failure. Ideally you will create either a commit to just fix the problem, or a new git revert commit to create a new commit which undoes what the commit target of the revert did.

If the problem in the old commit is just something was done incorrectly, go ahead and make a normal commit to fix the problem. Feel free to reference the old commit SHA in the commit message, and if you are into the blame-based development methodology, make fun of the person who made the mistake (or someone who recently left if you made the mistake).

The file may have been deleted or every change to that file in that commit (and all commits since then) should be destroyed. If so, you can simply checkout a version of the file which you know is good.

» shortcuts you may use those.

Obviously replace «SHA» with the reference that is good. You can then add and commit as normal to fix the problem.

» shortcuts you may use those.

Obviously replace «SHA» with the reference you want to revert.

Oh dear. This is going to get complicated.

» shortcuts you may use those.

At this time, I will not walk you through the process of recreating the donor branch. Given sufficient demand I can try to add that. However, if you look at howto/revert-a-faulty-merge.txt which is shipped as part of the git distribution, it will provide more words than you can shake a stick at.

If the state of a branch is contaminated beyond repair and you have pushed that branch or otherwise do not want to rewrite the existing history, then you can make a new commit which overwrites the original branch with the new one and pretends this was due to a merge. The command is a bit complicated, and will get rid of all ignored or untracked files in your working directory, so please be sure you have properly backed up everything.

You actually are being provided with two methods. The first set is more portable but generates two commits. The second knows about the current internal files git uses to do the necessary work in one commit. Only one command is different and a second command runs at a different time.

Next, you should probably look in other repositories you have lying around including ones on other hosts and in testing environments, and in your backups.

Practically every git operation which affects the repository is recorded in the git reflog. You may then use the reflog to look at the state of the branches at previous times or even go back to the state of the local branch at the time.

Once you have found the correct state of your branch, you can get back to that state by running

You could also link that old state to a new branch name using

Obviously replace «SHA» in both commands with the reference you want to get back to.

So, you were in the middle of a merge, have encountered one or more conflicts, and you have now decided that it was a big mistake and want to get out of the merge.

So, you were in the middle of a rebase, have encountered one or more conflicts, and you have now decided that it was a big mistake and want to get out of the merge.

Information is not promised or guaranteed to be correct, current, or complete, and may be out of date and may contain technical inaccuracies or typographical errors. Any reliance on this material is at your own risk. No one assumes any responsibility (and everyone expressly disclaims responsibility) for updates to keep information current or to ensure the accuracy or completeness of any posted information. Accordingly, you should confirm the accuracy and completeness of all posted information before making any decision related to any and all matters described.

Copyright ⓒ 2012 Seth Robertson

Creative Commons Attribution-ShareAlike 2.5 Generic (CC BY-SA 2.5)

I would appreciate changes being sent back to me, being notified if this is used or highlighted in some special way, and links being maintained back to the authoritative source. Thanks.

Thanks to the experts on #git and my coworkers for review, feedback, and ideas.

Comments and improvements welcome.

Add them below, or discuss with SethRobertson (and others) on #git

Line eater fodder

Because of my heavy use of anchors for navigation, and the utter lack of flexibility in the markup language this document is written in, it is important that the document be long enough at the bottom to complete fill your screen so that the item your link directed you to is at the top of the page.

How to remove a dangling commit from GitHub?

Yesterday, I pushed to my fork of ConnectBot on GitHub. I pushed once, realized that I hadn’t made the change the way I wanted, redid the commit and pushed again.

Now, GitHub has both commits:

My master branch is only tracking the second commit, but the first commit is still available and is still in my activity feed. How can I remove it to make sure no one accidentally pulls that commit instead of the corrected version?

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Delete the repo or contact GitHub

Deleting the repo and recreating it without the bad commit seems to work if you can afford losing all issues. The data also disappears from the commit API (although push events are still visible). See also: https://stackoverflow.com/a/32840254/895245

you can permanently remove all of your repository’s cached views and pull requests on GitHub by contacting GitHub Support.

Maybe making the repo private will also keep the issues around and get rid of the commit, I’m not sure. You lose starts/forks for sure though. Not sure if after restore the commits will be gone or not. But at least you might be able to keep a private backup of issues.