Version Control Management

Note: All pictures in this blog are from the Internet, if there is any infringement, please contact me to delete the picture

What is version control

A management method for recording code content changes, which can be used by files or projects to roll back to a previous version. Through the differences between different versions, you can know where there is a problem, where it has been modified (you can also determine which person), etc.

centralized

The centralized version control system has a single centrally managed server that saves the revisions of all files, and people who work together connect to this server through the client to take out the latest files or submit updates. (Networked, the central server has a high risk of single point of failure)

The most obvious disadvantage of doing this is the single point of failure of the central server. If there is an hour of downtime, no one can submit updates during this hour, and they cannot work together.
If the disk where the central database resides fails, and you don't have a proper backup, you will undoubtedly lose all your data - including the entire change history of the project, leaving only the individual snapshots that people keep on their machines.

distributed

The client does not only extract the latest version of the file snapshot, but completely mirrors the code warehouse, including the complete history. In this way, if any server used for collaborative work fails, it can be restored with any mirrored local warehouse afterwards. Each clone operation is actually a complete backup of the code repository.

1. Can work without networking, because everyone's computer has a complete repository
2. After modifying a file, you only need to push your modification to others
3. Rarely do you push changes directly, instead use something that acts as a "central server". (This is just convenient for operation, exchange and modification)
4. Powerful branch management and other functions

Git

Manual: https://git-scm.com/book/zh/v2

Distributed version control system

1. Code confidentiality is poor. Once the developer clones the entire library, all code and version information can be fully disclosed;
2. Permission control is not friendly; if you need to restrict various permissions for developers, it is recommended to use SVN.

The workflow is as follows:
Clone the Git resource from the remote warehouse as the local warehouse;
checkout the code from the local warehouse and then modify the code;
submit the code to the temporary storage area before submitting the local warehouse;
submit the modification and submit it to the local warehouse; the local warehouse Each historical version of the modification is saved in ;
when the code needs to be shared with team members, the modified code can be pushed to the remote warehouse.

Index / Stage: Temporary storage area : It is used to temporarily store your changes. In fact, it is just a file, which saves the list information of the files to be submitted next time, usually in the Git warehouse directory. In Git terminology it's called an "index"

Git has three states, and your files may be in one of them: committed, modified, and staged

• Modified means that the file has been modified but not yet saved to the database. ( Modified state if a modification has been made since the last checkout but has not been placed in the staging area )
• Staged means that the current version of a modified file is marked for inclusion in the next committed snapshot. (Modified and put into the temporary storage area, it belongs to the temporary storage state)
• Committed means that the data has been safely saved in the local database. (A specific version of the file is saved in the Git directory, which belongs to the committed state)
  

The new git warehouse has only one timeline. In Git, this branch is called the main branch, that is, the master branch (renamed main). Strictly speaking, the HEAD pointer does not point to the submission, but to the master, and the master points to the submission.

Creating a branch is very fast. Except for adding a dev pointer and changing the pointer of HEAD, the files in the workspace have not changed!
eg: Git creates a new pointer called dev, which points to the same commit as the master, and then points HEAD to dev, which means that the current branch is on dev :

after a new commit, the dev pointer moves forward one step, while the master pointer remains unchanged

. Once the work is done, you can merge dev into master. How does Git merge? The easiest way is to directly point the master to the current commit of dev, and the merge is completed.
You can even delete the dev branch after you're done merging the branches. Deleting the dev branch is to delete the dev pointer. After deletion, a master branch is left:

SVN

Centralized version control system

1. The repository is centralized on the central server
2. You need to pull the latest version code of the central server under your computer, and then do the work. After you finish the work, you need to push the work you have done to the central server.
3. The centralized management method can see what other developers are doing to a certain extent, and administrators can easily grasp everyone's development permissions.

The difference between Git and SVN

Most systems store information in the form of file changelists, and such systems ( svn, etc. ) view the information they store as a set of basic files and the cumulative differences of each file over time. After we submit and update a file, the system records will record which updates have been made to this file, **indicated by the incremental symbol Δ(Delta)**.

The final version of the document is the addition of these original documents and these additions.
The problem that arises: If there are too many increments, it will take time and performance to get the final file.

Git uses the method of directly recording snapshots instead of difference comparison .
Git thinks of data more like a series of snapshots of a small filesystem. In Git, every time you commit an update or save the state of a project , it basically creates a snapshot of all the files at that time and keeps an index of that snapshot. For efficiency, if the file has not been modified, Git does not re-store the file, but only keeps a link pointing to the previously stored file. Git treats data more like a stream of snapshots.

Store snapshots of project changes over time

• The vast majority of operations in Git only require access to local files and resources, and generally do not require information from other computers on the network
• To browse a project's history, Git doesn't need to go out to the server to fetch the history and then display it -- it just reads it directly from the local database. You can immediately see the project history. If you want to view the modifications introduced between the current version and the version a month ago, Git will find the file a month ago and do a local difference calculation instead of being processed by the remote server or pulling back the old version file from the remote server. local processing.
• It means that even if there is no network (flying), the code can be operated until there is a network connection before uploading
• Git does not have a global version number, while SVN does: this is by far the biggest feature GIT lacks compared to SVN.