Git (workspace, staging area, manage changes, undo changes, delete files)

Workspaces and staging Area 984 reads

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:

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 W Hat would be committed) # (use "Git checkout-<file> ..." to discard changes in working directo RY) ## modified:readme.txt# # untracked files:# (use "Git add <file> Committed) ## licenseno changes added to commit (use 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 be 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.

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:

Summary

Staging area is a very important concept of git, figuring out staging area, figuring out what a lot of git's operations are doing.

I don't know what's going on staging area. Children's shoes, please scroll up the page and look again.

Management Modified 864 reads

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:

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 the Readme.txt:

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:

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 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")

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:

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, if you don't add get to staging area, you won't join commit in.

Undo Change 791 Reads

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:

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 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")

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:

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 document were restored.

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 .

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

Delete a file 603 reads

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:

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 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 what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)## deleted: test.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 :

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 (workspace, staging area, manage changes, undo changes, delete files)