1 Definition
Version Control ( Revision Control ), also known as Version Control ( System ) or ( Source ) Code Management , is used to manage different versions of the same information unit. It is often used in the software development process to manage resources such as source code, documentation, or other resources that are shared by the entire developer, so as to ensure that the same file edited by different people is updated during the development process. Version control records all changes to source code or documentation and marks them with a number called a revision . For example: a simple form of version control is as follows: the initial version is designated "1" , when changes are made, the version number is incremented to "2" , and so on.
2 Version management model
2.1 Centralized Model
Traditional version management systems use a centralized model, that is, all version control activities take place in a shared central repository. If two developers try to make changes to the same file at the same time, and do not take effective action, they will likely overwrite each other's changes. We have two ways to solve this situation, and depending on the solution, the centralized version management system is divided into two models: file locking and version merging.
2.1.1 File Locking
The easiest way to solve this problem is to allow only one person to modify a file in the repository at a time. First of all, before the modification, the person who arrives first will " lock " the file, then another person cannot modify the file, and he can only read the file until the person who comes first releases the " lock " . This is also known as the " lock - modify - unlock " model. Early VSS used this model.
The disadvantage of the lock - modify - unlock model is that it is too restrictive:
n If a person acquires a " lock " and he does not release the " lock " for a long time , other developers cannot develop normally.
Locking can lead to unnecessarily linear development, and if two developers don't conflict at all on the same file, they can make changes to the code at the same time.
2.1.2 version merge
Many version control systems, such as CVS , Subversion , allow many developers to make changes to the same file at the same time. The developer who made the first commit always succeeds when they " commit " to the central repository after making changes. The version control system has the ability to merge all changes into the central repository as other developers commit . However, if two developers' changes overlap, it will cause " conflicts " , then you will see a set of conflict sets, you can choose to modify your own code or negotiate with other developers to resolve the conflict .
2.2 Distributed Model
In contrast to the client - server approach of the centralized model , the distributed model takes a peer-to-peer approach. Common centralized management systems such as CVS and Subversion have been widely used, but the centralized management has corresponding defects, such as over-reliance on a unique repository: once the centralized repository cannot be properly connected, the entire system will be paralyzed . The greatest ability of the distributed model is that it can maintain a distributed version library. Distributed developers can establish remote CVS , Subversion , and P4 protocol version library mirrors through distributed version management, and choose to work in their own appropriate mirror version library. The mirror can even be local, and the entire job can be done offline, then sync the mirror repository to the main repository when needed. Currently,Version management systems that use a distributed model include Bazaar , Git , Mercurial , etc.
3 Introduction to common terms
3.1 Branch ( Branch )
At one point in time, make a copy of a file under version control, and from then on, the two copies can be developed independently of each other without interfering with each other.
3.2 Take out ( Check-out )
A " pull " is to create a working copy of the repository locally.
3.3 Commit ( Commit )
A " commit " writes local changes back to the repository or merges them into the repository.
3.4 Conflict _ _
When developers commit changes to the same file at the same time, and the version system cannot merge them together, conflicts arise, requiring manual merges.
3.5 Export ( Export )
Exporting is very similar to taking out, except that the exported file is no longer under version control, and is often used to release code.
3.6 Import ( Import )
Importing means copying local files into the repository for the first time, keeping them under version control.
3.7 Merge ( Merge )
Merging is the unification of all changes to a file into a file.
3.8 Warehouse ( Repository )
A repository is where current and historical files under version control reside, usually on the server side.
3.9 Working copy ( Working copy )
Take a local copy from the archive. All file changes in the archive are modified from a working version, which is the origin of the name.