Preliminary knowledge

  • A COMMIT for this version has a commit ID,A 40-digit hexadecimal numberAccording to the SHA1 calculation, different files can calculate different SHA1 values (there is a small probability of the same, which can be ignored), so that each submission has its unique ID. Every time a new release is committed, the Git service actually strings them together into a timeline.

  • In Git,HEADThe current version, for example, the HEAD version belongs to e620A6FF0940A8DFF… , thenHEAD^Represents the previous version,HEAD^^The previous version, 100 versions up can be written as HEAD plus 100 consecutive ^, or it can be written as:HEAD~100

  • Git log: This command displays commit logs from the most recent to the most distant.
commit e620a6ff0940a8dff91e0d252f30e4d138ec37be
Author: TangShengqin <[email protected]>
Date: Wed Jan 3 10:35:44 2018 +0800

commit 33342d9870f104719d351539a15e74a1382407ea
Author: TangShengqin <[email protected]>
Date: Wed Jan 3 10:34:03 2018 +0800
Copy the code

Git structures and relationships between operations

  • Git log –pretty=oneline View the committed version

Rolling back the version (Three methods)

Git reset commit_id(uncommit and add)

Git reset defaults to –mixed mode

Git reset --mixed commit_id Undoes commit and add operationsCopy the code

  • Rollback of a version with the contents of the staging area and the local commit (commit) restored to the unstaging state without affecting the original local files (not committed)

  • The source code is retained, but git commit and index information are reverted to a version

Git reset –soft commit_id

  • * Roll back a version without emptying the staging area, and restore the submitted content to the staging area without affecting the original local files (unsubmitted files are also not affected)

  • Save the source code, only back the commit information to a certain version, does not involve the index rollback, if you still need to commit, directly commit

Git reset –hard commit_id

Git reset — hard commit_id or git reset — hard HEAD^

  • Undo the COMMIT and add operations and set the local version back to the previous version

  • Rollback a version, clear the staging area, restore the version of the submitted content to the local, local files will be replaced with the restored version

  • The source code is also reverted to a version, and both commit and index are reverted to a version (note that this is done by changing the local repository source code).

The hard option completely restores workspace, staging, and repository records to the specified repository

Reset and revert

  1. Reset: before the push.
  2. Revert: after a push.
git revert <commit_id.. >Copy the code

Rollback to the top version requires git push after execution

Reset and revert:

Git reset differs from Git Revert.

  • Git reset moves the HEAD back, while Git Revert moves the HEAD forward, but the new commit is the opposite of what you want to revert, and canceles what you want to revert.

  • Git revert allows you to use a new COMMIT to rollback the previous commit. Git reset deletes the specified commit.

  • In the case of rollback, the effect is similar. However, there are differences when continuing to merge older versions before. Because Git revert “neutralizes” previous commits with a reverse commit, this change does not reappear when older branches are merged, but git reset deletes a commit directly from a branch. Therefore, when merging with the old branch again, these rollback commits should be introduced again.

The actual case

The cache code overrides the workspace code

  • Scenario: The cache contains the last code change, i.e., the previous execution:git add

  • If the current working interval code wants to be discarded, it can be overwritten by the code in the cache:

Corresponding instruction:

  • A file in the cache overwrites the local workspace:git checkout -- testReset.txt
  • Overwrite the matching file:git checkout -- *.txt
  • Overwrite all files:git checkout -- .

The local repository code overrides the cache code

  • Scenario: You find that the previous add file is no longer needed, and you do not want to change the working interval back.

Corresponding instruction:

  • Overwrite a file in the cache from the local repository:git reset HEAD testReset.txt
  • Overwrite the cache with a matching file:git reset HEAD *.txt
  • Overwrite all files in the cache:git reset HEAD .

Note: It is the cache code that has changed, the working interval code remains the same (the editor code does not change)

Local repository code overwriting workspace code (common)

These two scenarios are less common in real development, followed by local repository code overwriting working interval code.

Scenario: The current working interval code is chaotic (generally after updating or merging branches), and the current change is discarded;

Corresponding instruction:

  • Git checkout HEAD testreset.txt

  • Git checkout HEAD overwrites the local workspace with all files from the local repository.

Commit list (); commit list (); commit list ();

  • Git commit id, git commit record
git log 
git log --pretty=oneline 
Copy the code
  • View previous commit history (including undo rollback records)
git reflog 
Copy the code

 

According to the COMMIT list, the work interval code allows for more flexible fallbacks:

  • Local working interval code reverts to previous version, previous version, and previous 10 versions
git reset --hard HEAD^ 
git reset --hard HEAD^^ 
git reset --hard HEAD~10 
Copy the code
  • Rollback of the local working interval code to the specified version (” D362816 “is the commit ID)
git reset --hard d362816 
Copy the code

Remote repository code overwrites local repository code (clears unpushed commit)

Scenario: Sometimes merging branches, switching branches, and updating code can lead to messy commits (not using –rebase). This is reflected in automatic commit generation and conflicting work interval code. Align the working interval code with the online code and remove the newly generated COMMIT.

Corresponding instruction:

  • The local working interval code falls back to the remote version
Git reset - hard origin/masterCopy the code

Remote repository code rollback (online code rollback)

Scenario: COMMIT a commit (the commit contains many files), find a problem, need to roll back, the online branch (master) to the last commit;

Use git reset or Git Revert to rollback.

Git reset

Git Revert

We can usegit revertReplace the new COMMIT; (don’tgit resetwithgit revertThe reason is to keep the COMMIT to facilitate subsequent code recovery.

Corresponding instruction:
Git revert HEAD Git commit -m "Rollback of the last commit" git push origin masterCopy the code
  • Git revert HEAD: To revert a recent commit, you can use the revert command to revert the latest commit

Summarize the case

git log --pretty=oneline
Copy the code

If you make a wrong commit locally, the way to roll back the version is simple

Start by finding the commit ID of the version you want to rollback with the following command:

git reflog
Copy the code

Then back to version:

git reset --hard a7e1d279a7e1d279
Copy the code

This is the first few digits of the commit ID of the version you want to roll back.

Remote branch version rollback method

If your error commit has already been pushed to your remote branch, then you need to roll back the remote branch.

First we roll back the local branch:

git reflog 
git reset --hard Obfafd
Copy the code

Then force push to remote branch:

git push -f origin master 
Copy the code

  • Origin is a name that Git creates by default when you clone a repository hosted on Github. Origin refers to repository, and Master is the first branch created in the repository by default.

  • Because origin and master are created by default when you git push, you can omit them like this.

Note: After the rollback, the version of the local branch will lag behind that of the remote branch. You must use force push to override the remote branch; otherwise, it cannot be pushed to the remote branch