The main basic differences:

1.GIT is distributed, SVN is not:

This is the core difference between GIT and other non-distributed version control systems such as SVN, CVS, and so on. If you can understand this concept, then you have already started half of the. Need to make a statement, GIT is not the first or only distributed version control system. There are some systems, such as Bitkeeper, etc., is also running in the distributed mode. But GIT in this area to do better, and there are more powerful features.

GIT has its own centralized repository or server as well as SVN. However, GIT is more likely to be used in distributed mode, that is, each developer from the central repository/server check out code will be on their own machine to clone a copy of their own. You can say that if you are trapped in a place where you can not connect to the network, like on a plane, a basement, an elevator, etc., you can still submit a document, view the historical version record, create a project branch, and so on. For some people, it does not seem much to use, but when you suddenly encounter no network environment, this will solve your big trouble.

Similarly, this distributed mode of operation for the development of open source software community is also a great gift, you do not have to make a patch as before, sent by email, you only need to create a branch to the project team Send a push request. This keeps your code up-to-date and will not be lost during transmission. GitHub.com is one such excellent case.

Some rumors coming out for future versions of subversion will also be based on distribution patterns. But at least still can not see now.

2.GIT the contents of the way by meta data storage and SVN is by file:

All the resource control system is the file meta information hidden in a similar. Svn,. Cvs and other folders. If you compare the size of the .git catalog with .svn, you will find them a big gap. Because the .git directory is a clone version of the repository on your machine, it has all the things on the central repository, such as labels, branches, version records, and so on.

3. The GIT branch and the branch of SVN are different:

Branch in SVN is not special, is the repository of another directory. If you want to know if you have merged a branch, you need to manually run the command like this svn propget svn: mergeinfo to confirm that the code is merged. Thanks to Ben for pointing out this feature. Therefore, there are often some branches of the situation is missing.

However, dealing with the GIT branch is quite simple and interesting. You can from the same work directory to quickly switch between several branches. You can easily find the merged branch, you can simply and quickly merge these files.

4.GIT does not have a global version number, and SVN has:

So far this is the biggest feature that GIT lacks compared to SVN. You also know that the SVN version number is actually a snapshot of any source code for the corresponding time. I think it is the biggest breakthrough from CVS to SVN. Because GIT and SVN are conceptually different, I do not know what the characteristics of GIT correspond to. If you have any clues, please share it with everyone in the comments.

Update: Some readers point out that we can use GIT’s SHA-1 to uniquely identify a code snapshot. This does not completely replace the digital version number that is easy to read in SVN. But the user should be the same.

5.GIT content integrity is better than SVN:

GIT’s content store uses a SHA-1 hash algorithm. This ensures the integrity of the code content and ensures that the repository is damaged in the event of disk failures and network problems.

6) Git downloaded from the local network can not see all the log, it is easy to learn, SVN need to network;

7) SVN in the Commit before, we have suggested that the first update, with the local code compiler no problem, and to ensure that the development of the normal function and then submitted, so that in fact very troublesome, there are several colleagues without Updata, Commit , There have been some mistakes, delayed everyone’s time, Git may be less of this situation.

Other differences:

1) Speed:

Cloning a new catalog, with the same five (only five) branch, SVN is the same time copy five versions of the file, that is repeated five times the same action. And Git just fetches the elements of each version of the file and then loads only the primary branch. In my experience, cloning a SVN with nearly ten thousand commit (commit), five branches, each branch with about 1500 files, spent nearly an hour! And Git only took a mere 1 minute!

2) repository:

As far as I know, SVN can only have a designated central repository. When the central repository has a problem, all the work members are paralyzed until the repository is repaired or the new repository is set up.

And Git can have the unlimited library. Or, more correctly, each Git is a repository, the difference is whether they have an active directory (Git Working Tree). If something happens to the main repository (for example, in the repository of GitHub), the work member can still submit it to its own local repository and wait for the main repository to be restored. Work members can also submit to other repositories!

3) Branch (Branch)

In SVN, the branch is a complete directory. And this directory has a complete actual file. If the work member wants to open a new branch, it will affect the “world”! Everyone will have the same branch as you. If your branch is used to disrupt the work, it will be like an infectious disease.

And Git, each member of the work can be in their own local repository to open unlimited branches. Example: When I want to try to destroy my own program (security test) and want to keep these modified files for later use, I can open a branch and do what I like.There is no need to worry about hindering other working members. As long as I am not merging and submitting to the main repository, no working member will be affected. Wait until I do not need this branch, I just want it from my local repository can be deleted. Painless itch.

Git’s branch name can be used with different names. For example, My local branch is called testing, and the name in the main repository is actually master.

The most worth mentioning I can Git any commit point (commit point) to open the branch! (One way is to use gitk -all to view the entire commit record, and then open the branch at any point.)

4) Commit

At SVN, when you submit your finished product, it will record directly to the central repository. When you find a serious problem with your finished product, you can not prevent it from happening. If the network is interrupted, you can not submit!

And Git’s submission is entirely part of the local repository. And you only need to “push” (git push) to the main repository can be. Git’s “push” is actually in the implementation of “synchronization” (Sync).

5) re-set the starting point (Rebase)

I did not try in SVN, do not know if there is such a function.

At Git, if you want to set up someone else’s latest commit as the starting point for this branch now, just execute git rebase branch_name. The difference between this and merge is that merge will be considered up to date based on the changes, and Rebase will ask you to resolve the conflicting places where both parties have modified.

A – B – E

\ – C – D

A – B – E

\ – C – D

6) system files

SVN will place a .svn in each directory. If you want to remove these .svn is very tired.

And Git will have a .git directory at the beginning of the directory, as well as .gitignore.

Differences in working mode:

Whether it is svn or git the workflow, are in the local conflict resolution and then submitted, rather than at the time of submission to resolve the conflict. and so:

svn mode is:
1. write the code.
3. Pull back the server’s current repository from the server and resolve the server repository conflict with the local code.
5. Submit the local code to the server.

The distributed version management model is:
1. write the code.
2. Submitted to the local repository.
3. Pull back the server’s current repository from the server and resolve the server repository conflict with the local code.
4. Merge the results of the remote library with the local code to the local repository.
5. Push the local repository to the server.

Therefore, the distributed version management is only to increase the concept of the local library, the rest of the concept and centralized management is no different. – but svn can not submit code before synchronizing with the server, so local modifications are more prone to problems.