Code rollback: Reset, Checkout, revert selection Zhongyi Tong edited this page on Dec 8, 2015 • 5 Revisions Pages +
- Home
- 2.1 Quick Guide
- 2.2 Creating a code Warehouse
- 2.3 Save your changes
- 2.4 Checking the warehouse status
- 2.5 Commit before checking out
- 2.6 Rollback Error Modification
- 2.7 Rewrite project history
- 3.2 Keeping in sync
- 3.3 Creating Pull Request
- 3.4 Using Branches
- 3.5 Common Workflow Comparisons
- 4.1 Graphical git commands
- 5.1 Code Merge: merge, rebase selection
- 5.2 Code rollback: Reset, Checkout, revert selection
- Show 4 More pages ...
Clone this wiki locallyClone in Desktop
by Dong ([email protected])
This is a translation based on the original text (by Atlassian). All content on the page is shared by the knowledge sharing-attribution (CC by 2.5 AU) Agreement unless otherwise noted.
git reset
, git checkout
and git revert
are some of the most useful commands in your Git toolbox. They are all used to undo some of the changes in the Code warehouse, and the first two commands can be used not only for submission, but also for specific files.
Because they are very similar, we often get confused and don't know which command to use in any scenario. In this article, we will compare git reset
, and the git checkout
git revert
most common usage. Hopefully you'll be able to use these commands to manage your warehouse when you're finished.
The GIT repository has three main components-working directory, buffer, and commit history. This diagram helps to understand what effect each command has. When you read, keep this picture in mind.
Action at the commit level
The parameters you pass git reset
git checkout
to and determine their scope. If you do not include a file path, these actions take effect for all commits. The SectionTo we are discussing is the submission level operation. Note that git revert
there is no file-level operation.
Reset
At the commit level, reset points the end of one branch to another commit. This can be used to remove some commits from the current branch. For example, the following two commands allow the hotfix branch to rollback two commits backwards.
git checkout hotfixgit reset HEAD~2
The two commits at the end of the hotfix branch now become hoisted commits. That is, the next time Git performs a garbage collection, the two commits are deleted. In other words, if you want to throw away these two commits, you can do so. The reset operation looks like this:
If your changes haven't been shared with others, git reset
it's a simple way to undo those changes. When you develop a feature, you find, "Oops, what did I do?" I should have come back! , reset is like a go-to command.
In addition to operating on the current branch, you can also modify your cache or working directory by passing in these tags:
- --soft– buffers and working directories will not be changed.
- --mixed– default options. The cache is synchronized with the commit you specified, but the working directory is not affected
- --hard– buffers and working directories are synchronized to the commits you specify
It is easy to understand the scope of these tokens as defined git reset
operations.
These tags are often used with the head as a parameter. For example, git reset --mixed HEAD
remove your current changes from the cache, but these changes remain in the working directory. On the other hand, if you want to completely discard the changes you have not submitted, you can use them git reset --hard HEAD
. This is the git reset
two most common uses.
Take extra care when you pass in a commit other than head, because the reset operation overrides the history of the current branch. As the rebase golden Rule says, doing this on a public branch can have serious consequences.
Checkout
You should already be very familiar with the submission level git checkout
. When you pass in a branch name, you can switch to that branch.
git checkout hotfix
The above command does nothing but move the head to a new branch and update the working directory. Because this may overwrite local modifications, git forces you to commit or cache all changes in the working directory, or the changes will be lost when checkout. and git reset
not the same, git checkout
these branches are not moved.
In addition to branching, you can also pass in the submitted reference to checkout to any commit. This is exactly the same as checkout to another branch: moving the head to a specific commit. For example, the following command will be checkout to the currently committed grandfather submission.
git checkout HEAD~2
This is useful for quickly viewing older versions of a project. But if your current head does not have any branch references, then this will cause head separation. This is very dangerous, and if you then add a new commit and then switch to another branch, there is no way to go back to the previously added commits. Therefore, you should create a new branch when adding a new commit to the detached head.
Revert
Revert a commit is revoked and a new commit is created. This is a safe method because it does not rewrite the commit history. For example, the following command finds the second-to-last commit, creates a new commit to undo the changes, and then adds the commit to the project.
git checkout hotfixgit revert HEAD~2
As shown in the following:
git reset
It does not change the present commit history compared to that. Therefore, it can be used on a git revert
public branch and git reset
should be used on a private branch.
You can also use it git revert
as a revocation of changes that have been committed, and git reset HEAD
to undo uncommitted changes.
Like git checkout
, it's git revert
possible to rewrite the file. So git will ask you to commit or cache changes in your working directory before you execute revert.
FILE-level operations
git reset
And the git checkout
command also accepts the file path as a parameter. At this point its behavior is greatly different. It will not be used for the entire commit, and the parameter restricts it to a specific file.
Reset
When a file path is detected, the git reset
buffer is synchronized to the commit that you specified. For example, the following command adds the foo.py in the second-to-last commit to the cache for use by the next commit.
git reset HEAD~2 foo.py
As with the submission level git reset
, we usually use head instead of a specific commit. The run will git reset HEAD foo.py
remove the current foo.py from the cache without affecting changes to foo.py in the working directory.
--soft 、--Mixed and--hard have no effect on the file level git reset
, because the files in the cache are bound to change, and the files in the working directory must be the same.
Checkout
Checkout a file and a file path are git reset
very similar, except that it changes the working directory rather than the cache. Unlike the checkout command at the commit level, it does not move the head reference, which means that you do not switch to another branch.
For example, the following command synchronizes the foo.py in the working directory to the foo.py in the second-to-last commit.
git checkout HEAD~2 foo.py
As with the commit layer, it can be used to check for older versions of the project, but scopes are limited to specific files.
If you cache and submit a checkout file, it has the effect of withdrawing a file back to the previous version. Note that it revokes all subsequent changes to the file, and the git revert
command only revokes changes to a specific commit.
git reset
as well, this command is usually used with head. For example git checkout HEAD foo.py
, the equivalent of discarding foo.py no cache changes. This behavior git reset HEAD --hard
is similar to, but only affects, specific files.
Summarize
You have now mastered all the tools for undoing changes in the Git repository. git reset
, git checkout
and git revert
commands are easy to confuse, but when you think of their different effects on the working directory, cache, and commit history, it's easy to tell which command to use right now.
The following table summarizes the most common usage scenarios for these commands. Remember to check this form often, because you will always use git when you are using it.
Command |
Scope |
Common Scenarios |
git reset |
Submission level |
Discard some uncommitted changes on the private branch |
git reset |
File level |
Remove a file from the cache |
Git checkout |
Submission level |
Switch branches or view older versions |
Git checkout |
File level |
Discard changes in the working directory |
git revert |
Submission level |
Roll back changes in public branch |
git revert |
File level |
(not yet) |
This article is part of "Git-recipes" , click on the catalogue to view all chapters.
If you find the article helpful, please click Star or Forkin the top right corner.
If you find an error, or want to join a collaboration, see Wiki collaboration instructions.
Git code rollback: Reset, Checkout, revert selection