git part 3, git detailed explanation part 3_PHP tutorial

Git three, git detailed explanation

1. status command and diff command

---

We have successfully added and submitted a readme.txt file earlier. Modify the readme.txt as follows:

echo "Git is a distributed version control system. " > readme.txt
echo "Git is free software." >> readme.txt

Run the git status command to see the results:

$ git status
...
no changes added to commit (use "git add" and/or "git commit -a")

The git status command allows us to keep track of the current status of the warehouse. The above shows that readme.txt has been modified, but there are no modifications ready to be submitted.

Take a look at this git diff command:

$ git diff readme.txt
...
-Git is version control system.
+Git is a distributed version control system.
Git is free software

As the name suggests, git diff is to view differences. The format displayed is the universal diff format of Unix. As you can see from the command output above, we added a "distributed" word in the first line.

After making any changes to readme.txt, submit it to the warehouse. Submitting changes and submitting new files are the same two steps, git add and git commit:

$ git add readme.txt
$ git commit -m "add distributed"

Attention

• To keep track of the status of the workspace, use the git status command.
• If git status tells you that a file has been modified, you can use git diff to view the modification content.

2. Version rollback

---

Now, practice again and modify the readme.txt file as follows:

echo "Git is a distributed version control system." > readme.txt
echo "Git is free software distributed under the GPL." >> readme.txt

We submit readme.txt again

$ git add readme.txt
$ git commit -m "append GPL"

We have submitted multiple documents now, would you like to see which ones are there? There must be a command in the version control system that can tell us the history. In Git, we use the git log command to view:

$ git log
commit 3628164fb26d48395383f8f31179f24e0882e1e0
Date: Tue Aug 25 15:11:49 2015 +0000
append GPL
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85
Date: Tue Aug 25 14:53:12 2015 +0000
add distributed
commit cb926e7ea50ad11b8f9e909c05226233bf755030
Date: Mon Aug 24 17:51:55 2015 +0000
wrote a readme file

The git log command displays the commit log from the most recent to the farthest. We can see 3 commits. The most recent one is append GPL, the last one is add distributed, and the earliest one is write a readme file. Commit 36281**2e1e0 is the commit id (version number). If you think the output information is too much, you can use $ git log --pretty=oneline. At this time, you will see a large list of commit ids similar to 3628164...882e1e0. Number).

Every time a new version is submitted, Git will actually automatically string them together into a timeline. Now I am going to roll back readme.txt to the previous version, which is the version of "add distributed". How to do it?

First, Git must know which version the current version is. In Git, HEAD is used to represent the current version, which is the latest commit 3628164...882e1e0 (note that my commit ID is definitely different from yours) , the previous version is HEAD^, and the previous version is HEAD^^. Of course, it is easier to count the previous 100 versions by writing 100^, so it is written as HEAD~100 .

Now, if we want to roll back the current version "append GPL" to the previous version "add distributed", we can use the git reset command:

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

3. Restore to the new version

---

Following the version rollback in the previous section, you can continue to roll back to the previous version write a readme file, but now let’s look at the status of the repository git log:

$ git log

The latest version append GPL is no longer visible! It's like you took a time shuttle from the 21st century to the 19th century, and if you want to go back you can't go back. What should you do?

As long as the environment on the right is still there, you can find that the commit id of the append GPL is 3628164..., so you can specify a version back to the future:

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

There is no need to write the complete version number, just the first few digits, Git will automatically find it. Of course, you can't just write the first one or two, because Git may find multiple version numbers and it won't be able to determine which one it is.

You can view the contents of readme.txt $ cat readme.txt .

Git’s version rollback is very fast because Git has an internal HEAD pointer pointing to the current version. When you roll back the version, Git just changes the HEAD from pointing to append GPL to pointing to add distributed .

4. git reflog command

---

Now, you have rolled back to a certain version. What should you do if you want to restore to a new version? What should I do if I can’t find the commit id of the new version?

You can rest assured in Git. When you use $ git reset --hard HEAD^ to roll back to the add distributed version, and then want to restore to append GPL, you must find the commit id of append GPL. Git provides a command git reflog to record each of your commands:

$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed
cb926e7 HEAD@{3}: commit (initial): wrote a readme file

As you can see, the second line shows that the commit id of append GPL is 3628164, so we can find it again.

Note, we can learn from these two sections:

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

 

5、基本概念

---

工作区：就是你在电脑里能看到的目录,learngit文件夹就是一个工作区，比如我们环境中当前的目录。

版本库:工作区有一个隐藏目录.git 这个不算工作区，而是Git的版本库。

暂存区：英文叫stage,或index。一般存放在git 目录下的index文件(.git/index)中，所以我们把暂存区时也叫作索引(index).

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

我们把文件往Git版本库里添加的时候，是分两步执行的：

• 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
• 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以现在git commit就是往master分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后一次性提交暂存区的所有修改。

 

实践理解暂存区

---

现在我们对readme.txt做个修改，比如追加一行内容：

echo "Git has a mutable index called stage." >> readme.txt

然后，在工作区新增一个LICENSE文本文件

echo "LICENSE is a new file." > LICENSE

用git status查看一下状态，Git显示结果，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。

现在，使用两次命令git add，把readme.txt和LICENSE都添加后，用git status再查看一下，通过图可以理解为：

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

$ git commit -m "understand how stage works"

一旦提交后，如果你又没有对工作区做任何修改，用git status查看下，没有任何内容，现在版本库变成了这样，暂存区就没有任何内容了：

http://www.bkjia.com/PHPjc/1111691.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/1111691.htmlTechArticlegit之三，git详解之三 1、status命令与diff命令 前面我们已经成功地添加并提交了一个readme.txt文件，修改readme.txt如下： echo "Git is a distributed...