Nothing Special   »   [go: up one dir, main page]

The Difference Between GIT and SVN

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

The difference between GIT and SVN

BY DO SON · SEPTEMBER 11, 2017

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.

You might also like