An article to understand the difference between Git and SVN [Principle]

Preface

Git and SVN are both version management systems, but they
The command difference will be a simple comparison later, let’s analyze it from the perspective of principle first.

4.git and svn commands

Let's review the Ha command first

effect	git	svn
Repository initialization	git init	svn create
clone	git clone	svn co（checkout）
add	git add (remove .gitignore, *all files)	svn add
commit	git commit	svn commit
pull	git pull	svn update
push	git push	-
Check working status	git status	svn status
Create branch	git branch <branch name>	svn cp <branch name>
Delete branch	git branch -d <branch name>	svn rm <branch name>
Branch merge	git merge <branch name>	svn merge <branch name>
Work area differences	git differ （-cached / head）	svn diff
Update to historical version	git checkout <commit>	svn update -r <rev>
Switch tag	git checkout <tag>	svn switch <tag>
Switch branch	git checkout branch	svn switch branch
Restore files	git checkout - path	svn revert path
Delete Files	git rm path	svn rm path
Move files	git mv path	git mv path
Clear untracked files	git clean	svn status sed -e

1. Storage difference

Think about why we generally use git for code management, and SVN for prototype diagrams and high-fidelity management.

1. Git is distributed, with two local and remote version repositories, SVN is centralized, and there is only one remote version repository;
2. The content of git is stored as metadata, all control files are in .git, svn is processed as files, and all resource control files are in .svn;
3. The branch of svn is a directory, but git is not;
4. Git does not have a global version number, svn has;
5. Git content storage uses SHA-1 hash algorithm to ensure code integrity;
6. Git has a work area, a temporary storage area, and a remote warehouse. git add submits the code to the temporary storage area, commit is submitted to the local repository, and push is pushed to the remote repository. Svn is add to the temporary storage, commit is to submit to the remote repository.

So it can be clearly seen that because the prototype and high-fidelity are based on a single file, it is suitable for SVN management, and our code is based on the number of lines, suitable for Git

2. The difference between file .svn and .git

1..svn directory

Just open a .svn directory to see the structure:
If you cannot view .svn, windows computer-click to view-tick hidden files;
Mac directly shift + command +.

├── pristine 各个版本纪录，这个文件一般较大
├── tmp 
├── entries 当前版本号
├── format 文本文件， 放了一个整数，当前版本号
├── wc.db 二进制文件
├── wc.db-journal 二进制文件

2..git directory structure

You may be very unfamiliar with these directory structures, it doesn’t matter, just type git help gitrepository-layout in the terminal and press Enter, you will find that the browser will open an html file, in fact, it will open an html document under the installation of git

├── hooks 钩子文件
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── fsmonitor-watchman.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample commit时会触发这个钩子
│   ├── pre-push.sample push触发
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   ├── update.sample update触发
├── info
│   ├── exclude 忽略的文件
├── object git数据对象，包括commit，trees，二进制对象，标签等
├── COMMIT_EDITMSG 上一次提交的注释信息
├── log 各个refs的历史信息
├── refs 每个分支指向那个提交
├── config 本项目配置信息，包括仓库地址，分支，用户账号等
├── description 项目描述
├── HEAD 当前分支的最后一次提交
├── index 索引文件，存贮git add把要添加的项
├── packed-refs 分支标识文件

So it can be seen that git is more powerful than svn in processing code

3..git file dynamic analysis

3.1 add stage

1. Executing git init will generate an initialized .git, and you will find that some of the above directory files are not, because some files will be generated after the specified command

2. Create a new test.txt, write something casually, and execute git status

On branch master  // 默认一个master 分支

No commits yet

Untracked files: // 未提交的文件
  (use "git add <file>..." to include in what will be committed)

    test.txt

nothing added to commit but untracked files present (use "git add" to track)

Run find .-type f

./config
./HEAD
./info/exclude
./description
./hooks/commit-msg.sample
./hooks/pre-rebase.sample
./hooks/pre-commit.sample
./hooks/applypatch-msg.sample
./hooks/fsmonitor-watchman.sample
./hooks/pre-receive.sample
./hooks/prepare-commit-msg.sample
./hooks/post-update.sample
./hooks/pre-applypatch.sample
./hooks/pre-push.sample
./hooks/update.sample
./index

3. Execute git add text.txt, display

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   test.txt

Run find .-type f

./config
./objects/61/de0edff4ebeeff225da34006cbe6427638fadc  # 比之前多了一个文件
./HEAD
./info/exclude
./description
./hooks/commit-msg.sample
./hooks/pre-rebase.sample
./hooks/pre-commit.sample
./hooks/applypatch-msg.sample
./hooks/fsmonitor-watchman.sample
./hooks/pre-receive.sample
./hooks/prepare-commit-msg.sample
./hooks/post-update.sample
./hooks/pre-applypatch.sample
./hooks/pre-push.sample
./hooks/update.sample
./index

4. Summary: It can be seen that test.txt is marked as staged after git add, and the object has an additional 61/de0edff file, so the object can store the contents of the git warehouse in a binary format.

5. We can check the source of the file

git cat-file -p 61de0edf
打印 test

6.How git manages and archives files
Our common file systems (NTFS, FAT, FAT32) retrieve files based on the address method, that is, first give a specific address, and then read the file content from the storage unit corresponding to the address number, while git is based on content retrieval, which is the entire content Retrieve, get a real storage location, similar to a hash map.

3.2 commit phase

1. Execute git commit -m'add test'

1 file changed, 1 insertion(+)
create mode 100644 test.txt

2. Run find .-type f

./test.txt
./.git/config
./.git/objects/61/de0edff4ebeeff225da34006cbe6427638fadc
./.git/objects/ed/fd7e903f8f622f9a52542adfa077552608202d
./.git/objects/26/ef8e81bc27b4a67f251145a4f83782364fa9fa
./.git/HEAD
./.git/info/exclude
./.git/logs/HEAD
./.git/logs/refs/heads/master
./.git/description
./.git/hooks/commit-msg.sample
./.git/hooks/pre-rebase.sample
./.git/hooks/pre-commit.sample
./.git/hooks/applypatch-msg.sample
./.git/hooks/fsmonitor-watchman.sample
./.git/hooks/pre-receive.sample
./.git/hooks/prepare-commit-msg.sample
./.git/hooks/post-update.sample
./.git/hooks/pre-applypatch.sample
./.git/hooks/pre-push.sample
./.git/hooks/update.sample
./.git/refs/heads/master
./.git/index
./.git/COMMIT_EDITMSG

It can be seen that after commit, object has two more files ed/fd7e90 and 26/ef8e8 on the basis of add. From the archive path and naming of the files, it can be seen that git uses the SHA-1 algorithm to verify the contents of the files.

There is also a COMMIT_EDITMSG, which is the comment information submitted last time

3. Use git cat-file to view the source

git cat-file -t edfd7e90
// 终端输出tree

git cat-file -t 26ef8e8
// 终端输出commit

git cat-file -p edfd7e90
// 终端输出 100644 blob 61de0edff4ebeeff225da34006cbe6427638fadc    test.txt

git cat-file -p 26ef8e8
// 终端输出 tree edfd7e903f8f622f9a52542adfa077552608202d
author 信息  1612668900 +0800
committer author 信息  1612668900 +0800

ed/fd7e90 is a commit object, the tree attribute points to 26/ef8e8, which records the file operation, author, and submitter information;
26/ef8e8 is a tree object, and the blob attribute points to the blob object 61/de0edf, which records the file name;
61/de0edf is a blob object that records the contents of the file.

Three file relationships:

So now you know why the object file is so big

3.3 branch

git branch to get a list of branches
The list is saved under refs/heads/master

3.4 git object model

Through the analysis of 3.2 above, we know that there are four types of objectionable objects in the git system:
1. Commit: point to a tree, which records the file operation, author, and submitter information;
2.tree: object relationship tree, manage the relationship between tree and blob;
3. blob: save the content of the file;
4.tag: tag submission.

3.5 git lifecycle hook

1. Hook initialization:
The hooks mentioned above are all life cycle scripts. Initializing the warehouse (git init) or git clone will initialize the .git file;

2. The hook is local, because it will not be submitted to the code repository, but it will be initialized when cloned;

3. Hook classification:

Hook name	effect
pre-commit	It will be triggered before every git commit. A very common application is to do code eslint verification in package.json with husky and lint-staged.
prepare-commit-msg	In pre-commit, the submission information generated in the text editor is called, and it is convenient to modify the automatically generated squash and merge submission
commit-msg	The user input submission information is called, which is the submission information after commit -m, which can be used to standardize the submission information
post-commit	Execute after commit-msg and notify the result of git commit
post-checkout	git checkout is called
pre-rebase	git rebase run before changing
pre-receive	Execute after git push, exist in the remote warehouse, server-side remote hook
update	call after pre-receive
post-receive	push is called after the push is successful, to notify the push user

Conclusion

Seeing that many confusions about git and svn are solved here, original codewords are not easy, welcome star!