About Git

1) Applicable objects are different. Git is for developers involved in open source projects. Because of their high level, they care more about efficiency than ease of use. Svn is different, it is suitable for ordinary company development teams. It’s easier to use.

2) The occasions used are different. Git is suitable for single project development with multiple development roles via the Internet. Svn is suitable for the development of multiple parallel projects coordinated by project managers within the enterprise.

3) The rights management strategy is different. Git does not have strict rights management controls. As long as you have an account, you can export, import, and even roll back. Svn has strict rights management, which can control the permissions of a subdirectory by group and by individual. Distinguish between read and write permissions. More stringent, does not support the rollback operation. Guaranteed code can always be tracked.

4) Branch (Branch) is not the same range. In Git, you can only branch to the entire repository, and once deleted, you can’t recover. In svn, the branch can be targeted to any subdirectory, which is essentially a copy operation. Therefore, you can create a very large, hierarchical branch, and delete it when you don’t need it, and you only need to checkout the old svn version when you need it later.

5) Based on the third point, Git is suitable for pure software projects, typically open source projects such as Linux kernel, busybox, etc. In contrast, Svn is good at multi-project management. For example, you can store a bsp/design document/filesystem/application/automated build script for a mobile project in an svn repository, or store the filesystems of five mobile projects in one svn. There must be n (number of items) * m (number of components) warehouses in git. Svn only needs a maximum of n or m.

6) Git uses the 128-bit ID as the version number, and checkout should indicate which branch is used, and svn uses an incremental serial number as the globally unique version number, which is more concise and easy to understand. Although you can use gittag to create some literal aliases, it’s only for special versions.

7) Traceability, the typical development process of git is: establish branch, develop, submit to local master, delete branch. The consequence of this is that the previous modification details will be lost. And doing the same thing under svn will not lose any details. Here is an interesting link that shows how git works in a typical way: (with the master as the core, constantly creating new branches, deleting old branches):


8) Local update, partial restore. SVN can be partially updated or restored simply because it creates a .svn folder in the folder for management. If you only want to update some parts, svn can be implemented very well. At the same time, the code is wrong, and local restore can be implemented very well. Of course, git can also be restored by historical version, but it cannot be easily restored locally.


SVN is a centralized version control system This approach brings many benefits, especially compared to the old-fashioned native VCS. Now, everyone can see to some extent what other people in the project are doing. Administrators can also easily control the permissions of each developer.

There are two sides of the matter, both good and bad. The most obvious drawback to doing this is a single point of failure for the central server. If it is down for an hour, then in this hour, no one can submit updates, restores, comparisons, etc., and they will not work together. If the central server’s disk fails and has not been backed up or backed up in time, there is a risk of losing data. The worst case 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, you can’t guarantee that all the data has been extracted. In principle, Subversion only cares about the specific differences in the contents of the file. Each time a record is updated, and what lines are updated.

The features of Subversion are summarized in the following sections:

  1. Each repository has a unique URL (official address) from which each user gets the code and data;
  2. To get the code update, you can only connect to this unique repository, sync to get the latest data;
  3. The submission must have a network connection (non-local repository);
  4. The submission requires authorization, and if there is no write permission, the submission will fail;
  5. Submissions are not always successful. If someone else submits before you, it will prompt “Change is based on outdated version, update and then submit”… and so on;
  6. Conflict resolution is a competition for submission speed: hand fast, submit first, safe and sound; slower, post-submit, may encounter troublesome conflict resolution.

Git is a distributed version control system Since its inception in 2005, Git has matured and is still highly pre-used while still retaining its initial set goals. It’s fast and extremely suitable for managing large projects, and it has an incredible nonlinear branch management system that can handle a variety of complex project development needs. Unlike SVN, Git record version history only cares whether the overall file data changes. Git does not save the difference data before and after the file content changes. In fact, Git is more like taking a snapshot of a changed file and recording it in a tiny file system. Each time an update is submitted, it takes a look at the fingerprint information of all the files and takes a snapshot of the file, then saves an index pointing to the snapshot. To improve performance, if the file has not changed, Git will not save it again, but only make a connection to the last saved snapshot.

In short, Git has the following characteristics:

  1. The repository for each clone in Git is equal. You can create your own repository from any clone of the repository, and your repository can be used as a source for others, as long as you like.
  2. Every extraction of Git is actually a complete backup of the code repository. Submissions are done entirely locally, without the need for someone else to authorize you, your repository is yours, and the submission will always succeed.
  3. Even changes based on the old version can be successfully submitted, and the commit will create a new branch based on the old version.
  4. Git’s submission will not be interrupted until your work is completely satisfactory. PUSH gives others or others PULL your repository. The merge will occur in the PULL and PUSH processes. Conflicts that cannot be resolved automatically will prompt you to do it manually.
  5. Conflict resolution is no longer SVN like to submit the same race, but only when needed to merge and conflict resolution.



In short, the company’s development team in the project development management, svn is a better choice, team members jointly maintain the company’s central version.

For open source projects, git is more suitable, everyone can maintain their own version, and there is github open source community support.