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

This article will explain the example analysis of git for you in detail. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

When we first know the version control tool, we may encounter such a situation: when we are writing our graduation thesis, we may write a preliminary version, then check it, and then modify it again to the ultimate version. Then constantly modify to derive a series of versions such as the ultimate version, the ultimate version 01 and the ultimate version 02. If we don't use distributed version control tools, we can only create a folder, then save each change as a new file, and then store different versions of our papers. But in view of the fact that I am operating alone, the trouble in this case is that I want to find a paragraph that existed in a previous version. I may need a document to find it slowly, which is obviously very inefficient. But there is another situation in which we need to cooperate with others. For example, we have a financial statement, you get a primary version and send it to the treasurer, and then your colleagues revise it when the financial revision is made. When the financial staff sends you the revised version, you also have to merge the changes made by the two people. So at this time version control tools appear, you can automatically remember every change in each file, but also multiple people can work together. Each change is recorded, and we clearly see each specific change:

Centralized version control tool

In fact, there are two kinds of version control tools, one is Git, a distributed version control tool that we are talking about today, and the other is SVN, a centralized version control tool. Many people may have heard of the name SVN. In fact, the word centralized can already reflect the shortcomings of this version control tool. Centralized version control tools can only be used online, and the version library has a single centrally managed server to manage all modified versions of all files. Before we work, we need to get the latest version from the central server and then modify it. When we are done with the changes, be sure to send our updates back to SVN to update the version library. At this time, if there are other updates before you, you may report an error: the changes are based on the outdated version, update first and then submit. So using centralized version control tools such as SVN will lead to a problem: updates that are done first will not be a problem, and those who finish the work will have to deal with code conflicts caused by the old version. These are the shortcomings of SVN, but the deadliest disadvantage of centralized version control tools such as SVN is that if there is a problem with the central server that centrally manages the version library, and it is not backed up in time, it may result in the loss of all historical change records of the entire project.

Distributed version control tool

After talking about centralized version control tools, let's talk about distributed version control tools. The most popular distributed version control tool is Git. Distributed version control tools can create a complete version library on everyone's computer, so there is no need for a server to manage the version library in the distributed version control tool set. Then let's aim at the shortcomings of SVN just mentioned to explain why we should adopt Git.

How to cooperate with Git

As I just said, centralized version control tools must be networked to be used, and the version library has a single centrally managed server to manage all modified versions of all files, but Git actually keeps all historical updates of the project on the local disk, and because most of Git operates local resources, there is no need for networking at all. In fact, Git generally has the function of a computer acting as a central server, but in fact, this central server is not used for unified management of version libraries, but for exchange and modification among colleagues. For example, if you submit your version library to the central server, if your colleagues want to synchronize your code, you only need to merge the central server version library pull with the local code. When colleagues finish uploading to the central server, we only need pull code to merge, so it is easy to synchronize the version library among colleagues. I just mentioned that SVN has a disadvantage: colleagues who finish the work first will update without problems, and colleagues who finish the work later will have to deal with code conflicts caused by the old version. However, this kind of submission competition will not occur in Git. Different colleagues can submit their own updated parts in turn. Even if the version library used is already an old version, it can be uploaded, and a new branch will be opened on the basis of the old version used. Then each update will be updated to this branch, and one day this function will be fully implemented. Then merge several branches developed by several colleagues into the main branch to merge the code. Let's give an example to explain: for example, there are three colleagues who developed based on a certain v1.0.0 version. Colleague A updates the code successfully, and colleague B updates the code. Since A has already updated the version, we have two choices at this time. The first is to merge the pull code with the local code and submit it, or at this time, because the functions they are responsible for are still being developed. We can create a new branch on this version of v1.0.0 and iterate through the update of the version. A month later, the whole function is complete, and then we can merge the three branches of our three colleagues into one branch.

How to make backup work well with Git

We have been talking about Git creating a version library locally, and the version library is stored on the local disk. If something goes wrong with the local disk, all my version libraries will be lost directly. We can do this: for example, create a version library on D disk, and then create a backup version library on F disk. Each time you submit a push to the backup version library, you can back up the version library.

Advantages of Git

The branch implementation mechanisms of Git and Svn are completely different, which directly leads to the difficulties of SVN in branch merging. When we use SVN to work on a branch for weeks or months, trunk changes are also going on at the same time, the development of the two lines will be very different, when you want to merge branches back to the trunk, probably because there are too many conflicts, it is no longer easy to merge your branch and trunk changes. The cost of creating a branch in the git version library is almost zero, so you can create your own personal work branch to avoid too much interference with the main branch master and facilitate communication and collaboration with others. When the final function completes and finally needs to merge branches to merge other people's changes, it is best to create a temporary branch to merge, merge and then fatch to your own branch.

Shortcomings of Git

There are few complete Git learning materials in Chinese.

The study cycle is relatively long.

Once the code is pull, it can fully expose the source code and version information.

This is the end of this article on "sample Analysis of git". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.