git modification and deletion function _ Power node Java College collation

Why Git is better designed than other version control systems is because Git tracks and manages changes, not files.

What is revision, you ask? So if you add a line, that's a change, if you delete a line, that's a change, if you change some characters, that's a change, if you delete something and add something, that's a change, or even if you create a new file, that's a change.

Why does Git manage changes, not files? Let's do the experiment. Step 1. Make one modification to readme. txt, such as adding one line:

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

Then, add:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

Then, modify ES16en. txt:

$ cat readme.txt 
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

Commit:

$ git commit -m "git tracks changes"
[master d4f25b6] git tracks changes
 1 file changed, 1 insertion(+)

After submitting, look at the status again:

$ git status
# On branch master
# Changes not staged for commit:
#  (use "git add <file>..." to update what will be committed)
#  (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:  readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

How come the second revision was not submitted?

Don't get excited, let's review the first operation:

The first modification - > git add - > Second modification - > git commit

You see, we talked about, in front of the Git management is to change, when you use git add command, after the first changes are in the work place in the staging area, ready to submit, however, in the work area second change is not in the staging area, so the git commit only responsible for the commits the staging area, also is the first revision has been submitted, the 2nd revision will not be submitted.

Once committed, use the git diff HEAD -- readme.txt command to see the difference between the workspace and the latest version in the repository:

$ git diff HEAD -- readme.txt 
diff --git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
 Git is a distributed version control system.
 Git is free software distributed under the GPL.
 Git has a mutable index called stage.
-Git tracks changes.
+Git tracks changes of files.

As you can see, the second change was not actually committed.

So how do you commit the second change? You can continue with git add and git commit, or you can submit the first modification before git add and then git commit, which is equivalent to submitting the one block after merging the two modifications:

The first modification - > git add - > Second modification - > git add - > git commit

Ok, now, commit the second revision, and start the summary.

Of course, you can't make a mistake. But it's two o 'clock in the morning, you're catching up on a job report, and you add a line to readme.txt:

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

Before you are ready to submit, a cup of coffee works and you suddenly discover that "stupid boss" could cost you your bonus for the month!

Since the error is caught in time, it can be easily corrected. You can delete the last line and manually restore the file to the previous version. If you use git status to view 1:

$ git status
# On branch master
# Changes not staged for commit:
#  (use "git add <file>..." to update what will be committed)
#  (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:  readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

As you can see, Git will tell you that git checkout -- file can discard workspace modifications:

$ git checkout -- readme.txt

git checkout -- readme.txt undoes all modifications to the readme.txt file in the workspace.

One is readme.txt has not been put into temporary storage since it was modified. Now, if the modification is cancelled, it will return to the state like version library module 1.

The first is readme.txt has been added to the staging area, but has been modified. Undoing the modification now returns to the state added to the staging area.

In short, this file is returned to the last time git commit or git add.

Now, take a look at the file contents of readme.txt:

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

The contents of the file were restored.

git checkout -- file command -- important, not -- becomes the "switch to another branch" command, and we will see the git checkout command again later in branch management.

Now let's say it's 3am. Not only have you written some nonsense, but you've got git add in temporary storage:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

0

Fortunately, you found this before commit. Use git status to view 1. The modification has only been added to the staging area and has not been committed:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

1

Git also tells us that using the command git reset HEAD file can undo changes to the staging area (unstage) and put them back into the workspace:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

2

The git reset command can either roll back the version or the modification of the staging area to the workspace. When we use HEAD, we mean the latest version.

Then use git status to check 1. Now the temporary storage area is clean and the workspace has been modified:

$ git status
# On branch master
# Changes not staged for commit:
#  (use "git add <file>..." to update what will be committed)
#  (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified:  readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Remember how to discard workspace modifications?

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

4

The whole world is quiet at last!

Now, suppose you not only fix something wrong, but also commit it from the staging area to the repository. git can be rolled back to the previous version. However, this is conditional on you not pushing your local repository to a remote location. Once you push the "stupid boss" submission to the remote repository, you're screwed
In Git, deletion is also a modification operation. In practice 1, we first add a new file test. txt to Git and submit:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

5

In general, you usually delete files directly from the file manager or use the rm command:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

6

At this point, Git knows that you have deleted the file, so the workspace and version library are not sent. The git status command immediately tells you which files have been deleted:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

7

Now you have two options, 1 is to actually delete the file from the repository, use the command git rm to delete and git commit:

$ git rm test.txt
rm 'test.txt'
$ git commit -m "remove test.txt"
[master d17efd8] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

The file is now deleted from the repository.

In the other case, it is a mistake to delete the files, because there is still a copy in the library, so you can easily restore the deleted files to the latest version:

$ git add readme.txt
$ git status
# On branch master
# Changes to be committed:
#  (use "git reset HEAD <file>..." to unstage)
#
#    modified:  readme.txt
#

9

git checkout essentially replaces the workspace version with the version in the repository, allowing you to "1-key restore" whether the workspace is modified or deleted.