What version control system does git belong to?

Git is a distributed version control system. Git is an open source distributed version control software developed by Linus Torvalds to help manage Linux kernel development. It is used to effectively and quickly handle version management of projects from small to very large projects.

The operating environment of this tutorial: windows7 system, mysql8.0.22 version, Dell G3 computer.

What version control system does git belong to?

Git is a distributed version control system.

Git has the following characteristics:

• The version library of each clone (clone) in Git is equal. You can clone any repository to create your own repository, and your repository can also be used as a source for others if you wish.

• Every extraction operation of Git is actually a complete backup of the code repository.

• Submission is completely completed locally, no one else needs to give you authorization, you are the master of your repository, and the submission will always be successful.

• Even changes based on the old version can be submitted successfully, and the submission will create a new branch based on the old version.

• Git submission will not be interrupted until you are completely satisfied with your work. PUSH to others or others to PULL your repository. Merging will occur during the PULL and PUSH processes. Conflicts that cannot be resolved automatically will prompt you to complete them manually.

• Conflict resolution is no longer like a submission competition like SVN, but merging and conflict resolution are performed when needed.

• Git can also simulate a centralized working mode

• The Git version library is unified on the server

• You can authorize the Git repository: who can create the repository, who can PUSH to the repository, and who can read (clone) the repository

• Members of the team first Clone the server's repository locally; and frequently pull (PULL) the latest updates from the server's repository;

• Team members push (PUSH) their changes to the server's repository In the repository, when others synchronize with the repository (PULL), changes will be automatically obtained

• Git’s centralized working model is very flexible

• You can completely disconnect from the network where the Git server is located, such as when working on the move/on a business trip, and still use the code library as usual

• You only need to be able to access the network where the Git server is located , PULL and PUSH can complete synchronization with the server and submit

• Git provides the rebase command, which can make your changes appear to be based on the latest code implementation

• Git has more working modes to choose from than Subversion.

What is "version control"?

Version control is a system that records changes in the content of one or several files so that you can check the revision status of a specific version and backtrack in the future. Any type of file can be version controlled.

If you are a graphic or web designer, you may need to save all revisions of a certain picture or page layout file (this may be a feature you are very eager to have), using a version control system (VCS) ) is a wise choice.

With it, you can roll back a certain file to its previous state, or even roll back the entire project to its state at a certain point in the past. You can compare the details of the changes in the files and find out what was last Who modified which part to find out what caused the weird problem, who reported a functional defect when, and so on.

Using a version control system usually also means that even if you change, delete, or delete files in the entire project at once, you can still easily restore them to their original appearance. But the additional workload is minimal.

Local version control system

Many people are used to copying the entire project directory to save different versions, and may also change the name and add the backup time to show the difference. The only advantage of doing this is that it is simple, but it is also very easy to make mistakes. Sometimes the working directory is confused, and the wrong file is accidentally written or an unexpected file is overwritten.

In order to solve this problem, people have developed many local version control systems a long time ago, most of which use some simple database to record the differences in previous updates of files.

Figure 1. Local version control.

The most popular one is called RCS, which can still be seen on many computer systems today. The rcs command can be used even after installing the developer toolkit on popular Mac OS X systems. It works by saving a set of patches (a patch is a change before and after a file is revised) on the hard disk; by applying all the patches, the contents of each version of the file can be recalculated.

Centralized version control system

Next, people encountered another problem, how to let developers on different systems work together?

Therefore, Centralized Version Control Systems (Centralized Version Control Systems, CVCS for short) came into being. Such systems, such as CVS, Subversion and Perforce, have a single centrally managed server that saves revisions of all files, and people working together connect to this server through clients to retrieve the latest files or commit renew. This has become standard practice for version control systems over the years.

Figure 2. Centralized version control.

This approach brings many benefits, especially compared to In terms of old-fashioned local VCS. Now, everyone can see to some extent what others in the project are working on. Administrators can also easily control the permissions of each developer, and managing a CVCS is far easier than maintaining local databases on each client.

There are two sides to things, good and bad. The most obvious disadvantage of doing this is that the central server is a single point of failure. If it is down for one hour, no one can submit updates during this hour, and no one can work together. If the disk on which the central database resides becomes corrupted and you don't back it up properly, you will undoubtedly lose all data - including the project's entire change history, leaving only the individual snapshots that people keep on their own machines. A similar problem exists with local version control systems. As long as the entire project's history is kept in a single location, there is a risk of losing all historical update records.

Distributed Version Control System

So the Distributed Version Control System (Distributed Version Control System, referred to as DVCS) came out. In such systems, such as Git, Mercurial, Bazaar, and Darcs, the client does not only extract the latest version of the file snapshot, but completely mirrors the code repository. In this way, if any server used for collaborative work fails, any mirrored local warehouse can be used to recover afterwards. Because every cloning operation is actually a complete backup of the code repository.

Figure 3. Distributed version control.

Furthermore, many of these systems can be specified to work with several different remote Interact with the end code repository. This way, you can collaborate with people from different working groups on the same project. You can set up different collaboration processes as needed, such as hierarchical model-based workflows, which was not possible in previous centralized systems.

Recommended study: "Git Tutorial"

The above is the detailed content of What version control system does git belong to?. For more information, please follow other related articles on the PHP Chinese website!