[git undo, delete and version rollback]

Knowledge points:

1. git status, view the status of the git warehouse
2. git diff view the modified content of git
3. The version pointed to by HEAD is the current version. Use the git reset --hard commit_id command to return to the specified version
4. View the commit through git log History and git reflog View command history, determine rollback or restore to a certain version.
Original text link:
https://www.cnblogs.com/codemissing/p/git_version_back.htmlCheck
the status of the git warehouse
Modify the content of the readme file and add a line of content.

  • Run git status to view status
    liu@liu-virtual-machine:~/gitTest$ git status
    is on branch master
    Changes not yet staged for commit:
    (Use "git add <file>..." to update the content to be committed)
    (Use " git checkout - <file>..." to discard workspace changes)

      修改:     readme.txt
    

The modification has not been added to the submission (use "git add" and/or "git commit -a"). The
git status command can view the current status of the warehouse. The above shows that the readme.txt file has been modified, but the content of the submission modification has not yet been added.

  • git diff can check what has been modified, so that you can clearly know what was modified last time, as follows
    liu@liu-virtual-machine:~/gitTest$ git diff diff
    --git a/readme.txt b/readme .txt
    index 90269eb…7d0ff65 100644
    — a/readme.txt
    +++ b/readme.txt
    @@ -1,4 +1,4 @@

`this is a test that I learning and use git version control system
this is a beginning
-wofaidognyixie dognxi
+i Add a new line information in the end of readme.txt file
before modifying the last line I added and submitted a line wofaidognyixie dognxi, Now modify it to i Add a new line information in the end of readme.txt file, which is equivalent to deleting and adding. git diff View different content, the result shows the comparison before and after modification.

  • git add readme.txt to add modifications, check the status of the warehouse at this time, prompt: the change to be submitted is readme.txt
    liu@liu-virtual-machine:~/gitTest$ git status
    is located in the branch master
    Change to be submitted:
    (use "git reset HEAD <file>…" to unstage)

      修改:     readme.txt
    
  • git commit and git status Submit and view the current warehouse status
    liu@liu-virtual-machine:~/gitTest$ git commit -m “add a new line in readme.txt”
    [master e181953] add a new line in readme.txt
    1 file changed, 1 insertion(+), 1 deletion(-)
    liu@liu-virtual-machine:~/gitTest$ git status
    is located in branch master
    No files to commit, clean workspace
    shows no changes to commit, clean work area, (working directory clean)
    view history.
    For a version control system, it is important that we can view the history so that we know what was modified and submitted each time.

  • git log View modification history
    git log displays the commit log from the latest to the farthest, and the author, date and commit information of each commit are displayed.

  • If too much information is displayed, add –pretty-oneline
    liu@liu-virtual-machine:~/gitTest$ git log --pretty=oneline
    e181953c3f43e15ceee10fb86f05fd4568265127 add a new line in readme.txt
    1769dcb57a1b16d3c4ed7f9 6828af2f1131f5882 modify
    d5b84bff04a672d9f520334d42e71a3e79910f17 modifya readme file
    3033dda882f53ea249d6dacd4c39c470fab700e8 add a In the readme file,
    each log record is displayed on one line at this time.
    The string of alphanumerics in front of each line is the commit id (version number). Unlike svn, the commit id of Git is not an incremental number of 1, 2, and 3, but a very large number calculated by SHA1, expressed in hexadecimal. Why does the commit id need to be represented by such a large string of numbers? Because Git is a distributed version control system, we will study how many people work in the same version library later. If everyone uses 1, 2, 3... as the version number, then there must be a conflict.
    Git strings each commit into a timeline.
    version rollback

  • git first needs to know which version the current version is. In Git, HEAD is used to indicate the current version, that is, the latest submitted e181...5127 above. The previous version is HEAD, and the previous version is HEAD ^. When going up 100 versions, it is written as HEAD~100

  • git reset --hard HEAD^, roll back the current version "add a new line in readme.txt" to the previous version "modify", as follows:
    iu@liu-virtual-machine:~/gitTest$ git reset --hard HEAD^
    HEAD is now located at 1769dcb modify
    to view the content of readme.txt is already the modified version,
    at this time use git log to view the history record
    liu@liu-virtual-machine:~/gitTest$ git log
    commit 1769dcb57a1b16d3c4ed7f96828af2f1131f5882
    Author: findmoon 12866 [email protected]
    Date: Tue Feb 20 13:37:05 2018 +0800

    modify

commit d5b84bff04a672d9f520334d42e71a3e79910f17
Author: findmoon [email protected]
Date: Tue Feb 20 12:55:06 2018 +0800

modifya readme file

commit 3033dda882f53ea249d6dacd4c39c470fab700e8
Author: findmoon [email protected]
Date: Tue Feb 20 12:48:53 2018 +0800

add a readme file

The previous latest version record is no longer available. If you want to return to the original latest version, you need to write down the version number at that time (the terminal is not closed, you can find it upwards). For example, the commit id e18195 of the "add a new line in readme.txt" version...

  • Specify to advance to a future version
    liu@liu-virtual-machine:~/gitTest$ git reset --hard e181953c3f43e15ceee10fb86f05fd4568265127
    HEAD is now located at e181953 add a new line in readme.txt
    The content of readme.txt has changed to the latest version.
  • git reset --hard e181953 does not need to write the full version number, Git will automatically find the
    version of Git, and the rollback speed is very fast, because Git has a HEAD pointer pointing to the current version internally. When rolling back the version, Git just puts HEAD changes from pointing to the current version to pointing to the rollback version. Then update the files in the workspace.
  • When you want to restore to the latest version after rolling back to a certain version, you must find the commit id. Git submits git reflog to record your every command
    liu@liu-virtual-machine:~/gitTest$ git reflog
    1769dcb HEAD@{0}: reset: moving to HEAD^
    e181953 HEAD@{1}: reset: moving to e181953c3f43e15ceee10fb86f05fd456826 5127
    1769dcb HEAD@{2}: reset: moving to HEAD^
    e181953 HEAD@{3}: commit: add a new line in readme.txt
    1769dcb HEAD@{4}: commit: modify
    d5b84bf HEAD@{5}: commit: modifya readme file
    3033dda HEAD@{6}: commit (initial): add a readme file
    Through the commit id in front of each command history, you can restore the version you want. People
    will always do things that they regret. At the beginning, they feel that there is a problem with the commit , It was found to be correct later, the problem is that you used git reset --hard HEAD^ or git reset --hard commit_id to roll back the local version.

The problem lies in –hard

What should I do if I can't find the commit id of the new version?

In Git, there is always regret medicine to take.

1. Find commit_id
hezaizai@ubuntu: ~/code_test $ git reflog
1ab8e23 HEAD@{0}: reset: moving to HEAD^
f8e01df HEAD@{1}: commit: latest node
1ab8e23 HEAD@{2}: commit: commit the new f
66759e4 HEAD@{4}: commit: forword
9cb749d HEAD@{6}: commit: twice commit
eb593f8 HEAD@{8}: commit: first commit gitreset”
here records all your operation records
here f8e01df is your rollback HEAD^, which is the commit_id.

2. Restore deleted records
Recommended: git reset --hard commit_id

Well, the world has returned to peace.

Method 2: git cherry-pick commit_id
git cherry-pick commit_id will generate a new node, not the original one, but the file is restored. You can refer to the git cherry-pick I wrote.

Some instructions:
1. reflog:Reference logs (reference log)

2. The difference between log and reflog.
git log shows the current HEAD and its ancestors, and the recursion follows the principle of the current pointer's father, the father's father, ..., such principles.
The git reflog is a sequential list of commits pointed to by HEAD: its undo history. The reflog is not part of the local warehouse, it is stored separately, not included in pushes, fetches or clones, it is only local.

Original link: https://blog.csdn.net/weixin_43083491/article/details/112618311

Guess you like

Origin blog.csdn.net/weixin_45876175/article/details/130885356