Shulou(Shulou.com)06/02 Report--

The birth of Git

As many people know, Linus created the open source Linux in 1991. since then, the Linux system has evolved into the largest server system software. Although Linus created Linux, the growth of Linux depends on the participation of enthusiastic volunteers from all over the world. With so many people writing code for Linux around the world, how is the Linux code managed?

The truth is, before 2002, volunteers around the world sent source code files to Linus via diff, and then Linus himself merged the code manually!

You might wonder, why doesn't Linus put Linux code in the version control system? Aren't there free version control systems like CVS and SVN? Because Linus is firmly opposed to CVS and SVN, these centralized version control systems are not only slow, but also must be connected to the Internet before they can be used. There are some commercial version control systems that are easier to use than CVS and SVN, but they are paid for and are not in line with the open source spirit of Linux.

However, in 2002, the Linux system had been developed for ten years, and the size of the code base made it difficult for Linus to continue to manage it manually, and the brothers in the community expressed strong dissatisfaction with this way, so Linus chose a commercial version control system, BitKeeper.

BitMover, the owner of BitKeeper, authorized the Linux community to use the version control system free of charge in a humanitarian spirit. The good situation of stability and unity was broken in 2005, due to the gathering of cattle people in the Linux community, which inevitably contaminated the habits of some Liangshan heroes. Andrew, who developed Samba, tried to crack BitKeeper's protocol (and he wasn't the only one), and was discovered by BitMover (good monitoring work! ), so BitMover got angry and wanted to take back the free use of the Linux community.

Use the power.

Linus can apologize to BitMover and promise to discipline the brothers strictly in the future. Well, this is impossible. The reality is this: it took Linus two weeks to write a distributed version control system in C, which is called Git! Within a month, the Linux system

The source code has been managed by Git! How do you define a cow? You can feel it. Git quickly became the most popular distributed version control system, especially in 2008, when the GitHub website was launched, which provided free Git storage for open source projects, and numerous open source projects began to migrate to GitHub, including jQuery, PHP, Ruby, and so on.

History is so accidental that if BitMover hadn't threatened the Linux community, we might not have a free and super-useful Git now.

Centralized vs distributed

CVS and SVN, which Linus has always hated, are centralized version control systems, while Git is a distributed version control system. What's the difference between centralized and distributed version control systems?

First of all, let's talk about the centralized version control system, where the version library is centrally stored on the central server, and when we work, we use our own computers, so we have to get the latest version from the central server first, and then start working and finish the work. Then push your work to the central server. The central server is like a library. If you want to change a book, you must first borrow it from the library, then go home to change it yourself, and then put it back in the library.

The biggest problem with the centralized version control system is that it must be connected to the Internet in order to work. If it is all right in the local area network, the bandwidth is large enough and the speed is fast enough, but if the network speed is slow on the Internet, it may take 5 minutes to submit a 10m file, which does not suffocate people.

What is the difference between a distributed version control system and a centralized version control system? First of all, the distributed version control system does not have a "central server" at all, and everyone has a complete version library on their computer, so that when you work, you do not need to connect to the Internet, because the version library is on your own computer. Since everyone has a complete version library on the computer, how can multiple people cooperate? For example, if you change file An on your computer, and your colleague changes file An on his computer, you just need to push your changes to each other and you can see each other's changes. Compared with the centralized version control system, the security of the distributed version control system is much higher, because everyone has a complete version library in the computer, it doesn't matter if one person's computer is broken, just copy one from someone else. If something goes wrong with the central server of the centralized version control system, everyone will not be able to work.

When actually using a distributed version control system, it is rare to push changes to the version library on the computers between the two people, because maybe you two are not in the same local area network and the two computers cannot access each other, or maybe your colleague is sick today and his computer is not turned on at all. Therefore, the distributed version control system usually has a computer that acts as a "central server", but the function of this server is only to facilitate the "exchange" of everyone's changes, and everyone will do the same without it, but it is just not convenient to exchange and modify.

Of course, the advantage of Git is not only that it is not necessary to connect to the Internet, but we will also see the extremely powerful branch management of Git, such as SVN, etc.

Far behind.

As the earliest open source and free centralized version control system, CVS is still used by many people. Due to CVS's own settings

The problem of design will result in incomplete submission and inexplicable damage to the version library. SVN, also open source and free, has been fixed

Some of the stability problems of CVS are the most frequently used centralized version base control systems.

In addition to being free, there are centralized version control systems for a fee, such as IBM's ClearCase (formerly owned by Rational

Acquired by IBM), characterized by the installation is bigger than Windows, running slower than snails, can use ClearCase is generally the world 500000

Strong, they have a common feature is deep pockets, or people stupid money.

Microsoft itself has a centralized version control system called VSS, which is integrated into Visual Studio. Because of its anti-human design, Lianwei

I'm too embarrassed to use it.

In addition to Git and BitKeeper, which led to the birth of Git, there are Mercurial and Bazaar similar to Git in the distributed version control system.

Wait. These distributed version control systems have their own characteristics, but the fastest, simplest, and most popular one is still Git!

Install git

Git was originally developed on Linux, and for a long time, Git could only run on Linux and Unix systems. But slowly, someone transplanted it.

To the Windows. Git now works on Linux, Unix, Mac, and Windows platforms.

Install Git on Linux

Yum-y install git

I. create a version library

20 mkdir / xgp create the required directory 21 git init git initialization

Create a username mailbox

26 git config-global user.name "admin" 27 git config-global user.email "admin@admin"

Add files to the version library

Now let's write three xgp.txt files with the following contents

23 vim xgp1.txt # xgp1 24 vim xgp2.txt # xgp2 25 vim xgp3.txt # xgp3

The first step is to tell Git with the command git add to add the file to the repository:

28 git add xgp1.txt xgp2.txt xgp3.txt

The second step is to tell Git with the command git commit to submit the file to the warehouse:

29 git commit-m "first submission"

View submission information

52 cd. / git 53 ls-a 57 cat logs/refs/heads/master 58 cat HEAD

Summary

Now let's sum up two things we learned today:

Initialize a Git repository, using the git init command.

Add files to the Git repository in two steps:

The first step is to use the command git add. Note that it can be used repeatedly to add multiple files.

The second step is to use the command git commit to finish.

Two. Time machine shuttle

We have successfully added and submitted a readme.txt file, and now it is time to continue to work, so we continue to modify the xgp.txt file to read as follows:

Xgp1

Fallback test

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

The git status command allows us to keep abreast of the current state of the warehouse. The above command tells us that readme.txt has been modified, but is not ready to submit the changes.

Although Git tells us that xgp1.txt has been modified, it would be nice to see what has been changed. For example, when you come back from a two-week vacation, on your first day at work, you can't remember how to modify readme.txt last time, so you need to use the git diff command to see:

As the name implies, git diff is to view difference, and the format displayed is the diff format commonly used by Unix. As you can see from the command output above, we have added a "fallback test" on the first line.

Once you know what changes have been made to readme.txt, you can rest assured to submit it to the repository. Submitting changes is the same as submitting a new file. The first step is git add:

Git add xgp1.txt

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

Git status tells us that the changes to be committed include xgp.txt, and the next step is to safely commit:

Git commit-m "second submission"

After the submission, we use the git status command to look at the current state of the warehouse:

Summary

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 changes.

four. Manage modification

Why is it that Git manages changes, not files? Let's do the experiment. The first step is to make a change to xgp1.txt, such as adding a line:

[root@localhost xgp] # cat xgp1.txt xgp1 fallback test xgp666xgpniubi then, add: 93 git add xgp1.txt 94 git status

Then, modify readme.txt:

[root@localhost xgp] # cat xgp1.txt xgp1 fallback test xgp666xgpniubi1 submission: [root@localhost xgp] # git commit-m "fourth submission" [master 31cb090] fourth submission 1 file changed, 1 insertion (+)

After submission, check the status:

Why, why didn't the second revision be submitted?

Take it easy, let's review the operation:

First revision-> git add-> second revision-> git commit

You see, as we said earlier, Git manages changes. When you use the git add command, the first change in the workspace is put into the staging area, ready to be submitted.

However, the second modification in the workspace is not put into the temporary storage area, so git commit is only responsible for submitting the changes to the temporary storage area, that is, for the first time

The changes are submitted, and the second changes will not be committed.

After submission, use the git diff HEAD-- readme.txt command to see the difference between the latest version in the workspace and the version library:

It can be seen that the second amendment has not been submitted.

Then how to submit the second amendment? You can continue to git add and then git commit, or don't rush to submit the first revision, git add the second revision first.

Change, and then git commit, is equivalent to merging the two changes and submitting one:

First revision-> git add-> second revision-> git add-> git commit

Okay, now, submit the second revision, and then start a summary.

Summary

Now you understand how Git tracks changes. Every time a change is made, it will not be added to the commit if it is not add to the staging area.

five. Undo the modification

Of course, you don't make mistakes. But it's 2: 00 in the morning, and you're in the middle of a work report, and you've added a line to readme.txt:

[root@localhost xgp] # cat xgp1.txt xgp1 fallback Test xgp666xgpniubi122222

Before you are ready to submit, a cup of coffee works, and you suddenly realize that "stupid boss" may cost you this month's bonus! Now that the mistake is found in time, it can be easily corrected. You can delete the last line and manually restore the file to the previous version. If

Check it out with git status:

As you can see, Git will tell you that git checkout-file can discard workspace changes:

Git checkout-- xgp1.txt [root@localhost xgp] # cat xgp1.txt xgp1 fallback Test xgp666xgpniubi1

Fortunately, you discovered this problem before commit. Check with git status to see that the changes have only been added to the staging area and have not been submitted yet:

Git also tells us that we can undo the changes to the staging area (unstage) and put them back into the workspace with the command git reset HEAD file:

[root@localhost xgp] # git reset HEAD xgp1.txt

Changes to withdraw from the temporary storage area after reset:

M xgp1.txt

The git reset command can roll back either the version or the changes to the staging area to the workspace. When we use HEAD, it represents the latest version.

Check again with git status. Now the staging area is clean and the workspace has been modified:

Remember how to discard changes to the workspace?

The whole world is finally quiet!

Now, suppose you not only correct something wrong, but also submit it from the temporary storage area to the version library, what should you do? Do you remember the version fallback section? You can fall back to the previous version. However, there is a condition that you haven't pushed your local version library remotely. Remember that Git is a distributed version control system? We'll talk about the remote version library later. Once you push the "stupid boss" submission to the remote version library, you are really miserable.

Summary

It's time for a summary again.

Scenario 1: when you change the contents of a file in the workspace and want to discard the changes in 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 temporary storage area, you want to discard the changes in two steps. The first step is to use the command git reset.

HEAD file, go back to scenario 1, and the second step is to follow scenario 1.

Scenario 3: if you want to undo this submission when inappropriate changes have been submitted to the version library, refer to the version fallback section, but only if it is not pushed to the remote.

Library.

six. Delete a file

In Git, deletion is also a modification operation. Let's add a new file test.txt to Git and submit it:

[root@localhost xgp] # vim test.txt [root@localhost xgp] # cat test.txt qqqqqqqqqqqq [root@localhost xgp] # git add test.txt [root@localhost xgp] # git commit-m "first time" [master f9688d7] first time 1 file changed, 1 insertion (+) create mode 100644 test.txt

In general, you usually delete useless files directly in the file manager, or delete them with the rm command:

At this point, Git knows that you deleted the files, so the workspace and the version library are inconsistent, and the git status command will immediately tell you which files have been deleted:

Now you have two choices. If you do want to delete the file from the version library, delete it with the command git rm, and git commit:

The file is now deleted from the version library.

Another situation is that the deletion is wrong, because there are still in the version library, so you can easily restore the mistakenly deleted files to the latest version:

$git checkout-test.txt

Git checkout actually replaces the version of the workspace with the version in the version library, which can be "restored with one click" regardless of whether the workspace is modified or deleted.

Summary

The command git rm is used to delete a file. If a file has been submitted to the version library, then you never have to worry about erroneous deletion, but be careful, you only

If you can restore the file to the latest version, you will lose the content you modified after the last submission.

seven. Git remote warehouse

Step 1: create a SSH Key. Under the user's home directory, see if there is a .ssh directory, and if so, see if there are id_rsa and id_rsa.pub files in this directory. If you already have one, you can skip to the next step. If not, open Shell (open Git Bash under Windows) and create a SSH Key:

Ssh-keygen-t rsa-C 2877364346@qq.com

You need to change your email address to your own email address, and then enter all the way, using the default value, because this Key is not used for military purposes.

So there is no need to set a password.

If all goes well, you can find the .ssh directory in the user's home directory, which contains two files, id_rsa and id_rsa.pub, which are SSH Key

Id_rsa is a private key and cannot be leaked. Id_rsa.pub is a public key and can be safely told to anyone.

Step 2: log in to GitHub and open the "Account settings", "SSH Keys" page:

Then, click "Add SSH Key", fill in any Title, and paste the contents of the id_rsa.pub file in the Key text box:

Why does GitHub need SSH Key? Because GitHub needs to identify that the submission you pushed was indeed pushed by you, not faked by others, and Git supports the SSH protocol, GitHub can confirm that only you can push it as long as you know your public key.

Clone from a remote library

The scenario now is that after you have created a Git repository locally, you want to create a Git repository in GitHub and have the two repositories synchronize remotely, so that the warehouse on GitHub can be used as a backup and allow others to collaborate through it.

First, log in to GitHub, then find the "Create a new repo" button in the upper right corner to create a new warehouse

Currently, the learngit repository on GitHub is empty, and GitHub tells us that we can clone a new warehouse from this warehouse, or associate an existing local warehouse with it, and then push the contents of the local warehouse to the GitHub warehouse.

Now that the remote library is ready, the next step is to clone a local library with the command git clone:

Git clone git@github.com:xgp666/xgp.git

Be careful to change the address of the Git library to your own, and then go to the gitskills directory to have a look, there are already README.md files.

If there are multiple individuals working together, then each person can clone one copy remotely.

You may also notice that GitHub gives you more than one address, and you can also use places like https://github.com/michaelliao/gitskills.git

Address. In fact, Git supports a variety of protocols, and the default git:// uses ssh, but other protocols such as https can also be used.

In addition to the slow speed of using https, the biggest problem is that you have to enter a password for each push, but in some companies that only open http ports

The Ministry cannot use the ssh protocol and can only use https.

Testing: creating a file in the remote library

[root@localhost xgp] # vim index.html [root@localhost xgp] # cat index.html Qqqqq [root@localhost xgp] # git add index.html [root@localhost xgp] # git commit-m "123" [master 65e2ec7] 123 1 file changed, 1 insertion (+) create mode 100644 index.html [root@localhost xgp] # git push origin master (default is master)

Browser view

Summary

To clone a warehouse, you must first know the address of the warehouse, and then use the git clone command to clone.

Git supports a variety of protocols, including https, but the native git protocol supported by ssh is the fastest.

eight. Link the remote library locally

Now that you have created a Git warehouse locally, you want to create a Git warehouse in GitHub and make the two repositories far away.

Program synchronization, so that the warehouse on GitHub can not only serve as a backup, but also allow others to collaborate through it, which is really worth killing many birds with one stone.

Currently, the learngit repository on GitHub is empty, and GitHub tells us that we can clone a new warehouse from this warehouse, or associate an existing local warehouse with it, and then push the contents of the local warehouse to the GitHub warehouse.

Now, at the prompt of GitHub, run the command under the local learngit repository:

Git remote add origin git@github.com:xgp666/xgp.git

Next, you can push all the contents of the local library to the remote library:

1.git branch-set-upstream-to=origin/master master

2.git fetch

3. Execute git branch-set-upstream-to=origin/master master again

4.git push origin master

5.git pull

6.

[root@localhost xhp] # vim aa.txt [root@localhost xhp] # git add * [root@localhost xhp] # git commit-m "4" [master 2f77003] 4 [root@localhost xhp] # git status! Located in the branch master! Your branch leads' origin/master' with a total of 3 submittals.! Use "git push" to publish your local submission! No documents to submit, clean workspace

7.git push origin master

Browser view

From now on, as long as a local submission is made, you can use the command:

$git push origin master

Push the latest changes from the local master branch to GitHub, and now you have a real distributed version library!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.