Git regret medicine Daquan vomiting blood Suggested collection

1. Undo file modification

• Undo changes to a single file

git reset HEAD XXX.js

• Undo all uncommitted changes

git reset --hard

Because the code at this time has not been submitted to the warehouse, this kind of undo is irreversible, please operate with caution. After revocation, the code version will roll back to the state of the last pull/commit.

2. Add and cancel in the temporary storage area

1. Add temporary storage area

• First check the status of the project file (the files that have not been added to the temporary storage area Untracked files)
• Changes to be committed Newly created uncommitted files (in the temporary storage area)
• Changes not staged for commit Modified uncommitted files (in the temporary storage area)
• Untracked files Files not added to the staging area (not in the staging area)

git status

In the result of the previous step, Untracked files correspond to files that have not been added to the temporary storage area. You can directly use git add + <file path in Untracked files> to add to the temporary storage area (files added to the temporary storage area will only Participate in submitting when committing), give a chestnut:

git add leetcode/977.js

2. Temporary storage area removal

• The first step is to check the status of the temporary storage area with git status, and find the list of files corresponding to the files you want to delete from the temporary storage area in Changes to be committed
• The second step is to remove the files that do not need to be submitted from the temporary storage area through the git reset HEAD <file path to be removed> command

git reset HEAD <要移除的文件路径>

• The third step is to end the removal here. It is recommended to use git status to check the deletion result

3. Edit the latest commit

High-energy warning, the following operations can support commit modification in three dimensions

• Re-edit the commit message
• Add missing files
• Modify the submitted file content

In fact, these three problems can be solved with one command, which is easy to understand, so I will not write them separately. As for how to submit it, do you know the judges? ... Very well, everyone will, then let's start from the completion of the submission

1. After the submission is complete, check the submission status first

git status

If you suddenly find  that there are files that you missed to submit, take the files Untracked files ticked in the screenshot as an exampletest.vue

2. Find missing submitted files and add them to the cache

git add src/components/fileEdit/test.vue

According to the Unix design philosophy, no news is the best news. You won't get any prompt if the addition is successful.

Of course, if you only want to modify the commit message, then ignore the second item.

3. There is a file to be modified, add it to the cache

Note that when your previous submission already includes a file such as index.vue, and you find that your submission is wrong after submission, but you don’t want to commit again, you need to manually add the file you modified to the cache. It's easy, just follow these three steps:

• modified file
• git status View changed files
• git add <the path corresponding to the file name viewed in the previous step>

Note that the index.vue file is a file you have already submitted, but you need to add it once with git add if you want to merge it into the last commit. Because git add adds specific file changes, not file names.

4. Revocation

amend means to amend.

When the --amend command is added after the commit command, Git will not add a commit record to the current commit, but will merge the contents of the current commit with the contents of the staging area and create a new one commit, replace the current commit with this new commit. So after revocation, you will only see one commit record in the git commit history, and the previous one is overwritten.

git commit --amend

Enter the above command and you should enter the interface shown in the following interface diagram. Depending on the operating system, it may be nano or vi. Here is the most basic usage of it.

• The default entry is in the command mode, press the lowercase i once to enter the edit mode
• The input is complete, press ESC once to return to the command mode
• Enter uppercase Z twice (support key combination) to save and exit

After understanding the above usage, it is easy to modify the commit message information. First, press the lowercase i once, cooperate with the keyboard up, down, left, and right keys to modify the message information, press ESC once, and then press the uppercase Z twice, and you're done.

Look at the picture, the submission information has changed

Look at the submission record again, there are easter eggs

It is already more than four o'clock in the afternoon, and the time displayed in the submission history with git commit --amendthe modified commit record is still the time of your first submission . That is to say, you can secretly modify the submitted files, and only one is displayed in the git submission record.

4. Edit any commit

Found a problem with the code submitted once, want to modify and roll back?

Looking back at the third article you just learned, you have already learned to directly modify the previous commit with an error, so we only need to consider the case that the commit you want to modify or roll back is not the latest commit.

In fact, after learning git commit --amend, the operation this time is also very simple. We only need to move the focus of the modification to the commit you want to modify, here we need to use the rebase -i command (i is the abbreviation of interactive, meaning interactive, rebase -i can be understood as interactive change base).

Interactive rebase? Is it a little confused?
To give the simplest example, when you write an article on the computer, the cursor is always pointing to the last character, you can directly press the back key to delete; but you find that the previous word is wrong and you don’t want to write all the last few words What should I do if I delete it? Of course, it is to move the cursor to the wrong character. You can think that the operation of interactive rebase is similar to that of moving the cursor.
But the focus here is not HEAD

Let’s take another picture to understand.

Continuing with rebase -ithis command, if you find that the third last commit is wrong, that is to say, the current cursor has to move forward twice before considering editing and modification, here you need to understand the two offset symbols supported by Git

• ^ One ^means shift backward one time.
  • Offset three times corresponds to the commit syntax should be git rebase -i HEAD^^^
• ~ ~Adding a number n means that the offset is shifted back n times.
  • Offset three times corresponds to the commit syntax should be git rebase -i HEAD~3

The next operation is the same as the third process, I will probably list it

• modify file
• add files git add <修改了要提交的文件>
• git commit --amend

Wait, there is the last step, move yours 光标to the end, it is still the rebase syntax.

git rebase --continue

Congratulations at this point, this interactive rebase process is perfectly over.

The Chinese explanation of rebase is rebase/rebase. After you understand the above process, you will find that this explanation is relatively accurate, so you can pay attention to it.

5. Roll back a commit

First rebase to the commit you want to undo. (I have just talked about the specific usage of rebase, you can read it again if you don’t understand it)

git rebase -i HEAD~2

The principle of rollback is actually to generate a new submission to offset the content of the previous submission.

git revert HEAD^

If you have uncommitted files locally, you may encounter the following warnings to prevent you from rolling back. You can commit or stage these changes somewhere and roll back to resolve them.

error: your local changes would be overwritten by revert.
hint: commit your changes or stash them to proceed.

After completion, you will find that there is one more commit in the local warehouse, and then you can directly push to the corresponding remote warehouse.

6. Undo branch deletion

It is a good habit to delete some task or bug branches when they are used up, but what should I do if I accidentally delete a useful branch?

Here is an introduction to the reflog command, the full name is reference log, which can view the movement records of references in the Git warehouse. If you don't specify a reference, it will display the movement records of HEAD, (the in-depth introduction to HEAD and references should be followed by a separate explanation).

I built a dev-reflog locally and pushed it to the remote warehouse, and then used the following command to delete this branch (note that I used -D to force deletion, please use it with caution in actual projects).

git branch -D dev-reflog

Well, the dev-reflog branch has been deleted here, and if you want to restore it, first check the operation record through git reflog.

git reflog

In the picture above, the penultimate item I framed is  dev-reflog the reference code corresponding to the deleted branch, and then you can retrieve it.

git checkout 715b2cb
git checkout -b dev-reflog

Because of Git's recycling mechanism, branches that are deleted within a certain period of time will be completely recycled by Git and cannot be retrieved, so it  reflog must be used in a timely manner.

7. Scenarios that cannot be retrieved

In most cases, git operations are traceable and can be rolled back, but there are also three special cases that cannot be recovered.

1. Local file reset
After the local file is reset, it cannot be retrieved because it has not been submitted and no record has been left in git. (Of course, non-git operations such as ctrl/command+z are not in the scope of our shop)

2. The file modified by amend
The amend command to modify the file actually overwrites the corresponding commit submission with one modification. Because it is an overwrite, only the latest commit record will exist in the git history. In this case, the state before amend modification is irreversible.

3. Branches reclaimed by Git
After deleting a branch, git will automatically recycle branches that have been deleted for a long time.

END