The difference between git and SVN and the basic operating comparison

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,CVS. If you can understand this concept, then you are already half-done. There is a need to make a statement that Git is not the first or only distributed version control system. Other systems, such as BitKeeper, mercurial, and so on, are also running in distributed mode. But Git does better in this and has more powerful features.

GIT has its own centralized repository or server like SVN. However, Git prefers to be used in distributed mode, where each developer Chect out code from the central repository/server and clones a repository on its own machine. It can be said that if you are trapped in a place where you can't connect to a network, you can still submit files, view historical version records, create project branches, and so on.

2) Git stores content in metadata, and SVN is by file:

All resource control systems hide the meta-information of files in a folder similar to. Svn,.cvs. If you compare the size of the. git directory with the. SVN, you will find that they are very different. Because the. Git directory is a cloned version of the repository on your machine that has everything on the central repository, such as tags, branches, release notes, and so on.

3) The GIT branch differs from the SVN branch:

The branch is not special in SVN, it is another directory in the repository. If you want to know if a branch has been merged, you need to manually run a command like this, SVN propget svn:mergeinfo, to verify that the code is merged.

However, the branch that handles git is quite simple and interesting. You can quickly switch between several branches from the same working directory. You can easily find the branches that have not been merged, and you will be able to merge these files easily and quickly.

4) Git does not have a global version number, and SVN has:

So far this is the biggest feature that git lacks in comparison with SVN.

5) Git has better content integrity than SVN:

Git's content store uses the SHA-1 hashing algorithm. This ensures the integrity of the content of the code and ensures that the repository is compromised when disk failure and network problems are encountered.

2, SVN and git basic operation comparison

1) Warehouse Creation initialization

In SVN, the warehouse itself is managed and used in everyday applications, using two different sets of commands. The commands used in the creation and backup maintenance of warehouses are svnadmin, and a new warehouse is created using svnadmin create

In Git, create a new repository that can be implemented in an empty directory using GIT init, which will create a. git directory to maintain the warehouse data.

In SVN, where you create warehouses is not where you use your daily warehouses, you need to checkout out specific warehouse paths elsewhere as a directory for your daily work. In Git, the directory where the repository resides is your daily work directory, with no server and client points. (Strictly speaking, the Git directory is the repository, the. Git directory is your working directory, for Bare project, only the contents of the Git directory, the contents of the working directory will be checkout out)

2) Checkout Warehouse

In SVN, use SVN Checkout (CO) to checkout local or remote repository code

For git, although there are checkout commands, because you need to have a warehouse locally, the first step in checkout code from the server is to use Git clone to get a copy of the repository, the default git The clone operation also checkout a copy of the current active branch on the remote repository

In SVN, the way the repository is managed determines that you can checkout only subdirectories in a specific path/branch in the repository, not the entire repository, and git can only checkout the entire branch.

3) incorporating files into version management

In SVN, svn add is used so that after each commit, SVN will automatically build a commit tree based on the modification of these add objects.

In Git, because of the concept of index, in order to put a file into the scope of version management, the first is to use Git-update-index–-add to put the file into the monitoring scope of index, only the content updated to index will be submitted at the time of commit. In addition, changes to the file itself are not automatically updated to index, and any changes must be re-updated to index in order to be submitted. Of course, a package script such as git add is usually used to invoke Git-update-index

4) Check the current status

SVN status can show the current file modification status of working tree

The git status command in git displays the status of the current index and the state of the working tree.

5) Submission of documents

The git commit operation is relatively straightforward in git commands, and one thing to note is that only the content in index is more than committed.

6) Delete Files

When using SVN rm to delete a directory, Because the. svn directory exists in each directory, the information on the server-side repository is recorded, so the other files in the directory are deleted before the commit, but the directory and its subdirectories are not actually deleted, and the directory is deleted only after the commit.

In Git, again, use git rm to delete files. But Git's handling of directories is a bit odd, and if all the files in a directory are deleted, the directory is automatically deleted, meaning you can't keep an empty directory. You also cannot add an empty directory to the repository. That is, Git automatically ignores empty directories and doesn't know what to do with it.

7) View Log

The SVN log command is basically used to view the log information that was written when the version was submitted

Git log can do a lot more things, after all, git log is a re-packaging of the underlying core command, through which you can not only view the log information, but also output a specific version of the specific change content and so on information.

8) Version Backtracking

In SVN, there is no mechanism to remove objects from the repository, and any modification will result in the increment of the version, so if you want to discard a change, you need to reverse-diff your changes and commit a new version.

The mechanism for resetting the index of the committed tree object is provided in Git, so you can restore the current branch version to a previous state, for example, by using an operation such as Git-reset. A common example is to backtrack a version and then modify the content to commit again. But it's not easy to do that. This includes operations such as Git-push, which are reject and require forced push.

If you just want to give up a change, Git's document is recommended to use the Git-revert operation, this operation is basically the same as the idea of SVN, is to submit a new version will need to revert version of the content of the reverse modification back, the version will be incremented, does not affect the content of the previous submission.

9) Discard Current changes

In SVN, using SVN revert for directory or file operations can restore changes to a specific path on the current working tree to a version on the server, discarding the current modification.

In Git, a git checkout command that uses no other parameters for a particular file can restore the file to the state in index and, if you want to restore a specific version, like this: Git checkout head file to restore the file to head The tree is the state of the most recent commit.

But git checkout has a problem, do not know whether intentionally this design, is even with git rm deleted content, if not committed, git checkout will recover later, including its status in index. This is somewhat incomprehensible. The delete operation has been recorded in theory on index and should not be restored.

Git also has a way to quickly and completely abandon all changes since the last commit, Git reset–hard HEAD

10) Code Merge

Git merge automatically remembers the location and state of the previous merge, which is easier to understand because the head commit of each branch can track its object index relationships. In addition, because of the reason for its object management mechanism, all modifications to the entire branch can only be made in commit. You cannot have a selection of changes under the merge section path. The merge requires the index and head to be consistent, and if the merge succeeds, the content will be directly commit, and the changes in the work tree will remain. (If it fails, it will merge the contents of the merge with the ones you already have in the work tree, probably not what you want, so it's better not to do so)

All modifications prior to a specific version of a specific branch of the merge can be achieved by the corresponding Rev of the merge version, and the modification of the merge section, considering that the commit requires a complete code tree relationship, it is not possible to do so by using git merge, which requires a diff/ Patch code to implement

The SVN merge operation does not remember its merge history, in other words, you can merge the same code multiple times, but the advantage is that you are free to choose which part of the merge, which version of the code, should say he is basically equivalent to the combination of diff and patch. However, because SVN does not have the concept of index, the merge operation is merged with the changes on the current working tree.

As for the historical information aspect, because the SVN merge is actually the patch file content itself, so, the historical information on different branches will not be reflected in the trunk after the merge, and Git's merge, if there is no conflict, is actually the merge commit tree inheritance relationship, so , all historical information can be indexed in a commit after the merge.

11) Get the simple code

In SVN, if you do not need any historical information, just want a version of the pure code (often have this requirement, so that the local data is relatively small), then use the SVN Export command can be implemented.

In Git, there seems to be no such command, however, because Git's local repository information is fully maintained in the. Git directory of the project root, (unlike SVN, there is a separate. SVN directory under each subdirectory). So, just clone,checkout and then delete the. git directory.

The difference between git and SVN and the basic operating comparison