Differences between git and SVN

1) git is distributed, and SVN is not:

This is the core difference between git and other non-distributed version control systems, such as SVN and CVS. The advantage is that there won't be too many conflicts with other colleagues. The code you write is stored on your computer and submitted and merged after a period of time. You can also submit the code locally without going online; if you can understand this concept, you will be half done. You need to make a statement that git is not currently the first or only distributed version control system. Some other systems, such as bitkeeper and mercurial, also run in distributed mode. But git is doing better in this regard and has more powerful features.

Git and SVN have their own centralized version libraries or servers. However, git is more inclined to be used in the distributed mode, that is, each developer will clone a version library on their own machine after chect out code on the central version Library/server. In this case, if you are stuck in a location that cannot connect to the network, you can still submit files, view historical version records, and create project branches.

2) git stores the content in metadata mode, while SVN stores the content by file:

All resource control systems hide the object metadata in a folder such as. SVN and. CVs. If you compare the size of the. Git directory with that of. SVN, you will find that they are quite different. Because, the. Git directory is a clone version library on your machine that owns everything on the central version library, such as tags, branches, and version records.

3) git branch and SVN branch are different:

The Branch is not special in SVN, that is, another directory in the version library. If you want to know whether a branch is merged, You need to manually run the command SVN propget SVN: mergeinfo like this to check whether the code is merged.

However, it is quite simple and interesting to process git branches. You can quickly switch between several branches in the same working directory. You can easily find unmerged branches. You can easily and quickly merge these files.

Git encourages branch, while SVN, to be honest, I have used branch a few times. I have never used Branch merge that comes with SVN, when there is merge, the beyond compare tool is used for merging and then commit;

4) git does not have a global version number, but SVN has:

So far, this is the biggest feature missing from git compared with SVN.

5) The content integrity of git is better than that of SVN:

Git uses the SHA-1 hash algorithm for content storage. This ensures the integrity of the Code content and reduces the damage to the version library in case of disk or network problems.

6) After git is downloaded, you can see all the logs locally without having to connect to the Internet. It is easy to learn, but SVN needs to be connected to the Internet;

7) before committing SVN, we recommend that you update the code first, compile the code locally, and ensure that the developed functions are normal before submission. This is actually quite troublesome, several times my colleagues did not updata first, so they committed it. Some errors have occurred, delaying everyone's time. Git may be less prone to this situation.

Other differences:

1. Speed:

Kelon has a brand new directory. In terms of having five (only five) branches, SVN retries five versions of files at the same time, that is, it repeats the same action five times. Git only obtains the elements of each version of the file, and then only loads the main branch (master ). In my experience, it took nearly an hour to clone a SVN with nearly 10 thousand commits and five branches, each of which has about 1500 files! Git only uses the 1-minute partition!

2. Version Library (repository ):

As far as I know, SVN can only have one specified central version library. When there is a problem with this central version library, all the work members are paralyzed until the version library is repaired or the new version library is set up.

Git can have unlimited version libraries. Or, more correctly, each git is a version library, and the difference is whether they have an active directory (GIT working tree ). If something happens to the main version Library (for example, the GitHub version Library), the working member can still submit it in his local version Library (local repository, wait until the master version library is restored. You can also submit a job member to another version library!

3. Branch)

In SVN, the Branch is a complete directory. The directory contains the complete actual files. If a job member wants to open a new branch, it will affect the "world "! Everyone has the same branch as you. If your branch is used for damage (Security Testing), it will be like an infectious disease.

In git, each worker can open an unlimited branch in the local repository. For example, if I want to destroy my program (Security Testing) and keep these modified files for future use, I can open a branch to do what I like. There is no need to worry about interfering with other members. As long as I do not merge and submit it to the main version library, no working member will be affected. When I don't need this branch, I just need to delete it from my local version library. No itching.

Git branch names can be different. For example, my local branch name is testing, and the name of the main version library is actually master.

Most importantly, I can open a commit branch at any commit point in git! (One method is to use gitk-all to observe the entire commit record, and then open the commit branch at any point .)

4. Submit)

In SVN, when you submit your finished product, it will be recorded directly to the central version library. When you find that your finished product has a serious problem, you cannot stop it from happening. If the network is interrupted, you cannot submit it!

The commit of git is entirely related to the local version library. You only need to "push" (GIT push) to the main version library. Git's "push" is actually executing "sync ).

5. Rebase)

I have not tried it in SVN. I don't know if it has such a function.

In git, if you want to set up others' latest commits as the starting point of the current branch, you only need to execute git rebase branch_name. The difference between this and merge is that merge will regard the modification time as the latest, and rebase will ask you to solve the conflict between both parties ).

A-B-e

\-C-d

A-B-e

\-C-d

6. System Files

SVN will place a. Svn in each directory. It is very tiring to remove these. SVN files.

Git will have a. Git directory and. gitignore at the beginning of the directory.

It is easy for me to manage a git version library.

 

In the following article, the author thinks SVN is useless. I agree with ghoststears.

With git, SVN is purely spam.

Ghoststears:

Everything is ultimately a human problem. Tools are just tools.

SVN is centralized, and the coupling you mentioned will appear. But in another aspect, this also requires the coding standards of developers: Do not use a function to do many things, or write many classes into a single file.

In addition, it is meaningless to submit non-Running code to any version control system. This is one of the core concepts of version control. That is, the granularity of submission: atomicity. The so-called atomicity refers to the completion of a task. This task can be a function declaration, a function implementation, or a sub-system. However, the mark of the completion of this task is that the code can be run and cannot be run. A maximum of half of the tasks are completed. This is not in line with version control ideas. When you update a version, the Code cannot run. What is your mood ???

Submitting codes that cannot be run is a matter of developers' quality or company management processes and mechanisms.

In addition, many people stressed that I have to work at home after work in the evening. I cannot submit a ticket !!! To attack centralized version control tools. Not to mention the attitude towards work and life. First, let's look at domestic enterprises to prevent many employees, such as thieves. How many people can bring their laptops and sign out the company's source code ???

In a version control system, tools are only one part. Appropriate tools should be selected based on the company's policies. Version Control! = Version control tool !!! = Source code management.

Finally, people have their own preferences. The launch of the above outline is completely unnecessary.

Refer:

Http://blog.csdn.net/a117653909/article/details/8952183

Http://wuzhangshu927.blog.163.com/blog/static/1142246872011621113641834/

Http://www.cnblogs.com/qinfengxiaoyue/p/3450194.html