Git study notes (3)

Navigation assistant

5. Remote operation

5.1 Understanding Distributed Version Control Systems

5.2 Remote warehouse

5.2.1 Create a new remote warehouse

5.2.2 Clone the remote repository

5.2.3 Push to remote warehouse

5.2.4 Pull remote warehouse


5. Remote operation

5.1 Understanding Distributed Version Control Systems

The content about Git introduced in the previous blog (for example: work area, temporary storage area, version library, use of various commands, etc.) is all carried out on the local computer~

And Git is actually a distributed version control system!

The branches provided by Git allow everyone to develop only the functions they need to implement, and finally only need to merge with the master branch. If there are conflicts, the merge conflicts must be resolved; this makes the completion of the project more efficient. Great improvement, you don’t have to complete it by yourself~

Of course, Git does not only rely on branches to complete the task of multi-person collaborative development: because the above operations are all done locally, that is, only on one server; There, this person develops for a while and that person develops for a while. If this is the case, it will definitely lose efficiency~

So, Git came up with an idea: let everyone have an independent and complete warehouse on their computer, and then push the modified content on the computer to the other party every time they modify it! In this way, in terms of security, for example, if there is some failure on one computer, then the data can also exist on another computer, and you can directly copy that computer at this time; of course, if If the two computers are not in the same LAN and cannot access each other, there is no way to push them! For example, if a colleague is sick and his computer is not turned on, he cannot push it at this time; if his computer is broken at this time, he cannot push it; this is not the final solution at this time~

Therefore, Git provides a central server, which runs continuously within 24 hours~

Of course, we can also call this central server warehouse a "remote warehouse"~

At this point, each computer can clone a copy of the warehouse of the central server, and then when submitting changes on its own computer, it can be pushed to the central server, and other people can directly pull it from the central server~

In this way, you are not afraid of any problems with other people's computers~

The traditional operating system acts on task management or resource allocation on a single computer or server; while the distributed operating system acts on collaboration and resource sharing among multiple computers~


In this world, there are some bigwigs who created such a website, github, to help complete the role of "remote warehouse" (of course, github is a foreign website, and the speed is slower); there are also gitee websites in China, which also start to a similar effect~

github link https://github.com/ Gitee - code cloud link https://gitee.com/

5.2 Remote warehouse

5.2.1 Create a new remote warehouse

Create a new remote project repository:


 Fill in the basic information:

Created successfully:

  


 After the creation is successful, we can perform vague basic settings on this remote warehouse:


Explain the role of the Issues template file: a place where people with problems can communicate effectively with people in the current warehouse~

 


Explain the role of the Pull Request template file:

For developers, when they want to develop functions, they must not be developed on the master branch, but must be developed on other branches (such as the dev branch), and the final merge operation (but this is very dangerous, when learning git You can do it when you need it), but in fact, developers will not be allowed to directly perform merge operations~

In fact, developers need to submit a PR (Pull Request), which can be understood in this way: a merge application form (why merge, what functions does the dev branch have...), the application form is for the administrator Only if they agree, can the merge operation be performed~

5.2.2 Clone the remote repository

Clone a remote warehouse using the HTTPS protocol:

Then you can go to the cloud server, use the git clone command, followed by the HTTPS link you just copied:

git clone HTTPS协议链接

 It should be noted that if you want to perform the clone operation, you cannot execute it in any directory where the local warehouse exists (here, you cannot execute it in the gitcode directory)


The state at this time can be represented by a graph:

We can use the following command to view the warehouse name of the remote warehouse (the default warehouse name is origin):

git remote

 If you want to know more detailed information, you can add a -v option after it:

git remote -v

The fetch permission means pull, which is the permission to clone the remote warehouse to your own computer; the push permission means push, which is the permission to upload the remote warehouse from your computer to the remote warehouse~


Use the SSH protocol to clone a remote warehouse:
The SSH protocol uses the mechanism of public key encryption + public key login. If you want to use the SSH protocol to clone a remote warehouse, you need to put the public key on your local server on the Git server. management~

How to check whether the public key is configured on the code cloud platform:


After copying the SSH link:

 

Now you need to configure the public key again:

Step 1: Create an SSH Key. In the user's home directory, check if there is a .ssh directory. If there is, then check if there are id_rsa (private key, stored on your own server and cannot be displayed externally) and id_rsa.pub (public key, if there is Just configure it to the corresponding location) If you already have these two files, you can directly skip to the next step. If not, you need to create an SSH Key:

At this point, you need to manually create these two files:

ssh-keygen -t rsa -C "邮箱"
    注意:这里的 邮箱 需要和码云上配置的邮箱一样(可以在 设置-基本设置-邮箱管理 中查看)

 

 In the second step, you need to copy the public key word by word to the relevant location on the code cloud:

 

Finally, just enter the password of the current code cloud account. At this time, a public key has been successfully added:

In the third step, you can directly use the following command to clone the remote warehouse via SSH protocol:

git clone SSH协议链接

 

5.2.3 Push to remote warehouse

Basic process (take the master branch as an example):

First of all, it must be developed on your own computer, that is: modify it in the work area, and use the add command to add it to the temporary storage area after modification;

Then, use the commit command to submit the content in the temporary storage area to the master branch in the local warehouse;

At this time, the remote warehouse cannot see the modification of the local warehouse, so the local warehouse needs to use the push operation to push the modification to the master branch of the remote warehouse (pushing a branch in the local warehouse to a certain branch of the remote warehouse branch) ~


Explain with a picture:


 Demo:

However, it should be noted that the content of the name and email configuration items must be exactly the same as the configuration items on the code hosting platform (code cloud) (my name is not the same for now, so I need to modify it):

To push the content in the local warehouse to the remote warehouse, you need to use the following command:

git push 远程主机名 本地分支名:远程分支名
    注意:如果 "本地分支名" 和 "远程分支名" 一样,则可以省略 : 及其之后的 远程分支名
          即:git push 远程主机名 本地分支名

At this point, the push will be successful, and we can see the pushed content on Code Cloud:

5.2.4 Pull remote warehouse

When the code of the local warehouse is ahead of the remote warehouse, in order to keep the code of the remote warehouse up-to-date, the push operation must be used to push the latest submission in the local warehouse to the remote warehouse~

However, if the code of the remote warehouse is ahead of the local warehouse, at this time the local warehouse wants to see the code in the remote warehouse, then a pull operation (pull operation) is required~

for example:

There is a remote warehouse, A clones a warehouse to the local, writes "hello git~" in it, and pushes it to the remote warehouse. At this time, there is also a "hello git~" in the remote warehouse; B also clones a copy of the warehouse to the local , at this time there is a "hello git~", B added another "hello world", and then pushed to the remote warehouse; at this time, there are "hello git~, hello world"~ in the remote warehouse

At this time, the code in the remote warehouse is newer than A’s local warehouse, and this state appears: the code in the remote warehouse needs to be pulled into A’s local warehouse~


At present, there is only one server, so it is simpler to directly modify the operation on the remote warehouse (code cloud), which also has a similar effect (in daily use, you must not directly modify it in the remote warehouse):

After making changes, submit:

We can use the following command to pull the remote warehouse (the pull operation is actually a one-time help to pull + merge branches): 

git pull 远程主机名 远程分支名:本地分支名
    注意:如果 "远程分支名" 和 "本地分支名" 一样,则可以省略 : 及其之后的 本地分支名
          即:git pull 远程主机名 远程分支名

Guess you like

Origin blog.csdn.net/qq_53362595/article/details/131494016