If you're using vi, just mash "d" repeatedly until the lines are gone 🙃 If you want to abort at any time, delete all the lines listed above the commented section (those starting with "#") to force the rebase to error out. This will save the rebase file you just edited
It's simple from here to drop all of our commits. This is a shorthand for -interactive, which allows you to edit each commit individually from the head to our specified commit hash.
To start the process, type the following: git rebase -i COPIED_COMMIT_HASH^ Rather than making a revert commit, you can modify the commit history directly using a rebase. Note: Read the disclaimer at the end of this section before going with this option. Still, you might want to change your commit history entirely so it appears those nasty commits were never there. Otherwise, you would end up submitting a revert commit for each one individually. This is useful when reverting several commits deep since it allows you to submit one large revert commit at the end. You can also add the -no-commit flag to stage each revert without actually creating a revert commit. If everything looks as expected, type ":wq" to confirm the reverts. Worth warning that this will open a confirmation file in vi (assuming you're using the default git editor) for each commit being reverted. This works well since you should be able to push your changes and have a clean change log as intended. Note that doing so will create a new commit meant to revert all changes made down to the commit specified. This is very straightforward: git revert COPIED_COMMIT_HASH. The first option is the most obvious one: run the revert command onto the commit hash we're reverting to. If you scroll through this and everything looks good, it's time to obliterate those commits! Step 4 Option 1: Run a commit revert (recommended) Otherwise, the diff will stop one commit early. This makes sure we diff down to the ancestor of that commit hash. So, everything in green is what will be added after reverting, and everything in red will be removed.Īlso note the ^ at the end there. Note this is from the perspective of changing from our most recent commit to the commit we're reverting to. Next, we see a line-by-line breakdown of lines added and removed from each modified file. In this case, the the resolution of a few images were updated. These files are often editor / build specific files (as in. First, we see a log of all binary files changed, with paths listed as a/file_path and b/file_path. To do so, use the copied hash and run the following command: git diff HEAD COPIED_HASH^ This is very vim so I don't blame you if you got stuck here 😛 Step 3: Diff against the most recent commitĬhecking for differences against your revert point is a great way to verify what changes you're about to make. Note: You can exit this log by hitting the "q" key.
#Git revert last commit code#
Once you find the inflection point for your code explosion, copy the hash for that commit and move on to the next step. These are hashes which uniquely identify a given commit. It also shows branch points to see the history of everything that got merged.Īlso notice the alphanumeric strings to the left of each commit.
This will show all of the commit history for your branch, starting with the most recent.
The cleanest way to do so is using: git log -oneline and out through the mouth.Ä«efore doing anything you might regret, it's best to look through all recent commits to pinpoint where you're reverting to. Before frantically flying to the keyboard, just go in through the nose. The best way to overcome your escalating fear that your codebase / world is collapsing around you is deep breathing.
0 kommentar(er)
