Shulou(Shulou.com)06/02 Report--

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

You will ask, what is modification? For example, if you add a new line, this is a modification, a deletion, a modification, a change of some characters, a modification, a deletion, an addition, a modification, or even the creation of a new file. it's a modification.

Why is it that Git manages changes, not files? Let's do the experiment. The first step is to make a change to readme.txt, such as adding a line:

$cat readme.txtGit 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..." To unstage) # # modified: readme.txt#

Then, modify 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.

Submit:

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

After submission, check the status:

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

Why, why didn't the second revision be submitted?

Take it easy, let's review the operation:

First revision-> git add-> second revision-> git commit

You see, as we said earlier, Git manages changes. When you use the git add command, the first change in the workspace is put into the staging area, ready to be submitted, but the second modification in the workspace is not put into the staging area, so git commit is only responsible for submitting the changes to the staging area, that is, the first modification is submitted, and the second modification will not be submitted.

After submission, use the git diff HEAD-- readme.txt command to see the difference between the latest version in the workspace and the version library:

$git diff HEAD-- readme.txt diff-- git a/readme.txt b/readme.txtindex 76d770f..a9c5755 100644 Murray-a Universe README.txtCharts @-1 meme 4 + 1 meme 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.

It can be seen that the second amendment has not been submitted.

Then how to submit the second amendment? You can continue to git add and then git commit, or you can not rush to submit the first modification, first git add the second revision, and then git commit, which is equivalent to merging the two changes and submitting one:

First revision-> git add-> second revision-> git add-> git commit

Okay, now, submit the second revision, and then start a summary.

Of course, you don't make mistakes. But it's 2: 00 in the morning, and you're in the middle of a work report, and you've added a line to readme.txt:

$cat readme.txtGit 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 realize that "stupid boss" may cost you this month's bonus!

Now that the mistake is found 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 check:

$git status# On branch master# Changes not staged for commit:# (use "git add..." To update what will be committed) # (use "git checkout--..." 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 changes:

$git checkout-readme.txt

The command git checkout-- readme.txt means to undo all changes to the readme.txt file in the workspace. There are two situations:

One is that readme.txt has not been placed in the temporary storage area since it was modified. Now, if you undo the changes, you will return to exactly the same state as the version library.

One is that after readme.txt has been added to the staging area, it has been modified, and now the undo changes return to the state after being added to the staging area.

In short, get the file back to the state it was when it was last git commit or git add.

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

$cat readme.txtGit 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.

Sure enough, the contents of the document were restored.

Git checkout-- in the file command-- very important, no-- becomes the "switch to another branch" command, which we will encounter again in branch management later on.

Now suppose it's 3: 00 in the morning, and you not only write some nonsense, but also git add to the temporary storage area:

$cat readme.txtGit 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.$ git add readme.txt

Fortunately, you discovered this problem before commit. Check with git status to see that the changes have only been added to the staging area and have not been submitted yet:

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

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

$git reset HEAD readme.txtUnstaged changes after reset:M readme.txt

The git reset command can roll back either the version or the changes to the staging area to the workspace. When we use HEAD, it represents the latest version.

Check again with git status. Now the staging area is clean and the workspace has been modified:

$git status# On branch master# Changes not staged for commit:# (use "git add..." To update what will be committed) # (use "git checkout--..." 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 changes to the workspace?

$git checkout-readme.txt$ git status# On branch masternothing to commit (working directory clean)

The whole world is finally quiet!

Now, suppose you not only correct something wrong, but also submit it from the temporary storage area to the version library, what should you do? Git can be rolled back to the previous version. However, there is a condition that you haven't pushed your local version library remotely. Once you push the "stupid boss" submission to the remote version library, you are really screwed.

In Git, deletion is also a modification operation. Let's add a new file test.txt to Git and submit it:

$git add test.txt$ git commit-m "add test.txt" [master 94cdc44] add test.txt 1 file changed, 1 insertion (+) create mode 100644 test.txt

In general, you usually delete useless files directly in the file manager, or delete them with the rm command:

$rm test.txt

At this point, Git knows that you deleted the files, so the workspace and the version library are inconsistent, and the git status command will immediately tell you which files have been deleted:

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

Now you have two choices. If you do want to delete the file from the version library, delete it with the command git rm, and git commit:

$git rm test.txtrm '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 version library.

Another situation is that the deletion is wrong, because there are still in the version library, so you can easily restore the mistakenly deleted files to the latest version:

$git checkout-test.txt

Git checkout actually replaces the version of the workspace with the version in the version library, which can be "restored with one click" regardless of whether the workspace is modified or deleted.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.