Git tutorial (the most detailed, the most stupid)


1. Git introduction

1.1 history

Git is the most advanced distributed version control system in the world.
Since then, Linus has been the largest open source software system in Linux since 1991. Although Linus created Linux, the growth of Linux relies on the participation of enthusiastic volunteers from all over the world. With so many people writing code for Linux around the world, how is Linux code managed? The fact is, * before 2002, volunteers around the world sent source code files to Linus through diff, and then Linus himself merged the code manually! You might wonder why Linus doesn’t put Linux code in version control? Isn’t there a free version control system like CVs and SVN? Because Linus firmly opposes CVs and SVN, these centralized version control systems are not only slow, but also have to be networked to use. There are some commercial version control systems that are easier to use than CVs and SVN, but they are paid for and do not conform to the open source spirit of Linux. However, by 2002, the Linux system had been developing for 10 years. The size of the code base made it difficult for Linus to continue to manage it manually. The brothers in the community also expressed strong dissatisfaction with this method. So Linus chose a commercial version control system, bitkeeper, Bitmover, the owner of bitkeeper, has granted the Linux community free access to the version control system in a humanitarian spirit. **The good situation of stability and unity was broken in 2005, because the gathering of niuren in the Linux community inevitably tainted some Liangshan heroes’ habits. Andrew, who developed samba, tried to crack bitkeeper’s protocol (and he was not the only one to do so), and was discovered by bitmover (good monitoring work! )So bitmover got angry and wanted to take back the free use of the Linux community. Linus can apologize to bitmover and promise to discipline the brothers strictly in the future. Well, it’s impossible. The actual situation is as follows:

Linus spent two weeks writing a distributed version control system in C, which is git! Within a month, the source code of Linux system has been managed by git! What is the definition of a cow? You can experience it. Git has rapidly become the most popular distributed version control system. Especially in 2008, GitHub website was launched. It provides free git storage for open source projects. Numerous open source projects have started to migrate to GitHub, including jQuery, PHP, ruby, etc. History is such an accident. If bitmover didn’t threaten the Linux community, we might not have a free and super easy-to-use git now.

1.2 git features

Version control: it can solve the problem of code developed by many people at the same time, and can also solve the problem of retrieving historical code.

Distributed: Git is a distributed version control system. The same git repository can be distributed to different machines. First of all, find a computer to act as a server, turn it on 24 hours a day, and everyone else will clone a copy from the “server” warehouse to their own computer, and push their respective submission to the server warehouse, and pull others’ submission from the server warehouse. You can build the server yourself or use GitHub website.

2. Installation configuration

Windows installation link

Click next all the way, and the installation position is on disk C.

After installing Git

Type git in the terminal,

The appearance of such a picture means that your Git is installed. There should be applause here~~

3. Create a version library

(1) Create a new directory GIT_ Test, in Git_ Create a version Library in the test directory. The command is as follows:

Then initialize the warehouse

Note: you can see in GIT_ A hidden. Git directory is created under the test directory, which is the version Library Directory.

4. Creation and rollback of version

4.1 use

(1) At Git_ Create a file in the test directory code.txt The editing contents are as follows:

(2) You can create a version using the following two commands:

git add code.txt
Git commit - M "version 1"

(3) Use the following command to view the version record:

git log

(4) Continue editing code.txt Add a line to it.

(5) Use the following command to create another version and view the version record:

(6) Now if you want to go back to a certain version, you can use the following command:

Head refers to the latest version [please remember to death],Head ^ indicates the previous version of the current version, head^^Represents the previous version of the current version. You can also useHEAD~1Represents the previous version of the current version,HEAD~100Represents the first 100 versions of the current version.

Because the content of version 1 is 1 line:

this is the first line

Because version 2 contains two lines:

this is the first line
this is the second line

$git reset -- hard head ^ head is now at 51d36c7 version 1
Make the pointer head point (backward) to version 1,
Therefore, the printed content is the content of version 1, that is, this is the first line

(7) What if we want to go back to version 2 now? You can use the following commands:

Git reset -- hard version number

(8) Execute the following command at the terminal:

Version 2 is back, and the content is the same.

Then play

Exit the terminal and re-enter:

This reentry terminal operation makes us unable to see the version number of version 2. What to do if we want to go back to version 2?
Command: git reflog to view the operation record.

Error examples:

The reason is that if you go backwards according to the current version 1, you will never advance to version 2? Logic error.

Correct example:
Use the version number.

To view the contents of version 2:

What’s the difference between version 1 and version 2?

This thing is like a game update. Version 2 adds new features to version 1, and the content of version 1 does not change. For example, when the king’s glory version is updated, the interface will always change, but the hero’s attributes (skill, name) will not change.

4.2 workspace and cache

4.2.1 working directory

A directory in a working directory computer, such as our GIT_ Test is a workspace.

4.2.2 repository

The workspace has a hidden directory.gitThis is not a workspace, but a git version library. There are many things stored in Git’s version library. The most important is the temporary storage area called stage (or index), the first branch master created by git automatically for us, and a pointer to the master named head.

Because when we create the GIT version library, GIT automatically creates the only master branch for us. Now, GIT commit is to commit changes to the master branch.

You can simply understand that the file changes that need to be submitted are put into the temporary storage area (computer cache), and then all the changes in the temporary storage area are submitted at one time.

As mentioned earlier, when we add files to the version library, it is implemented in two steps:
The first step is to add the file with git add, which is actually to add the file changes to the temporary storage area
The second step is to commit the changes with git commit, which actually commits all the contents of the staging to the current branch.

(1) Next, create a file code2.txt in the GIT test directory, and then edit the content as follows:

(2) Then edit code.txt The operation is as follows:

Note that creating and editing files are done in the workspace.

(3) Use the following command to view the status of the current work tree:

git status


It reminds us code.txt Was modified, but code2.txt was not tracked.

(4) We use the following command code.txt Add code2.txt and code2.txt to the temporary storage area, and then execute the GIT status command. The results are as follows:

Note: all git add commands store all committed changes to the temporary storage area.

(5) Git commit can then commit all changes to the staging to the branch and create a version at once.

Note: the pointer head always points to the current version. At this point, the current version is version 3.

(6) Once submitted, if you haven’t made any changes to the workspace, the workspace is “clean.”. Execute the following command to find out:

Now our version library has become a purple sauce

4.3 management modification

Git manages changes to files, which only commit changes to the staging area to create versions.

(1) Editor code.txt And use the GIT add command to add it to the staging area.

(2) Continue editing code.txt And add a line to it.

(3) Git commit creates a version and uses git status to view it. The second modification is found code.txt After the content, there is no workspace to add it, so the version is not committed when it is created.

Note: for code.txt For example, version 1 corresponds to first line, and so on.

4.4 revocation of modification

(1) Continuing with the above operation, we can use git checkout – < File > to discard the workspace changes. Execute the following command and find that the workspace is clean and the second change is gone.

(2) We continue to edit code.txt And add the following to it, and add it to the staging area.

(3) Git also tells us that with the command git reset head file, you can undo the modification of the temporary storage area and put it back into the workspace.

(4) Now if you want to throw it away code.txt To modify, execute the following command.

Now, if you not only correct something, but also commit it from the staging area to the version library, you need to do a version rollback.

Scenario 1: when you change the contents of a file in the workspace and want to discard the changes to the workspace directly, use the command git checkout – file
Scenario 2: when you not only change the contents of a file in the workspace, but also add it to the staging area, you want to discard the changes. There are two steps:
In the first step, use the command git reset head – file to return to scenario 1,
The second step is to operate according to scenario 1.
Scenario 3: if you want to cancel the submission when you have submitted inappropriate changes to the version library, refer to the section on version rollback.

4.5 differences in comparison documents

Compare the differences between the workspace and files in a version:

(1) Continue editing the file code.txt , add a line to it.

(2) Now compare it to the workspace code.txt And head version code.txt The difference. Use the following command:

(3) Discard changes to the workspace using the following command.

Compare the differences between the two versions
(1) Now compare head with head ^ code.txt Use the following command:


4.6 deleting files

(1) We delete code2.txt from the directory.

At this time, GIT knows that the files have been deleted. Therefore, the workspace and the version library are not consistent. The GIT status command will immediately prompt which files have been deleted.

(2) Now you have two choices. In one case, if you really want to delete the file from the version library, use the command gitrm to delete [permanently delete, cannot undo], and Git


Another case is that the deletion is wrong. You can directly use git checkout – code2.txt, so that the file code2.txt comes back.
Note: there is a difference between the two situations:
When the first case is executed [permanently deleted, cannot be undone], and then the second case is executed, an error will be reported

Extended version:

Short version:

The command RM delete is a permanent deletion. If you want to recover the data, you can restore / scan the hard disk;
The command git RM is used to delete a file. If a file has been submitted to the version library, you never have to worry about deleting it, but be careful. You can only restore the file to the latest version, and you will lose the content you modified after the last submission.

5. Branch management

5.1 concept

The branch is the parallel universe in science fiction movies. When you are working hard to learn git in front of the computer, the other is you are working hard to learn SVN in another parallel universe.
If two parallel universes don’t interfere with each other, it doesn’t matter to you now. However, at some point in time, two parallel universes merge, and as a result, you learn both GIT and SVN!

What’s the use of branching in practice?
Suppose you are ready to develop a new function, but it takes two weeks to complete. In the first week, you wrote 50% of the code. If you submit it immediately, because the code is not finished, the incomplete code base will cause others to be unable to work. If the code is completed and submitted again, there is a huge risk of losing daily progress.

Now that you have branches, you don’t have to be afraid. You create a branch that belongs to your own, which can’t be seen by others, and continues to work normally on the original branch. However, if you work on your own branch, you can submit it if you want, and then merge it to the original branch at one time after the development is completed. In this way, it is safe and does not affect other people’s work.

5.2 create and merge branches

Git strings our previous versions into a timeline, which is a branch. Up to now, there is only one timeline. In git, this branch is called the master branch. Strictly speaking, head does not point to commit, but to master, and master refers to commit. Therefore, head refers to the current branch.

(1) When submitting, the hemaster can point to the current branch with the latest branch

Each time you commit, the master branch moves forward one step. As you continue to commit, the line of the master branch grows longer and longer.
(2) When we create a new branch, such as dev, GIT creates a new pointer called dev, which points to the same commit of master, and then points head to dev, which indicates that the current branch is on dev

Git creates a branch very quickly, because there is no change in the workspace file except adding a dev pointer and changing the direction of head.

(3) However, from now on, the modification and submission of the workspace are aimed at the dev branch. For example, after a new commit, the dev pointer moves forward one step, while the master pointer remains unchanged

(4) If we have finished our work on dev, we can merge dev into master. How does git merge? The simplest way is to directly point the master to the current commit of dev to complete the merge

Git merges branches quickly, changing the pointer and changing the contents of the workspace.

(5) After merging branches, you can even delete the dev branch. To delete the dev branch is to delete the dev pointer. After deleting, we will have a master branch

(1) Execute the following command to see how many branches are currently in use and see which branch is working under.

(2) Next, create a branch Dev and switch to it to work.

(3) Let’s revise it code.txt Content, add a line to it and submit it.

(4) After the work of the dev branch is completed, we can switch back to the master branch

see code.txt , found that the added content is missing. Because that commit is on the dev branch, and the commit point of the master branch is not changed at the moment. [we need to taste it carefully here]

(5) Now, we merge the work of the dev branch into the master branch

The GIT merge command merges the specified branch to the current branch. After merging, check again code.txt As you can see, it is exactly the same as the latest commit of the dev branch.

Noting the rast forward information above, GIT tells us that this merge is in “fast forward mode”, that is, it directly points the master to the current commit of dev, so the merging speed is very fast.

(6) After the merge is completed, you can safely delete the dev branch. After deletion, check the branch, and only the master branch is left.

View branch:git branch
Create branch:git branch <name>
Switch branch:git checkout <name>
Create + switch branch:git checkout -b <name>
Merge a branch to the current branch:git merge <name>
Delete branch:git branch -d <name>

5.3 conflict resolution

Merging branches is not always easy.

(1) Create a new branch, dev.

(2) Modification code.txt Content and submit.

(3) Switch back to the master branch.

(4) In the master’s code.txt And submit a line.

In this case, GIT can’t perform “quick merge” and can only try to merge their own changes, but the merging may conflict.

(5) Execute the following command to try to merge the dev branch into the master branch.

Causes of conflict:
Now, the master branch and the dev branch have new submissions respectively, and the same file has been edited

Git tells us, code.txt There are conflicts in the file. You must manually resolve the conflicts before submitting.

The most important step:

(6) Git status can also tell us about the conflicting files:

(7) View code.txt Content of.

(8) Git<<<<<<<<,========,>>>>>>>>Mark the contents of different branches and save them after modification as follows:

(9) Re submit.

(10) Now, the master branch and dev branch are shown in the following figure:

(11) The GIT log with parameters can also be used to see the merging of branches

(12) Finally, you can delete the dev branch

5.4 branch management strategy

Usually, when merging branches, GIT uses thefast forwardHowever, some fast merges fail and there are no conflicts when merging. At this time, GIT will help us make a new submission after merging. However, in this mode, after deleting branches, the branch information will be lost. [pop up information]

(1) Create and switch to the dev branch.

(2) Create a new file code3.txt, edit the content as follows, and submit a commit.

(3) Switch back to master branch, edit code.txt And make a submission.

(4) Merge the contents of the dev branch to the master branch.

(5) When the following prompt appears, this is because the quick merge cannot be performed this time. So git prompts for the merge description information. After entering the merged content, GIT will automatically create a new submission.

Press:xSave and exit.

(6) Use the branch command to view branch information.

(7) Delete the dev branch.

If you want to force the fast forward mode to be disabled, GIT will generate a new commit when merge, so that the branch information can be seen from the branch history.

(1) Create and switch to the dev branch.

(2) Modification code.txt Content and submit a commit.

(3) Switch back to the master branch.

(4) To merge the dev branches, please note the – no FF parameter, which means fast forward: is disabled

Because a new commit will be created in this merge, add the – M parameter and write the commit description in it.

5.5 bug branch

In software development, bugs are just like everyday life. If you have a bug, you need to fix it. In git, because the branches are so powerful, so,
Each bug can be fixed by a new temporary branch. After fixing, the branch is merged and the temporary branch is removed.

(1) When you receive a task to fix a bug code named 001, naturally, you want to create a branch bug-001 to fix it, but wait, the work currently in progress on dev has not been submitted:

It is recommended to clear the screen first.

It’s not that you don’t want to submit, but that the work is only half way through and can’t be submitted yet. It is estimated that it will take another day to complete. However, the bug must be fixed within two hours. What to do?

(2) Git also provides a stash function, which can “store” the current work site and continue to work after the site is restored

(3) First, determine which branch to fix the bug on. Assuming that it needs to be fixed on the master branch, create a temporary branch from the master branch

(4) Now fix the bug. Suppose you put the code.txt Delete line 9 in and submit.

(5) After completing the branch repair, switch to the branch of master-001.

(6) Now that bug-001 is fixed, it’s time to go back to the dev branch!

(7) The work area is clean. Where has the work site been stored? Use git stash list command to see: [help us list saved work sites]

The job site is still in use. Git has stored the stash content in some place. It needs to be restored:

When fixing bugs, we will fix them by creating new bug branches, merge them, and finally delete them;
When the work in hand is not completed, first put the work sitegit stashThen fix the bug, fix it, and thengit stash pop, restore the work site.

6. Using GitHub

Warehouse creation 6

(1) Sign up for GitHub account

After logging in, click “new repository”

(2) In the new page, enter the name of the item [e.g. 2020], and check the Click ‘create repository’

It’s done here.

6.2 add SSH account

(1) Click the drop-down triangle behind the account picture and select ‘Settings’. If a machine needs to interact with the warehouse on GitHub, then add the SSH public key of this machine to the GitHub account.

(2) From the GIT command line, go back to the user’s home directory and edit the file.gitconfig, modify the GIT configuration of a machine.
Modify to the email address when registering GitHub and fill in the user name.


6.3 cloning project


6.4 upload branch / push code

(1) After the project is cloned locally, execute the following command to create the branch:

(2) Create a And submit a version:

(3) Before pushing, the file list on GitHub is as follows:

(4) Before pushing, the list of branches on GitHub is as follows:

(5) Push branch is to push all the local commits on the branch to the remote library. When pushing, the local branch should be specified. In this way, GIT will push the branch to the corresponding remote branch of the remote library

git push origin Branch name
For example:

git push origin smart

(6) Look at the GitHub branch again:
Next, reload the page:

Click smart, and then click As shown in the figure:

6.5 trace the local branch to the server branch

Git branch -- set upstream to = origin / remote branch name local branch name

For example:

 git branch --set-upstream-to=origin/smart smart

My social address:

6.6 pull code from remote branch

git pull orgin Branch name
For example:

git pull orgin smart

Using the above command will download and merge the code from the remote branch smart to the local branch.

7. Working with Git

Project Manager:
(1) The project manager builds the framework of the project.
(2) After building the project framework, the project manager puts the project framework code into the server.

General staff:
(1) On your own computer, generate the SSH public key, and then give the public key to the project manager, who will add it to the server.
(2) The project manager will give each team member the address of the project code, and the team member will download the code to their own computer.
(3) Create a local branch, dev, and do daily development in the dev branch.
(4) After each employee has developed their own code, they need to publish the code to the remote dev branch.

There are usually two branches in the project, such as:
Master: used to save the published project code.
Dev: used to save code during development. All team members develop their own code and submit it to the branch.

At this point, the GIT tutorial is finished. It is not only a record of our own practice [I can’t remember ha ha], but also can help more Taoists manage and control the code. If the content is useful to readers, please pay attention to me and praise for thinking!

Finally, we present the notes of the map

8. Mind map notes

This article about git use tutorial (the most detailed, the most stupid) article introduced here, more relevant git use tutorial content please search the previous articles of developeppaer or continue to browse the related articles below, I hope you can support developeppaer more in the future!