Git Easy guide 4--time Shuttle

We have successfully added and submitted a Readme.txt file, and now it is time to continue working, so we continue to modify the Readme.txt file and change it to the following:

Git is a distributed version control system. Git is free software.

Now, run the git status command to see the results:

$ git status# on branch master# changes not staged for commit:#   (use "git add <file> ...." To update what would 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")

　　

git statuscommand allows us to keep abreast of the current state of the warehouse, the above command tells us that Readme.txt has been modified, but not ready to commit the changes.

Although Git tells us that Readme.txt has been modified, it's good to see what's changed. For example, you take a vacation two weeks from abroad, the first day of work, have not remember the last how to modify the Readme.txt, so, need to use git diff this command to see:

$ git diff readme.txt diff--git A/readme.txt B/readme.txtindex 46d49bf: 9247DB6 100644---a/readme.txt+++ b/readme.txt@@ -1,2 +1,2 @@-git is a version control System.+git is a distributed versio N Control System. Git is free software.

　　

git diffAs the name implies is to view difference, the format is the UNIX common diff format, you can see from the command output above, we added a "distributed" word in the first line.

Know what changes to Readme.txt, and then submit it to the warehouse is much more assured that the submission of changes and submit a new file is the same two steps, the first step is git add :

$ git Add readme.txt

There is also no output. Before performing the second step git commit , let's run through git status the status of the current warehouse:

$ git status# on branch master# changes to being committed:#   (use "git reset HEAD <file> ..." to Unstage) # #       Modi Fied:   Readme.txt

　　git statusTell us that the changes to be submitted include Readme.txt, the next step, and you can safely submit:

$ git commit-m "add distributed" [Master ea34578] Add distributed 1 file changed, 1 insertion (+), 1 deletion (-)

Once submitted, we then use git status the command to see the current state of the warehouse:

$ git status# on branch masternothing to commit (working directory clean)

Git tells us that there are no changes that need to be committed at this moment, and that the working directory is clean (working directory cleanly).

Summary

• To keep track of the status of your workspace, use the git status command.

• If git status you are told that a file has been modified, you git diff can view the modified content.

Version fallback

Like this, you continue to modify the file, and then constantly submit changes to the repository, like playing RPG, every pass through the game will automatically save the state, if there is no past, you can also choose to read the status of the previous level. In some cases, you can manually save the boss before hitting it, so that if the boss fails, you may start again from the nearest place. Git, too, can "save a snapshot" whenever you feel that the file has been modified to a certain level, a snapshot that is called in Git commit . Once you've changed the file, or deleted it by mistake, you can recover from the latest one commit , and then continue working instead of losing all of your work for months.

Now, let's review how several versions of the Readme.txt file have been submitted to the GIT repository:

Version 1:wrote a Readme file

Git is a version control system. Git is free software.

Version 2:add distributed

Git is a distributed version control system. Git is free software.

Version 3:append GPL

Git is a distributed version control system. Git is free software distributed under the GPL.

Of course, in the actual work, how can we mind remember a thousands of-line file each time the change of what content, or version control system what to do. The version control system must have a command that tells us the history, and in Git we use git log commands to view:

$ git logcommit 3628164fb26d48395383f8f31179f24e0882e1e0author:michael Liao <[email protected]>date:   Tue 15:11:49 +0800    Append gplcommit ea34578d5496d7dd233c827ed32a8cd576c5ee85author:michael Liao <[email Protected]>date:   Tue 14:53:12 +0800    Add Distributedcommit Cb926e7ea50ad11b8f9e909c05226233bf755030author:michael Liao <[email protected]>date:   Mon 19 17:51:55 +0800    wrote a readme file

　　git logThe command shows the commit log from the most recent to the farthest, we can see 3 commits, the most recent being, the last one was append GPL add distributed , the first one was wrote a readme file . If too many output information, see dazzling, you can try to add --pretty=oneline parameters:

$ git log--pretty=oneline3628164fb26d48395383f8f31179f24e0882e1e0 append Gplea34578d5496d7dd233c827ed32a8cd576c5ee85 Add distributedcb926e7ea50ad11b8f9e909c05226233bf755030 wrote a Readme File

　　

The need for a friendly tip is that you see a bunch of similar 3628164...882e1e0 commit id (version number), and SVN is not the same, Git is commit id not a three-way ... Incrementing the number, but a SHA1 calculated by a very large number, in hexadecimal notation, and you see commit id and my affirmation is not the same, with your own prevail. Why do commit id we need to use such a large number of numbers to express? Because Git is a distributed version control system, we also want to study how many people work in the same repository, if we all use a three-to-one version ... As a version number, it must have been a conflict.

Each time a new version is submitted, git actually automatically strings them into a timeline. If you use a visualizer to view git history, you can see the time of commit history more clearly.

OK, now we start the time shuttle, ready to Readme.txt back to the previous version, that is, "add distributed" that version, how to do it?

First, git must know which version of the current version is, in Git, the current version, that is, the HEAD latest commit 3628164...882e1e0 (note that my commit ID is not the same as yours), the previous version is HEAD^ , the last version is, HEAD^^ Of course up to 100 versions write 100 ^ more easy to count, so write HEAD~100 .

Now we're going to roll back the current version of "Append GPL" to the previous version of "Add distributed", and you can use the git reset command:

$ git reset--hard head^head is now at ea34578 add distributed

　　

--hardWhat does the parameter mean? I'll talk about this later, and now you can use it with ease.

See if the content of Readme.txt is not version add distributed :

$ cat Readme.txtgit is a distributed version control system. Git is free software.

You can also continue to fall back to the previous version wrote a readme file , but wait, let's take git log a look at the status of the repository now:

$ git logcommit ea34578d5496d7dd233c827ed32a8cd576c5ee85author:michael Liao <[email protected]>date:   Tue 14:53:12 +0800    Add distributedcommit cb926e7ea50ad11b8f9e909c05226233bf755030author:michael Liao <[ Email protected]>date:   Mon 17:51:55 +0800    wrote a readme file

　　

The latest version is out of append GPL sight! Like you from 21st century to sit time shuttle machine came to 19th century, want to go back already can't go back, swollen?

The method is still some, as long as the above command Line window has not been turned off, you can go up and look for Ah, find append GPL that commit id is 3628164... , so you can specify back to a future version:

$ git reset--hard 3628164HEAD is now at 3628164 append GPL

　　

The version number is not necessary to write the whole, the first few can be, git will automatically go to find. Of course, you can't just write the top one or two bits, because git might find multiple version numbers, and there's no way to determine which one.

Look carefully at the contents of Readme.txt:

$ cat Readme.txtgit is a distributed version control system. Git is free software distributed under the GPL.

Git's version fallback is very fast because git has a pointer to the current version inside, and HEAD when you roll back the version, git just points to the head append GPL :

Instead, point to add distributed :

And then by the way, the workspace files are updated. So you HEAD can point to which version number, and you position the current version.

Now, you fall back to a version, turn off the computer, the next morning regret, want to revert to the new version of what to do? What if I can't find a new version commit id ?

In Git, there's always a regret pill to eat. $ git reset --hard HEAD^ add distributed The Commit ID that you must find when you want to revert back to the version append GPL append GPL . git provides a command git reflog to keep track of every command you make:

$ git reflogea34578 [email protected]{0}: reset:moving to head^3628164 [email protected]{1}: commit:append GPLea34578 [E Mail protected]{2}: Commit:add distributedcb926e7 [Email protected]{3}: Commit (initial): wrote a readme file

Finally relieved, the second line shows append GPL the commit ID is 3628164 , now, you can take the time machine back to the future.

Summary

Now summarize:

• HEADThe point is the current version, so git allows us to navigate between versions of history, using commands git reset --hard commit_id .

• Before you travel, git log you can view the commit history to determine which version to fallback to.

• To return to the future, use the git reflog view command history to determine which version to return to in the future.

Workspaces and Staging Area

One of the differences between Git and other version control systems like SVN is the concept of staging area.

First look at the noun explanation.

Workspaces (Working Directory)

Is the directory you can see on your computer, like my learngit folder is a workspace.

Version Library (Repository)

The workspace has a hidden directory .git , which does not count as a workspace, but a git repository.

Git's repository contains a lot of things, the most important of which is called the stage (or index) of the staging area, as well as git for us to automatically create the first branch master , and pointing master to a pointer called HEAD .

HEADthe concept of branching and we speak later.

When we added the file to the Git repository, it was done in two steps:

The first step is to add the file git add , in effect, to add the file to the staging area;

The second step is to commit the git commit changes, in effect, to commit all the contents of the staging area to the current branch.

Since we created the Git repository, Git automatically created the only branch for US master , so now it's time to git commit commit the changes to the master branch.

You can simply understand that the file changes that need to be submitted are all put to staging area, and then all changes to staging area are submitted at once.

As the saying goes, practice is the truth. Now, let's practice again and readme.txt make a change, such as adding a line of content:

Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage.

Then, add a text file to the workspace LICENSE (the content is written casually).

Check the git status status first:

$ git status# on branch master# changes not staged for commit:#   (use "git add <file> ...." To update what would be Committed) #   (use "Git checkout--<file> ..." to discard changes in working directory) # #       Modified:   readme.txt## untracked files:#   (use "git add <file> ...." To include in what'll be committed) # #       Licenseno Ch Anges added to commit (use "git add" and/or "Git Commit-a")

　　

Git tells us very clearly that readme.txt it has been modified and has LICENSE never been added, so its state is Untracked .

Now, using the two commands git add , readme.txt Add and LICENSE then look at the following git status :

$ git status# on branch master# changes to being committed:#   (use "git reset HEAD <file> ..." to Unstage) # #       New File:   license#       modified:   readme.txt

Now, the state of staging area becomes this:

So, the git add command actually puts all the changes you want to commit to staging area (Stage), and then executes git commit it to commit all the staging area changes to the branch at once.

$ git commit-m "understand how stage works" [Master 27c9860] Understand how stage works 2 files changed, 675 insertions (+) Create mode 100644 LICENSE

Once submitted, if you do not make any changes to the workspace, then the workspace is "clean":

$ git status# on branch masternothing to commit (working directory clean)

Now that the repository has changed, staging area has no content:

Manage changes

Now, suppose you have mastered the concept of staging area completely. What we're going to talk about here is why Git is better designed than other version control systems because git tracks and manages changes, not files.

You will ask, what is the modification? For example, you add a row, this is a change, delete a row, is also a modification, change some characters, is also a modification, delete some and add some, is also a modification, even create a new file, also counted as a modification.

Why is git managing changes, not files? We still do the experiment. The first step is to make a change to Readme.txt, such as adding a line of content:

$ 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 being committed:#   (use "git reset HEAD <file> ..." to unstage) # #       modified:   readme.txt#

Then, modify the 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 submitting, look at the status:

$ git status# on branch master# changes not staged for commit:#   (use "git add <file> ...." To update what would 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")

　　

Gee, how did the second Amendment not be submitted?

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

First modification, git add second modification,git commit

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

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

$ git diff HEAD--readme.txt diff--git A/readme.txt B/readme.txtindex 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 can be seen, the second modification is indeed not committed.

Then how to submit a second Amendment? You can continue git add git commit , or you can not worry about the first modification, the git add second modification, and then git commit , the equivalent of two changes after the merger of a piece submitted:

First modification, git add Second Amendment, git addgit commit

OK, now, submit the second change and start the summary.

Summary

Now you understand how git keeps track of changes, every time you change it, and if you don't add get to staging area, you won't join commit in.

Undo Changes

Undo changes to the workspace

Naturally, you are not going to make a mistake. But it's two o'clock in the morning, and you're working on a job report, and you've readme.txt added a line to it:

$ 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 prepare to submit, a cup of coffee has played a role, you suddenly found that "stupid boss" may let you lose this month's bonus!

Now that the error has been found in time, it can be easily corrected. You can delete the last line, manually restore the file to the previous version of the state. If you take a git status look:

$ git status# on branch master# changes not staged for commit:#   (use "git add <file> ...." To update what would 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")

You can see that git will tell you that you git checkout -- file can discard changes to the workspace:

$ git checkout--readme.txt

　　

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

One is that readme.txt since the modification has not been put into the staging area, now, undo changes back to the same state as the repository;

One is readme.txt added to the staging area, and then modified, and now, undo changes back to the state after adding to staging area.

In short, let this file go back to git commit git add the last state or time.

Now, look at readme.txt the contents of the 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.

　　git checkout -- fileThe command is -- important, no -- , it becomes the "Create a new branch" command, we will encounter the command in the later branch management git checkout .

Undo changes to Staging area

Now suppose it is 3 o'clock in the morning, you have not only written some nonsense, but also git add to the staging 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, commit before, you discovered the problem. With git status a look, the changes were added to the staging area, not yet committed:

$ git status# on branch master# changes to being committed:#   (use "git reset HEAD <file> ..." to Unstage) # #       Modi Fied:   Readme.txt

Git also tells us to use the command to git reset HEAD file undo the staging area changes (Unstage) and re-put them back into the workspace:

$ git reset HEAD readme.txtunstaged changes after reset:m       readme.txt

　　

git resetThe command can be rolled back to the version, or the staging area's modifications can be rolled back to the workspace. When we use HEAD it, the latest version is indicated.

Again with a git status look, now staging area is clean, the workspace has been modified:

$ git status# on branch master# changes not staged for commit:#   (use "git add <file> ...." To update what would 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 changes to the workspace?

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

　　

Now, suppose you have not only changed the wrong thing, but also submitted it from staging area to the repository, what should I do? Do you remember the version fallback section? Can be rolled back to the previous version. However, this is conditional, that you have not yet pushed your local repository to remote. Remember Git is a distributed version control system? We'll talk about the remote repository later, and once you push the "stupid boss" commit to the remote repository, you're really miserable ...

Summary

It's time to summarize again.

Scenario 1: When you mess up the contents of a file in your workspace and want to discard the workspace changes directly, use the command git checkout -- file .

Scenario 2: When you not only changed the contents of a file in the workspace, but also added to the staging area, want to discard the changes, two steps, the first step with the command git reset HEAD file , back to Scene 1, the second step by scene 1 operation.

Scenario 3: When an inappropriate modification to the repository has been submitted, you want to revoke this commit, refer to the version fallback section, but only if it is not pushed to the remote library.

deleting files

In Git, the deletion is also a modification operation, we do the actual combat, first add a new file Test.txt to Git and commit:

$ git add test.txt$ git commit-m "add test.txt" [Master 94cdc44] Add test.txt 1 file changed, 1 insertion (+) Create mode 1 00644 Test.txt

In general, you usually delete the useless files directly in the File Manager, or rm delete them by command:

$ RM test.txt

At this point, git knows that you deleted the file, so the workspace and repository are inconsistent, and the git status command will immediately tell you which files were deleted:

$ git status# on branch master# changes not staged for commit:#   (use "Git add/rm <file> ..." To update the What would Be committed) #   (use "Git checkout--<file> ..." to discard changes in working directory) # #       deleted:    tes T.txt#no changes added to commit (use "git add" and/or "Git Commit-a")

Now that you have two options, one is to remove the file from the repository, delete it with a 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 repository.

The other is wrong, because the repository is still there, so it is easy to restore the deleted files to the latest version:

$ git checkout--test.txt

　　git checkoutInstead, replace the workspace version with the version in the repository, which can be "one-click Restore", regardless of whether the workspace is modified or deleted.

Summary

Command git rm to delete a file. If a file has been submitted to the repository, then you never have to worry about accidentally deleting it, but be careful that you can only recover files to the latest version and you will lose what you modified after the last commit .

Git Easy guide 4--time Shuttle