Shulou(Shulou.com)05/31 Report--

This article focuses on "what are the advantages and disadvantages of SVN and Git version control". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let the editor take you to learn "what are the advantages and disadvantages of SVN and Git version control?"

Centralized vs distributed 1.Subversion belongs to centralized version control system

Centralized version control systems have a single centrally managed server that holds revised versions of all files, while people who work together connect to the server through the client to retrieve the latest files or submit updates.

The characteristics of Subversion can be summarized as follows:

Each version library has a unique URL (official address) from which each user gets the code and data.

To get code updates, you can only connect to this unique version library and synchronize to get the latest data.

Submission must have a network connection (non-local version library)

Submission requires authorization. If there is no write permission, the submission will fail.

Submission is not always successful. If someone else submits before you, you will be prompted to "change based on the outdated version, update before submitting". And so on.

Conflict resolution is a race for the speed of submission: those who are fast, submit first, and those who are slow, submit later, may encounter trouble in conflict resolution.

Benefits:

Everyone can see to some extent what other people in the project are doing. The administrator can also easily control the permissions of each developer.

Cons: single point of failure of the central server.

If there is an hour of downtime, during that hour, no one will be able to submit updates, restore, compare, etc., and will not be able to work together. If the disk of the central server fails and the backup is not made or not backed up in time, there is also a risk of data loss. The worst-case scenario is to completely lose all historical change records for the entire project, except for some snapshot data extracted by the client, but this is still a problem, and you can't guarantee that all the data has been extracted.

In principle, Subversion is only concerned with the specific differences in the contents of the file. Each time you record which files have been updated and what lines have been updated.

2.Git is a distributed version control system.

Git records version history only concerned with whether the file data as a whole has changed. Git does not save data about differences between before and after changes in the contents of the file.

In fact, Git is more like taking snapshots of changed files and recording them in a miniature file system. Each time an update is submitted, it goes through the fingerprint information of all the files and takes a snapshot of the file, and then saves an index that points to the snapshot. To improve performance, if the file does not change, Git will not save it again, but will only attach the last saved snapshot.

In the distributed version control system, the client not only takes the snapshot of the latest version of the file, but also mirrors the original code repository completely. In this way, any server used to work together fails and can be recovered later with any mirrored local repository. Such systems can be designated to interact with several different remote code repositories. In this way, you can collaborate with people in different working groups on the same project. You can set different collaboration processes according to your needs.

In addition, because Git keeps all the historical updates about the current project on the local disk, and most operations in Git only need to access local files and resources without networking, it is fast to process. With SVN, you can't do anything without the Internet or disconnecting VPN. But with Git, even if you are on a plane or train, you can happily submit updates frequently and upload them to a remote image repository when the network is available. For other version control systems, this is almost impossible, or very troublesome.

Git has the following characteristics:

The version library for each clone in Git is equal. You can create your own version library from any clone of the version library, and your version library can also be provided to others as a source, as long as you want.

Each extraction operation of Git is actually a full backup of the code repository.

The submission is done entirely locally, without authorization, your version library is up to you, and the submission will always be successful.

Even changes based on the old version can be successfully committed, and the commit creates a new branch based on the old version.

The submission of Git will not be interrupted until your work is completely satisfied, PUSH gives or others PULL your version library, merging will occur in the process of PULL and PUSH, and conflicts that cannot be resolved automatically will prompt you to do so manually.

Conflict resolution is no longer a submission contest like SVN, but a merger and conflict resolution only when needed.

Git can also simulate a centralized mode of operation.

The Git version library is uniformly placed in the server

Git version libraries can be licensed: who can create the version library, who can PUSH it, and who can read (clone) the version library

Team members first clone the server's version library locally; and frequently update the server's version PULL

Team members PUSH their changes to the server's version library, and when others synchronize with the version library (PULL), they automatically get the changes

The centralized working mode of Git is very flexible.

You can use the code base as usual when you are away from the network where the Git server is located, such as mobile office / business trip.

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 rebase commands to make your changes appear to be based on the latest code implementation changes

Git has more working modes to choose from than Subversion.

Version Library and Workspace

Subversion's workspace and version library are completely separate, while Git's workspace and version library go hand in hand.

1.SVN 's version library is separate from the workspace

The workspace of Subversion is physically separated from the version library: the version library and workspace of Subversion are stored in different paths, usually in different hosts. In the enterprise deployment of Subversion, the version library is on the server and can only be accessed through https, http, svn and other protocols, but cannot be directly accessed by users.

The workspace of Subversion is a snapshot of the version library in a certain historical state, such as: the latest data of the version library is checked out to the workspace.

Each directory in the workspace of Subversion contains a control directory (hidden directory) named .svn, which serves the following purposes:

① identifies the correspondence between the workspace and the version library.

② contains an original copy of the files checked out in this subdirectory. When comparing the differences of file changes or the fallback of local changes, you can directly refer to the original copy without having to access the remote version library over the network.

Subversion's .svn control directory can introduce a lot of trouble:

The original text of the file under ①. SVN will result in twice as much search time and results when searching by file content in the directory.

② .svn is easy to introduce into products, especially Web applications during integration, and bringing .svn directories into Web servers can lead to security risks. Because of a Web directory that does not allow directory browsing, you can see the files that may exist in that directory through the .svn / entries file.

2. The version library and workspace of Git go hand in hand.

The version library of Git is in the same directory as the workspace, and the root directory of the workspace has a subdirectory of .git. The directory called .git is the version library itself, where Git stores metadata and object databases. This directory is very important, and every time you clone an image repository, you actually copy the data in this directory. So be sure to delete this file carefully.

Other files in the workspace are workspace files, which may be checked out from .git, checked in, or temporary files generated by running, and so on.

A version library can exist outside the workspace and become a bare (naked) version library. You can create it with the-bare parameter. However, the workspace cannot exist without the version library, that is, there must be a version library clone file named .git in the root directory of the workspace.

The version library of Git can be accessed directly by users because it is in the workspace.

① users can edit .git / config files, modify configurations, and add new sources

② users can edit .git / info/exclude files to create local ignore.

In Git's workspace, there is only a .git directory under the root of the workspace, and there is no more control directory. The only .git directory under the Git workspace is the version library, not the equivalent of .svn. If you delete the .git directory and there are no other mirrors (clones) of the version library, you destroy the entire history and the version library is lost forever.

Git is in the local .git version library, which provides a complete history of changes. In addition to data exchange with others, any version library-related operations are completed locally, more local operations, avoiding lengthy network delays and greatly saving time. For example, viewing log, switching to any historical version, and so on, do not need to connect to the network.

How does Git ensure security: create a Git library locally because the workspace and the library are in the same directory. If the workspace is deleted or the disk partition is formatted, isn't the data all gone? In fact, we can do this:

① creates a version library in one disk partition (preferably with the-bare parameter), and then clones a new one in another disk partition as a workspace. Commits in the workspace should be PUSH to another partition's version library from time to time, so that the local data is mirrored. You can even create more version library images locally, which is more secure than a Subversion library plus a workspace.

Another way to ②: share your version library with others, and when others clone your version library, you have a remote backup.

Global version number and global version number

The global version number of SVN is a great improvement compared to maintaining a set of version numbers independently of each file in CVS. Behind the seemingly simple global version number, Subversion provides support for transaction processing, and each transaction (that is, a commit) has a globally unique version number for the entire version library.

The version number of Git goes a step further, which is unique in the world. For each submission, Git calculates a SHA-1 hash value from the content of the file or the structure of the directory, resulting in a 40-bit hexadecimal string that Git uses as the version number.

1. Compare the version numbers of SVN and Git

All data stored in the Git database is indexed by this 40-bit hash value, not by the file name.

The advantage of using hash as version number is that for a distributed version control system, the version number formed by everyone after each submission will not be duplicated. Another advantage is to ensure the integrity of the data, because the hash value is calculated based on the content or directory structure, so we can also determine whether the data content has been tampered with.

The version number of SVN is consecutive, and the next version number can be predicted, while the version number of Git is not.

Because subversion is centralized version control, it is easy to achieve version number continuity. Git is a distributed version control system, and Git uses a 40-bit hash as the version number, and each person's submission is done independently, without priority (even if the submission is different, it also varies due to the direction and timing of the PUSH/PULL). Although the version numbers of Git are not contiguous, there are clues, that is, each version has a corresponding parent version (one or two), which can form a complex commit chain.

The version number of Git is simplified: Git can use a string of any length from the left as the simplified version number, as long as the simplified version number is not ambiguous. A 7-bit short version number is generally used (you can also use a shorter version number as long as there are no duplicates).

4. Partial check-out

Subversion can check out the entire library to the workspace or a directory to the workspace. For users who want to use a large, bloated version library, partial checkout is very convenient and practical.

However, Git can only be checked out completely, and partial checkout according to the directory is not supported.

1. Partial detection of SVN

In SVN, from a working tree of the warehouse checkout, each subdirectory maintains its own .svn directory, recording the changes to the files in that directory and the corresponding relationship with the server-side repository. So SVN can checkout the content under the partial path (partially checked out) instead of checkout the entire version library or branch.

Subversion has a command: svn export, you can export everything in a directory of the subversion version library to a specified directory. Subversion requires the svn export command because it exports a clean directory that does not contain .svn directories (containing configuration files and original copies of files).

2. Detection of Git

Git is not partially checked out, which does not mean that files can be viewed only if the entire library is cloned. There are many git tools that provide the ability to browse git libraries directly, such as gitweb, git version library browsing for trac, and git version library browsing for redmine.

Git-submodule can modularize the version library: Git handles this problem through sub-modules.

The submodule allows you to use one Git repository as a subdirectory of another Git repository. This allows you to clone another repository into your project and keep your submissions relatively independent.

Why doesn't Git implement the function of svn export? Because git's local repository information is fully maintained in the .git directory of the project root directory (unlike svn, there is a separate .svn directory under each subdirectory). So, just clone,checkout and delete the .git directory.

Update and submit 1. Update operation

In SVN, because there is only one central repository, the so-called remote update, also known as svn update, uses this command to keep the workspace and version repository in sync.

For git, other people's changes exist on the remote repository, so although the git checkout command is similar to update in svn in some functions (such as fetching a specific version of the warehouse), it is different in terms of remote updates and is not covered by git checkout.

Git uses git fetch and git pull to complete the remote update task, the fetch operation is only to copy the object of the remote database to the local, and then update the refs,git pull of remotes head is to add the merge operation to the current branch on the basis of git fetch.

Commit command in 2.SVN

For SVN, because it is a central form of warehouse management, there is no special concept of remote submission, and all commit operations can be thought of as updates to remote repositories. Add, modify, and delete files in the workspace to synchronize to the version library, you must use the commit command.

The add command marks files that are not marked as versioned as added and stored the next time they are submitted.

The delete command deletes the file through SVN and is valid after the next submission.

Subversion has a submit list function, which adds some files to a modified list, and submissions can only submit files that are on that list.

Temporary storage area (stage) in 3.Git

When Git manages a project, files flow in three work areas: Git's local data directory, working directory, and staging area. The temporary storage area (stage) is an intermediate state between the workcopy and the HEAD version of the version library. The so-called temporary storage area is just a simple file, which is usually placed in the git directory. Sometimes people call this file an index file, but the standard term is still a temporary storage area.

To bring a file into the scope of version management, the first step is to use gitadd to bring the file into the scope of stage monitoring, and only content updated to stage will be submitted at commit. In addition, changes to the file itself are not automatically updated to the stage, and any changes must be re-updated to the stage before they are submitted. Files that are deleted directly from the workspace need to be marked with the git rm command and deleted in the version library the next time they are submitted.

File changes in the workspace (add files, modify files, delete files) must be identified with the git add or git rm command so that the changes go into stage

Submit only changes that have been added to stage

If a file changes again after adding the stage, the subsequent changes do not change the stage. That is, the changes to the file have two states, one is the changes marked in the stage and will be put into the library on the next commit, and the other subsequent changes will not be committed unless you use the git add command to add the changes to the stage again.

Git's stag gives you a clear idea of what changes git will submit when you submit. Unless you use the-a parameter when submitting (not recommended).

We can judge its status from the location of the file: if it is a specific version of the file saved in the git directory, it belongs to the submitted state; if it has been modified and put into the temporary storage area, it belongs to the temporary storage state; if it has been modified since the last time it was taken out, but it has not been put into the temporary storage area, it is the modified state; if it is taken out, it has not been modified.

In git, because there is a difference between the local warehouse and the remote warehouse, it is different from the commit operation, and there are additional push commands for updating the data from the local warehouse to the remote warehouse. Git push can select the branch that needs to be submitted, updated, and specify the name of the branch on the remote repository.

VI. Realization of branches and milestones

Almost every version control system supports branching in some form. Using branches means that you can separate from the development mainline and continue to work without affecting the mainline. In many version control systems, this is an expensive process, and it is often necessary to create a complete copy of the source code directory, which takes a long time for large projects.

The meaning of lightweight branches / milestones is that the complexity of creating branches / milestones is o (1) and will not be slowed down by the growing size of the version base. In CVS, the complexity of creating branches is o (n), resulting in very slow branch creation of large version libraries.

Branches / milestones of 1.Subversion

Subversion lightweight branches and milestones are achieved through the svn cp command, that is, copies with history are the secret to creating branches and milestones quickly. Subversion's version library has a special design, and when you copy a directory, you don't have to worry about getting huge-Subversion doesn't copy all the data, on the contrary, it just creates an entrance to an existing directory tree. This "cheap copy" is why creating branches / milestones is lightweight.

Since the branches and tags of Svn come from directory copies, it is customary to copy them in the branches/ and tags/ directories. The so-called branch, tag and other concepts are just an object or index on different paths in the warehouse, which is not essentially different from the ordinary path, and no one can prevent the data in different branches from being modified at the same time in the same commit.

A milestone is an alias for a history submission, as a mark of history, and should not be changed. Milestones for svn should be established under the tags/ directory and should not be submitted under the milestones directory under tags/. But no one can stop the tampering of milestones without access control.

Lightweight branches and milestones of 2.Git

A branch in Git is really just a file containing the checksum of the specified object (a 40-character SHA-1 hash), so it becomes very cheap to create and destroy a branch. To put it bluntly, creating a new branch is as simple as writing 41 bytes (version number plus a newline character) to a file, which is naturally fast. The implementation of Git has nothing to do with the complexity of the project, it can always create and switch branches in a few milliseconds. This is in sharp contrast to most version control systems.

The branches of Git are completely isolated, while Subversion does not. Branches are supposed to be relatively independent namespaces, and a commit can only occur in one branch. In Git, its internal object-level dependencies may be similar to SVN, but the view representation of its working tree is completely different from that of SVN. The working tree is always a complete branch, and different branches are built by different head indexes, so you can't get the content of multiple branches in the working tree at the same time.

Git uses two types of tags: lightweight (lightweight) and annotated (annotated). The ① lightweight tag is like an immutable branch; it is actually a reference to a specific commit object. ②, which contains a note tag, is actually a separate object stored in the warehouse. It has its own checksum information, including the name, email address and date of the tag, as well as the tag description. The tag itself also allows you to use GNU Privacy Guard (GPG) to sign or verify.

Git milestones are read-only, and Git fully adheres to the spatio-temporal law that history cannot be changed. Users cannot submit to a milestone in git, otherwise the milestone is not a mark but a branch. Of course, Git allows users to delete milestones and recreate assignments to different historical submissions.

3. Switching between multiple branches

A feature switch is provided in SVN, which allows you to switch between different branches on the same working tree using switch.

The command that Git uses to switch in the branch is checkout.

VII. Branches and mergers

The branch implementation mechanisms of Git and Svn are completely different, which directly leads to the difficulties of SVN in branch merging. Although the merge tracking mechanism was introduced through the svn:mergeinfo attribute after SVN 1.5, there are still many difficulties in merging under certain circumstances.

Branch merging of 1.SVN

When you work on a branch for weeks or months, trunk changes are also going on at the same time, and the development of the two lines will be very different. When you want to merge branches back to the trunk, it may be because there are too many conflicts. It is no longer easy to merge your branch and trunk changes.

Another problem is that Subversion does not record any merge operations, and when you submit local changes, the version library cannot tell whether you got these files through svn merge or manual modification. So you have to record this information manually (indicating the specific version number or the range of the version number of the merge).

To solve the above problems can only be avoided by regularly merging the trunk into the branch, make such a policy: merge last week's changes into the branch every week, note that you need to be careful when doing so, you must record the merger process manually, in order to avoid repeated merging, you need to carefully write the merge log information, accurately describe the scope of the merge. This looks a bit like coercion.

The version number of SVN is a consecutive version number. Each new commit will have a version number of + 1, regardless of which branch the commit was made in. SVN A commit can modify different files of different branches at the same time, because the commit command can be executed in the directory above / trunk, / branches, / tags.

The submission of SVN is single-threaded, and each submission (except the original submission 0) has only one parent node (a submission node with a smaller version number).

SVN has only one submission chain, and we can't get the branch diagram only from the version number and submission description.

SVN branch diagrams can be provided in some tools (such as Tortoise SVN), which require checking the submission, treating directory copy actions as branches, and changes to svn:mergeinfo as merging, but this can lead to strange branch diagrams due to the flexibility of directory management.

Branch merging of 2.Git

The cost of creating branches in the git version library is almost zero, so don't be stingy about creating a few more branches. When git-init is executed for the first time, a branch called "master" is created. Other branches are created by hand. Here are some common branching strategies.

① creates a personal work branch of its own to avoid too much interference with the main branch master and to facilitate communication and collaboration with others.

When ② is doing risky work, it's better to create an experimental branch and throw away a mess than to clean up a mess.

When ③ merges other people's changes, it is best to create a temporary branch to merge, and then "fatch" to your own branch after the merge is complete.

Operation commands related to Git branch

Undo operation 1. Revocation of submission

Once you have completed the data submission to the server in Subversion, you will have no way to recover it from the client. You can only correct it (fallback or modify) in subsequent submissions. Because Subversion is a centralized version control, individuals cannot be allowed to tamper with submitted data. A very important feature of Subversion is that its information is never lost, even though it may have disappeared from the latest version when you delete a file or directory, but this object still exists in earlier versions of history.

Git is different. Git is a distributed version control system, and the code base belongs to the individual and allows arbitrary modification. Git ensures the uniqueness and immutability of the submission by establishing a digital summary of the submission, and ensures the security of the data through multiple copies of the version library among multiple people. Git can discard the latest one or more submissions, and using the git reset-hard command, you can discard the latest one or more submissions forever.

2. Submit changes to the description

If you are not satisfied with the submission instructions after submission, how to modify the submission instructions:

⑴ Git can use the command git commit-amend to modify the submission description.

Git can modify the last submission description. It does not mean that you cannot modify the submission description of the historical version, but that you can modify the submission description of the last version with the simplest command.

If Git modifies the submission description, it will change the submitted commit-id. That is, after the submission description is modified, a new submission will be generated.

Git can modify the history submission through git reset-hard, git commit-amend,git rebase onto and other commands.

Using the stg tool, you can more easily modify the historical submission description, including the submission content.

⑵ Subversion can also modify the submission description by modifying the svn:log version attribute of the submission:

You can modify not only the description of the last submission, but also the submission description of the historical submission

Subversion modifying the submission description is an irreversible operation and may cause the description to be maliciously modified

Subversion turns off the ability to modify the submission description by default. The administrator cannot turn on this feature until he has set up an email notification to submit a change in the description.

3. Modify and reconstruct history submission

Git can modify and ReFactor History commits: using Git's own reset and rebase commands, you can modify or restructure / ReFactor History commits, which is very flexible. Using powerful stg can make the refactoring of history submissions more concise if you are familiar with stg or Hg/MQ.

Subversion modification history submission can only be done by the administrator.

Subversion is a centralized version control system, and once the commit is completed from the client, there is no way to undo the commit from the client. However, the administrator can complete the revocation and modification of the submission on the server side, but the operation process and cost are high.

IX. Authority management

Subversion implements rights management by authorizing file directories, and subdirectories inherit the permissions of the parent directory by default. But there is also a drawback, that is, permissions cannot be inherited in the branch and cannot be authorized on a single file. For example, authorization for / trunk and its subdirectories cannot be inherited to the corresponding directory in the branch or tag.

Git's authorization is not as elaborate as Subversion. Git's authorization model can only implement zero-to-one authorization, either with full write permission, no write permission, read access to the entire version library, or disabled.

Technically, Git may never be able to do path authorization similar to SVN (read authorization):

If authorization is allowed according to the path, the relationship between clones will no longer be equal, some with more content, some with less content, and the idea of distribution will be destroyed.

If only part of the path is readable, the cloned commit and the original commit ID may be different. Because the submission of the ID is related to the submission, some of the submissions in the clone are discarded, and the ID that is bound to be submitted has to be recalculated.

Allowing all the code to be readable and only part of the code to be writable makes little practical sense under version control and leads to logical incompleteness of the submission.

So is there any way to solve the problem of authorization?

1. The company's internal code is open. That is, the code is within the company and is open to project team members equally.

two。 The company decomposes the code base reasonably and authorizes each code base separately. That is, a code base is completely open to team members and completely closed to other teams.

3. Companies use Subversion for centralized version control, and individuals and / or teams use Git-svn. This is a workaround that programmers can adopt when the company's version control strategy cannot be changed.

The deployment of the 4.Git server can actually use hooks to write authorization to branches and paths, that is, you can control who can create branches and write specific files.

Compare the advantages and disadvantages of 1.SVN

Advantages:

1. Convenient management, clear logic, in line with the thinking habits of ordinary people.

2. it is easy to manage, and the centralized server can guarantee the security.

3. The code consistency is very high.

4. it is suitable for the development of projects with a small number of developers.

Disadvantages:

1. The pressure on the server is too great, and the capacity of the database increases sharply.

2, if you can not connect to the server, basically can not work, see the second step above, if the server can not connect, it can not be submitted, restore, compare, and so on.

3, not suitable for open source development (the number of developers is very large, but Google app engine uses svn). However, the general centralized management has a very clear authority management mechanism (such as branch access restrictions), which can achieve hierarchical management, so as to solve the problem of a large number of developers.

Advantages and disadvantages of 2.Git:

1. Suitable for distributed development, with emphasis on individuals.

2. The pressure on public servers and the amount of data will not be too large.

3. Fast and flexible.

4. Conflicts can be easily resolved between any two developers.

5. Work offline.

Disadvantages:

1. The learning cycle is relatively long.

2. It is not in line with conventional thinking.

3, the code confidentiality is poor, once the developer clones down the entire library, all the code and version information can be fully disclosed.

At this point, I believe you have a deeper understanding of "what are the advantages and disadvantages of SVN and Git version control?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.