Foreword
成功不是将来才有的，而是从决定去做的那一刻起，持续累积而成。
在测试工作中，我们或多或少都接触过svn\github，当然git是趋势，笔者来一个系列的git，期待大家能有所收获。
First, the concept of version control
- Version control refers to the management of changes to various program codes, configuration files, and explanatory documents during software development. It is one of the core ideas of software configuration management.
- Its core functions include:
1. Tracking file changes, and it will faithfully record information such as when and who changed the content of the file. Each time the file is changed, the version number of the file will increase by
2. Parallel development. Software development is often a collaborative operation of multiple people. Version control can effectively solve the problem of version synchronization and development communication between different developers, improving collaborative development. s efficiency
Second, the advantages of using a version control system
- Collaboration:
Every team member can modify any file at any time without any concerns. The version control system can merge all subsequent changes into a common version, whether it is a file or the entire project. - Store versions correctly: It
is a very important habit to save changes to the project frequently. But without a version control system, this operation will be very difficult and very error-prone, such as: How do you know what changes have been made between the first version and the second version? How do you name these versions? It is difficult to track and judge changes by name - Restore the previous version:
restore some files to the version before the last change (even the entire project is restored to the previous version). - Know what happened:
Every time you submit a new change to the project, your version management system will ask you to add a short description of the change. In addition, you can also see a detailed comparison of the content before and after the change. - Backup:
Every team member will have a complete copy of the project in his local area, including the history of the entire project. If the server you depend on is down, or your storage hard drive is broken, all the recovery files you need can be obtained from another team member.
3. Contents of version control work
- Check-in and check-out control, software developers can not modify the source files in the software configuration management library, the source file modification depends on the basic file system and in their own work space. In order to facilitate software development, different software developers are required to organize their work spaces. Generally speaking, different workspaces are represented by different directories, and access to the workspace is controlled by file access permissions provided by the file system.
- The manual method of a version branch (starting with a specific version of an existing branch, but an independently developed version sequence) is to copy a copy from the main version, called the trunk, and mark it. After version control is implemented, the branch of the version is also a copy, and the copying process and marking action are completed by the version control system. There are two ways to merge versions (two versions from different branches are merged into a new version of one of the branches). One is to append the contents of version A to version B; the other is to merge the contents of version A and version B. Form a new version C.
- History records and version history records help to review software configuration items and help track the source of problems. The history record includes the most basic content such as version number, version modification time, version modifier, version modification description, and other auxiliary content, such as version file size and read-write attributes.
4. History of version control system
-
4.1 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 backup time to show the difference. The only benefit of this is simplicity, but it is particularly easy to make mistakes. Sometimes it confuses the working directory, and accidentally writes wrong files or overwrites unexpected files.
In order to solve this problem, people have developed many kinds of local version control systems a long time ago, and most of them use some simple database to record the previous update differences of files.
One of the most popular is called RCS, which is still visible on many computer systems today. The working principle of RCS is to save the patch set on the hard disk (patch refers to the changes before and after the file revision); by applying all the patches, you can recalculate the file content of each version. -
4.2 Centralized Version Control System:
Centralized Version Control Systems, or CVCS for short, is different from the local version control system. The centralized version control system allows developers on different systems to work collaboratively. Such systems, such as CVS, Subversion, and Perforce, have a single centrally managed server that stores revisions of all files, and people who work together are connected to this server through the client to take out the latest files or submit Update. Over the years, this has become a standard practice in version control systems.
Everyone can see to a certain extent what other people in the project are doing. The administrator can also easily control the permissions of each developer, and managing a CVCS is much easier than maintaining a local database on each client.
The most obvious shortcoming of the centralized version control system is the single point of failure of the central server. If there is an hour of downtime, no one can submit updates within this hour, and they will not be able to work together. If the disk of the central server fails, it happens that no backup is made, or the backup is not timely enough, there is a risk of data loss. -
4.3 Distributed Version Control System:
Distributed Version Control System, referred to as DVCS, in such systems, like Git, Mercurial, Bazaar and Darcs, the client not only extracts the latest version of the file snapshot, but completely mirrors the code warehouse Down, including complete history. In this way, any server that works together can fail and can be recovered from any local warehouse mirrored afterwards. Because every clone operation is actually a complete backup of the code warehouse.
Furthermore, many of these systems can be specified to interact with several different remote code repositories. With this, you can collaborate with people from different working groups in the same project.