preface

Previously: Git Application details First lecture: Git partition, Configuration and logging

In the first lecture, we gave you a brief introduction to Git. If you are smart enough, you already know the basics of Git.

Git: Delete files, compare files, undo changes, modify comments, and view help files.

Delete files

1.git rm <file>

This command is used to delete files from the version library. Deleting files in the workspace and staging area will cause an error:

  • If you use this command to delete a file from a workspace, an error will be reported:

  • If this command is used to delete a file in the staging area, the following error is reported:

** Files in the repository are: ** Files that have been committed by the COMMIT directive, not files in the workspace (red), or files in the staging area (green).

Git rm does two things:

  • ** Step 1: ** Delete files from the repository;
  • ** Step 2: ** Add the delete operation to the staging area (stage). As shown in the following figure, it is executedgit add test.txtAnd can then be submitted directly to completetest.txtDelete;

2.rm <file>

This command is used to delete files in the workspace and repository.

** Note: ** no local files added to git repository are workspace files.

  • When deleting a file in a workspace:

  • When deleting a file from a repository:

Unlike git RM, this directive does not include delete operations in the staging area. The test. TXT file can be deleted only after it is added to the temporary storage area and then submitted to the version library.

  • When deleting a file in the staging area:

From the figure, the rm command can only delete test3. TXT from the workspace, but not from the staging area. :

Rename the file

1.git mv <file1> <file2>

Git mv:

git mv test.txt test3.txt
Copy the code

Rename test. TXT to test3.txt; The mv command can be understood as changing the name while cutting.

Changes to be committed indicates that the change is already in the staging area and can be committed.

A green file has been committed to the staging area. Instead of git add, you can make a git commit.

Git MV does two things:

  • ** Step 1: ** filetest.txtrenametest3.txt;
  • Test. TXT -> test3. TXT;

2.mv <file1> <file2>

Use the system command mv:

mv test2.txt test3.txt
Copy the code

Git status:

Found two more steps in workspace:

  • Delete file test2.txt;

  • Create a new file text3.txt;

Git add test2.txt test3. TXT commit the operation to the staging area and run git status to check the status:

Git immediately recognizes that this is a file rename;

This impliesgit mvThree steps were performed:

  • ** Step 1: ** Delete the files in the workspace before the renametest2.txt;
  • ** Step 2: ** Create the renamed file in your workspacetest3.txt;
  • Step 3: Commit the above two operations to the staging area;

That is, the difference between git mv and mv is equivalent to the difference between git rm and rm.

3. Compare files

1. Local files<->The local file

diff file_a file_b

This is a system-provided comparison command used to compare local files or files that have been committed to the repository. Create files A and B and compare them using the instructions above:

indiff -u a bIn the output information of:

The -u argument is added to display the comparison information in more detail.

  • **– a** Indicates that a is the original file.

  • **+++ b** indicates that B is the target file.

  • -1 in 3 – indicates the original file a, 1 indicates the first line in the original file, and 3 indicates the third line. Lines 1 to 3 in the original file A;

  • In the same way: +1, 3 indicates: lines 1 to 3 in the object file B;

  • Data is preceded by three symbols representing different information:

    • The blank space: indicates that the line exists in both files, as shown in the figure aboveAABBThis line of filea.bThere are;
    • -: indicates the original fileaRemove the line to become the object fileb;
    • +: indicates the original fileaAdd this line to make it the object fileb;

    The line AABB contains both files, as long as the original file A is removed:

a1
a2
Copy the code

Plus:

b1
b2
Copy the code

It becomes object file B;

2. The workspace<-The staging area

Git compares the same file in the staging area with that in the workspace. And: The original file is the file in the staging area, and the destination file is the file in the workspace. The following is an example:

git diff

First, create new files a.tuck and b.tuck, modify their contents and submit them to the staging area:

Then, modify the contents of the files A.tuck and b.tuck again in the workspace:

Git diff git diff git diff

ingit diffIn the output information of:

  • — a/ a.txt: indicates that the original file is a.txt in the staging area.

  • +++ b/ a.txt: indicates that the target file is A.txt in the workspace.

  • – indicates the original file, and 1 indicates that the file starts from line 1. Since the a.txt file (the original file) in the staging area has only 1 line, the original (-1,1) is shortened to -1;

  • +1, 2: where + represents the object file, and 1, 2 represents the A.txt file (object file) in the workspace with 2 lines starting from line 1;

  • Hello world: indicates the content that exists in both the source and destination files.

  • + Hello Java means that a.txt in the staging area plus the line becomes the same as A.txt in the workspace;

As you can see, this directive compares the workspace version to the staging version of the same file, one by one. It does not compare A.txt to B.txt.

3. The workspace<-repository

The following command compares the same file in a repository and workspace. And: The original file is the file in the repository, the target file is the file in the workspace.

git diff commit_id

Compare the A files on the commit with the A files in the workspace.

git diff HEAD

Use to compare A files on the latest commit with A files in the workspace:

The A file above is only an example, as follows.

As shown in the following figure, test.txt is initialized as: changes in version library, and then commit once; Then add workspace modifications to test.txt in the workspace; Then execute the above comparison command, and the result shows that the test. TXT file in the workspace has one more line of changes than the latest submitted test. TXT file.

4. The staging area<-repository

The following command compares the same file in the repository and the staging area, where the original file is in the repository and the target file is in the staging area:

git diff --cached commit_id

Compare A file on A specified commit with A file in the staging area.

git diff --cached

Use to compare A files on the latest commit with A files in the staging area. The following is an example:

As you can see, the A.txt file in the staging area has an extra hello Java line than the a.txt file in the latest commit. The B.txt file in the staging area has an extra line of Hello Java2 than the b.txt file in the latest commit.

5. To summarize

  • The determination of the target file and the original file follows the following order: Workspace <- staging area <- version library (commit);

  • The comparison of the above comparison instructions is shown in the following table:

    instruction role The original file The target file
    diff <file1> <file2> Compare two local files Local file/version library Local file/version library
    git diff Compare the same file in the staging area and workspace The staging area The workspace
    git diff commit_id Compared to specifycommit idSubmit theAFiles and workspacesAfile repository The workspace
    git diff HEAD Compare the most recently submittedAFiles and workspacesAfile repository The workspace
    git diff --cached commit_id Compares what is committed on a specifiedAFiles and staging areaAfile repository The staging area
    git diff --cached Compare the most recently submittedAFiles and staging areaAfile repository The staging area

    File A in the table is only an example.

Iv. Cancel the modification

The main task is to restore the changes that have been included in the staging area (green) to the workspace (red), and then to the previous changes. For example, to undo git rm:

1. Restore the staging changes to the workspace (unstage)

That is, change the file modification operation from green to red.

Method one:git reset head <file>

As shown below, git rm deletes the test3.txt file from the repository and commits the operation to the staging area. The delete operation is then restored to the workspace using the command above;

Method 2:git restore --stage <file>

Here, the parameter –stage is written as –staged effects are the same and have the same effect as Passage 1:

2. Undo the workspace operation

For example, undo file changes, additions, and deletions in the workspace:

Method one:git restore <file>

As shown in the figure below, the test3.txt file is deleted from the workspace. Then undo the test3.txt delete from the workspace with the command above:

Method 2:git checkout -- <file>

The effect is the same as that of Law 1:

5. Modify the submitted notes and authors

1. Modify the latest submission information

git commit --amend -m‘Correction information’

If the commit message is written incorrectly:

You can modify the last commit by: git commit — amend-m ‘comment’

git commit --amend

When you need to add a large number of comments for a recent submission, you can use this directive directly to enter the Vim editor to edit:

This has the advantage that incorrect commits and corrected commits will only become one commit after being corrected by this command, instead of two.

git commit --amend --author 'Name<email>'

Used to modify the most recently submitted configuration information, including author and comment information. When executing the command, enter the vim editor to edit the comment information:

The last two commits on this branch before modification are as follows:

The last two submissions after modification are as follows:

You can see that the author of the last commit and the commit comment were successfully changed.

** Note: ** Changes the commit comment, but the commit_ID is different before and after the commit, indicating that a new commit is created instead of the original commit that needs to be corrected. Commit 5 and Commit 3 are shown below:

2. Modify specific submission information

As shown in the figure, four commits are made in the Test branch. Now we want to modify the commit information for the third commit:

git rebase -i commit_id

Use the above commands to enter rebase interactive mode and display commit information after commit_ID. For example, if commit_id is the commit_id of the first commit_id, the commit_id of the second to fourth commit_id is displayed. Here we need to modify the third commit by specifying it as commit_id for the second commit. Execute the following command to enter the Vim editor:

git rebase -i 678e0
Copy the code

From this interface, we can modify the third error commit by changing the pick parameter to one provided by the other Rebase. There are two parameters that do this:

Here is how to use the Vim editor:

  • shift + AIs an insert command that can be enteredvimEdit mode of the editor;
  • After editing, press firstESCGo back tovimEditor command line mode, and then enter:wqSave and exit the editor.

rewordparameter

This parameter directly modifies the submission comment for the submission with this parameter set. Here we should change the pick parameter for the third submission to reword:

Save and exit via :wq, then enter the vim editor again, this time to modify the submission with the reword parameter set.

Change it to the correct submission information:

Run the :wq command to save and exit the vim editor. The error submission information is modified and the historical submission information is displayed again.

You can see that the incorrect commit information is corrected, and the commit_id of this commit and subsequent commits has changed. Git creates a corresponding number of new commits and overwrites the original commits, but the contents remain unchanged.

Git rebase -i commit_id git rebase -i commit_id git rebase -i commit_id Any commit after this benchmark will be overwritten by a new commit created by Git with the same content. More on the rebase directive later.

editparameter

This parameter does the same thing, but with a few more steps. Stop the rebase process, edit the commit that added the parameter, and then proceed with the rebase by calling git rebase –continue. Details are as follows:

Change the pick parameter of a submission with error submission information to the edit parameter:

Run the :wq command to save the configuration and exit:

As you can see, the Edit parameter stops the rebase operation. Follow the instructions to:

git commit --amend
Copy the code

Enter the Vim editor and modify the currently submitted comment information:

After the modification, run the :wq command to save the changes and exit the vim editor. Then call:

git rebase --continue
Copy the code

Continue with the rebase operation to complete the modification of the error submission information:

If you want to update the commit history of the test branch, you will find that the wrong commit information has been corrected, and a new commit has been created, overwriting the original commit as in the reword parameter above.

git rebase -i HEAD~n

You can also use the preceding command to enter the Rebase interactive mode, where N indicates the latest n submission records to be displayed. For example, display the last three commits of the Test branch with the following command:

git rebase -i HEAD~3
Copy the code

After entering the Rebase interface, the subsequent actions and results are the same as the first method, which I won’t repeat here.

Get help

1.git help config

This command opens the Git-config help file in your git installation directory:

The use of relevant operation instructions is shown in detail in the document:

2.git config --help

The effect is the same as above, the same help page pops up;

3.man git-config

Man is a help document provided with Linux. You can also view the help document.

4.git

Display common commands directly in the command window: