How to abort commit git

I accidentally amended my previous commit. The commit should have been separate to keep history of the changes I made to a particular file.

(I have not yet pushed to any remote directories)

12 Answers 12

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

you should then have all your previously amended changes only in your working copy and can commit again

to see a full list of previous indices type git reflog

1 is exactly the same as HEAD^ and identifiers the parent of the current commit. HEAD@ <1>on the other hand refers to the commit which HEAD pointed to before this one, i.e. they mean different commits when you checkout a different branch or amend a commit.

Find your amended commits by:

then reset your HEAD to any previous commit at the point it was fine by:

Then cherry-pick the other commit that you need on top of it:

None of these answers with the use of HEAD@ <1>worked out for me, so here’s my solution:

Your staging environment will now contain all of the changes that you accidentally merged with the c296452 commit.

If you have pushed the commit to remote and then erroneously amended changes to that commit this will fix your problem. Issue a git log to find the SHA before the commit. (this assumes remote is named origin). Now issue these command using that SHA.

You can always split a commit, From the manual

How to un-commit last un-pushed git commit without losing the changes

This has not been pushed, only committed.

9 Answers 9

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

There are a lot of ways to do so, for example:

in case you have not pushed the commit publicly yet:

That’s it, your commit changes will be in your working directory, whereas the LAST commit will be removed from your current branch. See git reset man

In case you did push publicly (on a branch called ‘master’):

revert commit normally and push

1′: unknown revision or path not in the working tree

If you pushed the changes, you can undo it and move the files back to stage without using another branch.

It will create a patch file that contain the last branch changes. Then it revert the changes. And finally, apply the patch files to the working tree.

This will «uncommit» your changes and return your git status to the point before your last local commit. You will not lose any changes you made.

2020 simple way :

Commit hash of the last commit you want to keep.

The easiest way to undo the last Git commit is to execute the git reset command with one of the below options

Let’s assume you have added two commits and you want to undo the last commit

–soft option undo the last commit and preserve changes done to your files

–hard option undo the last commit and discard all changes in the working directory and index

—mixed option undo the last commit and keep changes in the working directory but NOT in the index

New Update for fellow googlers from 2021 onwards.

Here is a modern way to undo your last commit if you are a VSCode user.

All it does is it restores your repository just as it was before you made the commit, with your changes untouched.

With me mostly it happens when I push changes to the wrong branch and realize later. And following works in most of the time.

PLease make sure to backup your changes before running these commmand in a separate folder

git checkout branch_name

Check status of the code after aborting the merge

these command will reset your changes and align your code with the branch_name (branch) code.

Adding steps I followed hoping that it’s helpful for a beginner like me.

Following picture shows the commits I have already pushed to the remote branch ‘A‘ in bitbucket.

From these 5 commits, I want to keep the last 2 as it is, but the first 3 commits I want them pushed to another branch ‘B‘.

These are the steps I followed:

Inside branch ‘A‘:

After the push, this is how it looked like:-

Inside branch ‘B‘:

I simply cherry-picked the commits I wanted to branch ‘B‘. In my case I did:

for those 3 commits I reverted.

(Again, as an example, git cherry-pick d4a3734 where d4a3734 is the commit hash of the last commit in the picture)

Операции отмены

В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.

Эта команда использует область подготовки (индекс) для внесения правок в коммит. Если вы ничего не меняли с момента последнего коммита (например, команда запущена сразу после предыдущего коммита), то снимок состояния останется в точности таким же, а всё что вы сможете изменить — это ваше сообщение к коммиту.

Запустится тот же редактор, только он уже будет содержать сообщение предыдущего коммита. Вы можете редактировать сообщение как обычно, однако, оно заменит сообщение предыдущего коммита.

Например, если вы сделали коммит и поняли, что забыли проиндексировать изменения в файле, который хотели добавить в коммит, то можно сделать следующее:

В итоге получится единый коммит — второй коммит заменит результаты первого.

Очень важно понимать, что когда вы вносите правки в последний коммит, вы не столько исправляете его, сколько заменяете новым, который полностью его перезаписывает. В результате всё выглядит так, будто первоначальный коммит никогда не существовал, а так же он больше не появится в истории вашего репозитория.

Очевидно, смысл изменения коммитов в добавлении незначительных правок в последние коммиты и, при этом, в избежании засорения истории сообщениями вида «Ой, забыл добавить файл» или «Исправление грамматической ошибки».

Отмена индексации файла

Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге. Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам как отменять изменения в них. Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду git add * и добавили в индекс оба. Как исключить из индекса один из них? Команда git status напомнит вам:

Прямо под текстом «Changes to be committed» говорится: используйте git reset HEAD …​ для исключения из индекса. Давайте последуем этому совету и отменим индексирование файла CONTRIBUTING.md :

Команда выглядит несколько странно, но — работает! Файл CONTRIBUTING.md изменен, но больше не добавлен в индекс.

Отмена изменений в файле

В выводе команды из последнего примера список изменений выглядит примерно так:

Здесь явно сказано как отменить существующие изменения. Давайте так и сделаем:

Как видите, откат изменений выполнен.

Если вы хотите сохранить изменения в файле, но прямо сейчас их нужно отменить, то есть способы получше, такие как ветвление и припрятывание — мы рассмотрим их в главе Ветвление в Git.

Отмена действий с помощью git restore

Отмена индексации файла с помощью git restore

Файл CONTRIBUTING.md изменен, но снова не индексирован.

Откат измененного файла с помощью git restore

Он довольно недвусмысленно говорит, как отменить сделанные вами изменения. Давайте сделаем то, что написано:

Важно понимать, что git restore — опасная команда. Любые локальные изменения, внесенные в этот файл, исчезнут — Git просто заменит файл последней зафиксированной версией. Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения.

How to abort commit git

Check your version of git by running

SYNOPSIS

DESCRIPTION

…​ git reset [-q] [—pathspec-from-file= [—pathspec-file-nul]] [ ]

These forms reset the index entries for all paths that match the

to their state at . (It does not affect the working tree or the current branch.)

This means that git reset

is the opposite of git add

After running git reset

Interactively select hunks in the difference between the index and (defaults to HEAD ). The chosen hunks are applied in reverse to the index.

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

Resets the index and working tree. Any changes to tracked files in the working tree since are discarded. Any untracked files or directories in the way of writing any tracked files are simply deleted.

See «Reset, restore and revert» in git[1] for the differences between the three commands.

OPTIONS

Be quiet, only report errors.

Refresh the index after a mixed reset. Enabled by default.

Do not interpret any more arguments as options.

Limits the paths affected by the operation.

For more details, see the pathspec entry in gitglossary[7].

EXAMPLES

Somebody asks you to pull, and the changes sound worthy of merging.

Then you can pull and merge, leaving frotz.c and filfre.c changes still in the working tree.

This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before «reset».

Make corrections to working tree files.

Rewind the master branch to get rid of those three commits.

Switch to topic/wip branch and keep working.

2 ) were bad and you do not want to ever see them again. Do not do this if you have already given these commits to somebody else. (See the «RECOVERING FROM UPSTREAM REBASE» section in git-rebase[1] for the implications of doing so.)

Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later.

Merge a topic branch into the current branch, which resulted in a fast-forward.

Even if you may have local modifications in your working tree, you can safely say git pull when you know that the change in the other branch does not overlap with them.

Suppose you are interrupted by an urgent fix request while you are in the middle of a large change. The files in your working tree are not in any shape to be committed yet, but you need to get to the other branch for a quick bugfix.

This commit will get blown away so a throw-away log message is OK.

This removes the WIP commit from the commit history, and sets your working tree to the state just before you made that snapshot.

At this point the index file still has all the WIP changes you committed as snapshot WIP. This updates the index to show your WIP files as uncommitted.

Suppose you have added a file to your index, but later decide you do not want to add it to your commit. You can remove the file from the index while keeping your changes with git reset.

This removes the file from the index while keeping it in the working directory.

This commits all other changes in the index.

Adds the file to the index again.

Suppose you are working on something and you commit it, and then you continue working a bit more, but now you think that what you have in your working tree should be in another branch that has nothing to do with what you committed previously. You can start a new branch and reset it while keeping the changes in your working tree.

You can repeat steps 2-4 multiple times to break the original code into any number of commits.

Once again, check to verify that you’ve included what you want to. You may also wish to verify that git diff doesn’t show any remaining changes to be committed later.

How to Undo Changes in Git with Git Undo Commit

November 25, 2020

Stay connected

Time Travel in Your Project: Undo Changes with Git

In life, undoing our mistakes is something we’ve always wished was possible. While life might not always present us with a chance to undo our mistakes, Git provides us ample opportunities to do just that. Lucky us! Undoing things in Git isn’t just for mistakes. There are many other valid reasons you’d want to travel in time between different versions of a project. For example, maybe you’re working on a new feature that isn’t ready yet, and then you need to rollback to a previous commit.

In this post, we’ll explore ways to undo changes in Git. So, next time you think you’ve made a commit in error, you’ll have no reason at all to panic. As you know, Git stores snapshots of a repo at different points and then creates a timeline history. We’ll be taking advantage of this timeline to move back and forth as we please. Let’s jump right into it!

To make this post practical and relatable, I’ll be creating a new git folder to use as a demo. I advise you do the same so you can easily follow along. We’ll be doing everything from the terminal, so get ready to do some typing.

Setting Things Up

From my terminal, I’ll run the following commands to create the repo folder, add some files and create some commits to work with:

Now, we have a repo set up with one file added and one commit in the git history. Let’s add a few more files with separate commits so we can have more commits to work with.

Checking Git History

To be able to travel back and forth in time, we need a way to know where we are. We also need a list of possible places and times we can travel to. And that’s where the Git history comes in handy. There are two major ways to view the git history of a repo: git reflog and git log. While these two commands serve a similar purpose (viewing history), there are subtle differences in how they work and the result they show. Either of the two will serve us just fine, however, for the scope of this tutorial. So let’s use git reflog. To read more about their differences, check out this StackOverflow answer. When you run the git reflog command, you should have something like this:

Git reflog shows a list of all commits that have been made in this repo, as well as some other key events, like when switching between branches (checkout). Each commit is identified by a SHA-1 hash (before the commit message). You can use these SHA-1 IDs to travel to any commit whenever you want.

Undoing Uncommitted Changes

The first approach we’re going to look at in undoing changes is how to undo changes you’ve made but not yet committed. Whether you’ve staged these changes or not, what matters is that you haven’t committed them. Let’s make some changes to the third file we created earlier (page3.txt).

echo «making some changes to page3» > page3.txt

After running the above command, run git status. You should see something like this:

Let’s assume you made the above change in error. Luckily, you realized the problem before making the commit. Now you want to restore the repo to how it was before you made the change. There are three ways to go about it:

git stash : The git stash command will discard all your untracked files, as well as staged and unstaged modifications. However, Git will temporarily save them, in case you want to retrieve them later.

Which option is best? I mostly use git stash because I can reapply the discarded changes later. When I’m absolutely sure I won’t ever need those changes, I use one of the other options.

Undoing Committed Changes (Git Reset)

Now, let’s assume you didn’t realize you made an error before you committed. Fret not! You can easily go back to a previous commit from where you’re sure there’s no error. Let’s create a new page and commit it to see how to do this.

We want to restore our repo to when we had just three pages. Here’s how to do that:

Run git reflog to see a history of all commits made.

Then note down the ID (SHA-1 hash) of the commit we want to go back to.

Undoing Your Last Commit

A Note on Shared Repos

The three undo methods we’ve looked at above are best applied to local repos you’re working on alone, when you haven’t pushed your commits to a remote repo. A shared repo introduces a different dynamic to how you undo changes. Beyond Git, it’s important that you communicate with other members sharing the repo so they’re all aware and on the same page as you. One thing to consider when working on a shared repo is to use git branches for your local work. That way your work doesn’t interfere with the main branch. You merge into the main shared branch only when you’re sure your work contains no errors. That said, what if for any reason you have to do a git reset on a shared branch and you try to git push? Git will refuse the push, complaining that your local copy is out of date and missing some commits.

Undoing Changes in a Shared Repo

Recap of All Commands

Let’s do a quick summary, since we’ve covered a lot in this post.

Use Git reflog to check commits history.

Git stash lets you discard changes and save them for later reuse.

Now you’ve seen the various methods Git provides for undoing changes. The next time you need to time travel in your project and undo things, always remember that Git has you covered. Check out the CloudBees blog to learn more about Git, GitOps, Git Switch Branch, Advanced Git with Jenkins and much more.

Stay up to date

We ‘ ll never share your email address and you can opt out at any time, we promise.