The git revert command is used for undoing changes to a repository's commit history. Other 'undo' commands like, git checkout and git reset, move the HEAD and branch ref pointers to a specified commit. Git revert also takes a specified commit, however, git revert does not move ref pointers to this commit. A revert operation will take the specified commit, inverse the changes from that commit, and create a new "revert commit". The ref pointers are then updated to point at the new revert commit making it the tip of the branch.
The git pull command lets you retrieve changes made to a project from a remote repository and download those changes to your local machine. This operation can be undone using the git reset command. The reset command reverts a repository to a previous point in its history. The log output shows the e2f9a78 and 872fa7e commits no longer exist in the commit history. At this point, we can continue working and creating new commits as if the 'crazy' commits never happened.
This method of undoing changes has the cleanest effect on history. Doing a reset is great for local changes however it adds complications when working with a shared remote repository. Git will assume that the branch being pushed is not up to date because of it's missing commits. In these scenarios, git revert should be the preferred undo method. There is no command to explicitly undo the git pull command.
The alternative is to use git reset, which reverts a repository back to a previous commit. A collaborator has just pushed a commit to the remote version of the project that is stored on GitHub. You can use the git reset command to undo a git pull operation.
The git reset command resets your repository to a particular point in its history. If you made changes to files before running git pull that you did not commit, those changes will be gone. Git reflog will show everything what have been done with git.
There is a concern that git reset --hard will revert everything what is shown in reflog, which sometimes are not goal, eg. You want to revert merge on master branch pulled from origin with bad data , and after that merge you have worked on other branches. Reflog will show every chage on other branches. But git checkout master and git reset --hard will reset only current master branch removing pulled merge from origin.
These three commands, while different, should give you all the tools you need to undo any changes in your Git repository. The git reset, git revert, and git checkout commands can be confusing at times, especially because they are similar, while at the same time being very different. On top of that, the git reset and git checkout commands can also be used to manipulate either commits or individual files. The net effect of the git revert command is similar to reset, but its approach is different. Where the reset command moves the branch pointer back in the chain to "undo" changes, the revert command adds a new commit at the end of the chain to "cancel" changes. The effect is most easily seen by looking at Figure 1 again.
If we add a line to a file in each commit in the chain, one way to get back to the version with only two lines is to reset to that commit, i.e., git reset HEAD~1. Remember that once you add a set of changes to version control using git add, the changed file has been staged. If a changed file has been staged via git add, then you need to use git reset to pull the most recently committed version of the file and undo the changes that you've made. In the previous section, we discussed different strategies for undoing commits. These strategies are all applicable to the most recent commit as well.
In some cases though, you might not need to remove or reset the last commit. In this case you can amend the most recent commit. Once you have made more changes in the working directory and staged them for commit by using git add, you can execute git commit --amend. This will have Git open the configured system editor and let you modify the last commit message. The new changes will be added to the amended commit. Here we have initialized a repo in a newly created directory named git_revert_test.
We have made 3 commits to the repo in which we have added a file demo_file and modified its content twice. At the end of the repo setup procedure, we invoke git log to display the commit history, showing a total of 3 commits. With the repo in this state, we are ready to initiate a git revert. A pull request is just you telling the remote server that you have some updated commits that you would like them to look over and integrate with the remote repository.
Remember, as stated above, Git will take some time to learn and understand. In this article, I will give you some useful information on the git reset, git checkout, and git revert commands. Learning the little Git command differences will definitely help you along the way when it comes to properly using the relevant command at the relevant time. Git reset is essentially the opposite of the command git add. It will undo the git add to remove the changed file from version control, and then you can git checkout to undo the changes from the file. The git checkout command lets you navigate between the branches created by git branch .
Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. This process merges any changes discovered by the git fetch command onto your local machine. This means when you run git pull your local version of a repository will be changed to match the remote repository.
Well, there's a second way that a Git repository can get updated—git pull. You probably do this a lot whenever your coworkers make changes that get pushed. In that case, you're pulling down commits from the remote repository, and syncing it with your local repo. That being said, three of the most useful commands available for you to use are the git reset, git checkout, and git revert commands. These commands can be somewhat similar and you may not understand them fully. That being said, let's take a look at these Git command differences together.
Usually, reverting a merge considered a complicated process. We are going to undo a merge operation with the help of git revert command. Although some other commands like git reset can do it. Why would you choose to do a revert over a reset operation? If you have already pushed your chain of commits to the remote repository , a revert is a nicer way to cancel out changes for them. The preferred method of undoing shared history is git revert.
A revert is safer than a reset because it will not remove any commits from a shared history. A revert will retain the commits you want to undo and create a new commit that inverts the undesired commit. This method is safer for shared remote collaboration because a remote developer can then pull the branch and receive the new revert commit which undoes the undesired commit. Using the git checkout command we can checkout the previous commit, a1e8fb5, putting the repository in a state before the crazy commit happened. Checking out a specific commit will put the repo in a "detached HEAD" state.
This means you are no longer working on any branch. In a detached state, any new commits you make will be orphaned when you change branches back to an established branch. Orphaned commits are up for deletion by Git's garbage collector. The garbage collector runs on a configured interval and permanently destroys orphaned commits.
To prevent orphaned commits from being garbage collected, we need to ensure we are on a branch. Second, git revert is able to target an individual commit at an arbitrary point in the history, whereas git reset can only work backward from the current commit. Needless to say, this is not an elegant undo solution. For a more detailed discussion on the differences between git revert and other 'undo' commands see Resetting, Checking Out and Reverting.
When you use git reset, your changes still exist in the file, but the file has been unstaged (i.e. the changes no longer being tracked by version control). So now, git status will display a message that there are changes that can be added or staged to version control. Reverting a pull request on GitHub creates a new pull request that contains one revert of the merge commit from the original merged pull request. To revert pull requests, you must have write permissions in the repository. When working on a team with remote repositories, extra consideration needs to be made when undoing changes. Git reset should generally be considered a 'local' undo method.
A reset should be used when undoing changes to a private branch. This safely isolates the removal of commits from other branches that may be in use by other developers. Problems arise when a reset is executed on a shared branch and that branch is then pushed remotely with git push. Git will block the push in this scenario complaining that the branch being pushed is out of date from the remote branch as it is missing commits.
The whole idea behind any version control system is to store "safe" copies of a project so that you never have to worry about irreparably breaking your code base. Once you've built up a project history of commits, you can review and revisit any commit in the history. One of the best utilities for reviewing the history of a Git repository is the git log command. In the example below, we use git log to get a list of the latest commits to a popular open-source graphics library. Passing this option will prevent git revert from creating a new commit that inverses the target commit.
Instead of creating the new commit this option will add the inverse changes to the Staging Index and Working Directory. These are the other trees Git uses to manage the state of the repository. When you run the git pull command, Git will check if any changes have been made to a remote repository by running the git fetch command. Then, if changes have been made, the fetch command will retrieve the metadata for those changes. Once you start collaborating with other developer it's going to be important to know how to revert a single file to a certain commit. This need arises because you sometimes need to change files not related to you're pull request in order to test the feature you're working on.
However, manually changing each line of code in those files back to their original state and doing a new commit can lead to a messy commit history. Reverting the file is a much cleaner what to handling it. Now that you have installed and configured Git, you can use it! To use GitHub with your package, you'll need to initialise a local repository, or repo for short.
This creates a .git directory that stores configuration files and a database that records changes to your code. A new repo exists only on your computer; you'll learn how to share it with others shortly. Command instantiates a 'hard deletion' of all changes from now -- or point-in-time of code reversion -- to the designated former code commit. It resets the code tree to the version in question and deletes unstaged files. Similar to the previous example, when you use git reset HEAD~, the modifications will be unstaged, and then you can use git checkout to undo the changes to the file.
If you have committed changes to a file (i.e. you have run both git add and git commit), and want to undo those changes, then you can use git reset HEAD~ to undo your commit. To undo the merge, use git reset --hard to reset the local repository to a previous state; use git-reflog to find the SHA-1 of the previous state and then reset to it. And looking at the point at which you want to undo to. Look at git stash to put all of your local changes into a "stash file" and revert to the last commit.
At that point, you can apply your stashed changes, or discard them. The for loop will delete all tracked files which are changed in the local repo, so git pull will work without any problems. The easiest way to undo the last Git commit is to execute the "git reset" command with the "–soft" option that will preserve changes done to your files. You have to specify the commit to undo which is "HEAD~1" in this case.
The last commit will be removed from your Git history. To undo the merge, use git reset –hard to reset the local repository to a previous state; use git-reflog to find the SHA-1 of the previous state and then reset to it. As it does with regular commits, Git creates merge commits with a commit hash representing the point in history where the other branch was merged in. We can use this information to run the git revert command to restore your branch to the state that it was in previously.
The git revert command will have generated a commit that restores your branch's state to where it was before the faulty merge. If your merge was remote (i.e. happened on GitHub) you can push this commit like any other and you'll be set to go. If you notice an error in a specific commit that has already been pushed, you can revert that commit.
This operation results in a new commit that reverses the effect of the commit you want to undo. Thus, project history is preserved, as the original commit remains intact. The working directory is generally in sync with the local file system. To undo changes in the working directory you can edit files like you normally would using your favorite editor. Git has a couple utilities that help manage the working directory.
There is the git clean command which is a convenience utility for undoing changes to the working directory. Additionally, git reset can be invoked with the --mixed or --hard options and will apply a reset to the working directory. From the detached HEADstate, we can execute git checkout -b new_branch_without_crazy_commit.
This will create a new branch named new_branch_without_crazy_commit and switch to that state. The repo is now on a new history timeline in which the 872fa7ecommit no longer exists. At this point, we can continue work on this new branch in which the 872fa7ecommit no longer exists and consider it 'undone'. Unfortunately, if you need the previous branch, maybe it was your mainbranch, this undo strategy is not appropriate. For more information and examples review our in-depth git checkoutdiscussion. Reverting has two important advantages over resetting.
