It is not entirely clear what situation you are in.
If the "old" commit means that it is already running on the server, then you would probably be better off to leave everything as it is.
Yes, there will be some unnecessary commit, but you don’t have to do the git rebase (which automatically entails git push -f : and force is usually not welcome in commands).
But as a result, you see the real history of the project as it is and this is also sometimes an important thing.
If you have not yet released it to a remote server despite the old commit, or you are the only user for this git repository (say, a small pet project), then do the git rebase .
If you have a simple linear history (without -noff), then you need to do something like the following.
Give command
$ git rebase -i HEAD~5 pick 44e62cc A pick 95efd4a B pick ea91c6a C pick 99cd517 D pick 008df96 E # Rebase 5c79d06..008df96 onto 5c79d06 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out "~/ansible/test/.git/rebase-merge/git-rebase-todo" 23L, 851C
(I specified a commit via HEAD ~ 5, you can specify the SHA (id) of the previous commit before the one you want to delete)
Delete the entire line pick ea91c6a C - bring the text to the form:
pick 44e62cc A pick 95efd4a B pick 99cd517 D pick 008df96 E
Then exit with saving from the editor.
Then everything is very dependent on the contents of commits D and E.
In the simplest case, you will see a message that the rebase was successful (Successfully rebased and updated refs / heads / master.); In difficult cases, you will have to make corrections to commits that cannot be automatically applied to the working directory.
The simplest example is to understand: a new adsf.txt file was created in commit C, while there is some modification of this file in commit D, and there is nothing to apply the changes to.
On each of the commits that cannot be automatically applied, the git will stop in the Detached HEAD state and will wait for your corrections. Corrected - gave the command git rebase --continue and again continue to apply commits, until you reach the last (and the rebase is over), or again stop at one of the intermediate.
I also described step-by-step actions on rebase in detail: you can read here .
PS Update Here's what else. I didn’t read about "if I change my mind, it's easy to return C" and the instruction above will remove the commit completely and you will not return it after 30 days (or scrubbing git gc ) in any way. If you want to save a commit, you can make a separate backup branch before performing a rebase.