Git's detailed tutorial - trilogy

Git's detailed tutorial - Git trilogy

As a developer, we often encounter version management tools in our usual development. Today we will talk about the use of Git. Recently, I worshipped Jiang Xin's "Git Authoritative Guide" book, which has benefited a lot. Share this with everyone.

Git is a distributed version management tool. Everyone participating in the developer's computer is a code repository, which is very flexible to use. We will not explain the installation and configuration of Git here. There are many related content on the Internet. Not much to say about the advantages of Git, just start using it.

The use of Git can be said to be mainly divided into three parts to illustrate, and all the remaining commands serve these three commands. I will explain it in detail below.

trilogy	Order
add to staging area	git add
commit to repository	git commit
Submit to remote	git push

The above three commands are the most important commands, and other commands serve them, and their functions and commands can be listed.

Accessibility	Order
Initialize warehouse	git init
clone code	git clone
Compare the differences	git diff
View status	git status
View logs	git log
Check out the code	git checkout
reset code	git reset
recovery progress	git stash
milestone	git day
rollback operation	git revert
fetch (not merge)	git fetch
merge operation	git merge
Fetch and merge (fetch+merge)	git pull
rebase command (can handle conflicts and merge commits)	git rebase

The commonly used commands above have been written. Before we get into the real topic, let’s briefly talk about the three places where the code is stored in the git version management. There is a workspace, which is where we write the code; the second is temporary The storage area (Index), you can tell by the name that it is the place to temporarily store the code; the other is the repository, which is the place where the code is stored after we submit the code locally, and also the place where the code is submitted to the remote warehouse. In the following explanations, you will often encounter HEAD. git is a code management tool that supports multiple branches. As long as the HEAD head pointer is not in the state of the separated head pointer (the separated head pointer means that it points to a specific commit ID), then It will point to one of the branches, and a certain branch can be understood as the master branch, and the pointer of the master branch will point to the latest commit ID. In fact, HEAD can be understood as a cursor, flexibly switching between all branches, but pointing to the latest commit of the current branch.

Let's use AndroidStudio to create a project named Git to illustrate the functions of these commands. In fact, they are all the same. Even if you create a folder and write something in it, you can learn the meaning and function of these commands.

• Create a project named Git
• Right-click in the root directory of the project to run Git bash here, use the git init command to initialize the git repository, a hidden folder named .git will appear in the directory, and then we can track and version the code. .
• 
• Next, we modify the code in the project (don't worry, our project will not run, because it is meaningless to run), first look at the code of MainActicity.java before the modification, there is a problem that needs to be paid attention to here, the git version management tool can only manage Tracked files, that is, files that have not been added (add), cannot be tracked. Here we just use git init to initialize an empty repository. The above execution information also clearly says Initialized empty Git responsitory. So let's take a look at the git add command first

1. git add command

git add command	significance
git add . (here is a dot)	Commit changes to the workspace to the staging area, including file modifications and additions, but not deleted files
git add -u	Commit the changes of the workspace to the staging area, including file modification and deletion, but not including newly added files
git add -A	Commit workspace changes to the staging area, including all additions, deletions, and modifications
git add -i	Submit the changes of the workspace to the staging area, enter the interactive mode and select the file for operation
git add [filename]	Submit the changes in the workspace to the staging area, and select a file to submit

In order not to be confused with this later study, here I will directly use the git add -A command to submit all the content of the project and then use git commit -m "initial commit" to submit it once, and then carry out the study of this content, which everyone does not understand here. You can do this first and talk about it later. We use the git log command to view the commit record and we will see the commit information just now:

• At this time, we start to modify the code and add a method getName() to MainActivity; we use the command git diff to check it and add a line of code;

There are several symbols to pay attention to here, among which the three minus signs refer to the original file before the modification, and the three plus signs are worth the content of the current file. It is easy to see that a new line of code has been added by looking at the information;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }

    public void getName(){}
}

As I said just now, all other commands can be said to serve the trilogy commands, and the git diff command here is no exception. Here is a detailed description of the git command, and then you will know the meaning of the above git diff:

git diff command	significance
git diff	Compare workspace and staging area differences
git diff –cached	Compare the differences between the staging area and the repository
git diff HEAD	Compare the difference between the work area and the branch pointed to by the HEAD head pointer
git diff [ID]	Workspace is compared to a commit branch
git diff –cached [ID]	Compare the staging area with a branch

So the above git diff compares the workspace and the staging area. We add a line of code to the workspace, there is no add, so there is no staging area. At this time, the effect of executing git diff HEAD is different from that of git diff, but the effect is the same. Because the code is still in the workspace, it is neither added to the temporary area nor to the repository, as shown below:

• 这时候我们执行一下git status -s命令查看一下，显示如下，我们看到打印信息前面显示了一个大写的红色M但是没有最顶格写，它的意义有两点，第一M代表的是修改的意思，也就是我们是在原来基础上修改的这个文件，并不是新增的（因为之前有一次提交）；第二红色以及大写代表是还没有添加到暂存区；等会我们添加后再来对比一下。

• 这时候我们将其git add -A添加到暂存区,执行git status -s命令：查看对比刚才的，这时候会发现add之后，执行git status -s命令，大写M顶格写了，而且颜色也变为绿色的了，这就给了我们一个好的启示，因为执行git diff可能信息量太大，那么我们就可以执行git status命令查看，不仅知道哪个文件修改了，而且还知道是否添加到暂存区了。

• 这时候执行git diff会发现没有变化了，但是执行git diff –cached和git diff HEAD有变化，因为修改已经提交到暂存区，工作区和暂存区一致，但是没有提交到版本库中，如下图：

好了，git add命令讲解就到这里。下面我们讲解git commit 命令。

2.git commit命令

• 现在我们将修改已经提交到暂存区了，下一步就该提交版本库了，需要使用git commit命令

git commit命令	意义
git commit -m “msg”	将修改从暂存区提交到版本库中，msg指的是本次提交的信息
git commit –amend	修改上次提交的信息,会出现一个交互界面，相当于本次提交和上次提交合并为一个提交
git commit –amend -m “msg”	修改上次提交的信息,不会出现一个交互界面，相当于本次提交和上次提交合并为一个提交
git commit –allow-empty -m “msg”	看意思就是说允许空白提交，多用来测试时候使用

• 了解了以上命令的意思，我们就直接使用一下吧，git commit -m “add method getName()”，如下：查看一下log信息
  

The git log command is also shown here:

git log command	significance
git log	Display commit details, including commit SHA1 value, date author and commit information
git log –oneline	Only show the simple information of the submission, the first few digits of the SHA1 value, and the submission information
git log –graph	Display submission information in detail in the form of a graph chain
git log –oneling –graph	Simple display of submission information in the form of a graph chain

3.git push

git push command	significance
git push origin [branch]	Submit the code to the remote branch
git push origin [brchan] -f	Overwrite the code on the remote branch. This command is dangerous. Use it with caution. Make sure that this branch is only available for your personal work.

Finally, it is submitted. If it is a real project, it can be submitted using git push origin [branchname]. By default, if you clone the code from the remote, the default is the remote master branch. This depends on the actual branch model of the project, or it may be the develop branch. If it is the develop branch clone, you can use git push origin develop to push the repository code to the remote end to create a new branch. After others have reviewed it and there is no problem, it can be merged into the main branch. Here, our push will definitely not be successful. The display cannot be read from the remote warehouse, as shown below:

If you want to test, you can first set the project VCS->Import into Version Control->share Project on GitHub when building a Git project, so that there is a remote reference pointing to the current project, and the push can be successful. Because push is relatively simple, it mainly describes the use of some other commands, but the push command is very important, remember not to use the -f command casually.

Well, today's exchange is over, there are still many important commands, such as rebase checkout reset revert, etc., I will write them out in the following blogs slowly. If there is something wrong in the blog, please correct it.