前言

Git和SVN都是版本管理系统,然而他们
命令区别前面会简略进行一个比照,咱们先从原理的角度剖析

4.git和svn命令

先来温习哈命令

作用gitsvn
版本库初始化git initsvn create
clonegit clonesvn co(checkout)
addgit add (.除去.gitignore,*所有的文件)svn add
commitgit commitsvn commit
pullgit pullsvn update
pushgit push-
查看工作状态git statussvn status
创立分支git branch <分支名>svn cp <分支名>
删除分支git branch -d <分支名>svn rm <分支名>
分支合并git merge <分支名>svn merge <分支名>
工作区差别git differ (-cached / head)svn diff
更新至历史版本git checkout <commit>svn update -r <rev>
切换taggit checkout <tag>svn switch <tag>
切换分支git checkout branchsvn switch branch
还原文件git checkout - pathsvn revert path
删除文件git rm pathsvn rm path
挪动文件git mv pathgit mv path
革除未追踪文件git cleansvn status sed -e

1.存贮区别

大家想想为什么咱们代码治理为什么个别用git,原型图和高保真治理个别用SVN?

1.git是分布式的,有本地和近程两个版本库,SVN是集中式,只有一个近程版本库;
2.git的内容是按元数据形式存贮,所有管制文件在.git中,svn是按文件解决,所有资源管制文件在.svn中;
3.svn的分支是一个目录,git不是;
4.git没有一个全局的版本号,svn有;
5.git内容存贮是应用SHA-1哈希算法,能确保代码完整性;
6.git 有工作区,暂存区,近程仓库,git add将代码提交到暂存区, commit提交到本地版本库,push推送到近程版本库。svn是add 提交到暂存,commit是提交到近程版本库。

所以能够很分明的看出因为原型图和高保真都是以单个文件为单位,所以适宜用SVN治理,而咱们代码时以行数为单位,适宜Git

2.文件.svn和.git区别

1..svn目录

轻易关上一个.svn的目录能够看到构造:
如果无奈查看.svn,window电脑-点击查看-勾选暗藏文件;
mac间接shift + command + .

├── pristine 各个版本纪录,这个文件个别较大├── tmp ├── entries 以后版本号├── format 文本文件, 放了一个整数,以后版本号├── wc.db 二进制文件├── wc.db-journal 二进制文件

2..git 目录构造

你可能对这些目录构造很生疏,没关系,间接在终端输出 git help gitrepository-layout回车,你会发现浏览器会关上一个html文件,实际上就会关上装置git上面的一个html文档

├── 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 分支标识文件

所以能够看出git在解决代码方面性能比svn要弱小一些

3..git文件动态分析

3.1 add阶段

1.执行git init会生成一个初始化的.git,会发现下面有些目录文件没有,因为有些文件是指定的命令后才会生成

2.新建一个test.txt,轻易写点内容,执行git status

On branch master  // 默认一个master 分支No commits yetUntracked files: // 未提交的文件  (use "git add <file>..." to include in what will be committed)    test.txtnothing added to commit but untracked files present (use "git add" to track)

运行 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.执行 git add text.txt,显示

On branch masterNo commits yetChanges to be committed:  (use "git rm --cached <file>..." to unstage)    new file:   test.txt

运行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.总结:能够看出git add后test.txt 被标记为staged 状态,而且object多了一个61/de0edff 文件,所以object 能够存贮git仓库内容,以二进制形式存贮。

5.咱们能够查看下文件起源

git cat-file -p 61de0edf打印 test

6.git如何治理和归档文件
咱们常见的文件系统(NTFS、FAT、FAT32)是基于地址形式检索文件,即先给具体的地址,而后从地址编号对应的存储单元读取文件内容,而git是基于内容检索,是对整个内容检索,失去一个实在的存储地位,相似哈希映射。

3.2 commit阶段

1.执行 git commit -m 'add test'

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

2.运行 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

能够看出commit 后在add 的根底上object多了两个文件ed/fd7e90和26/ef8e8,从文件的归档门路和命名能够看出git应用SHA-1算法对文件内容进行了校验

还多了一个COMMIT_EDITMSG ,外面是上一次提交的正文信息

3.应用git cat-file 查看起源

git cat-file -t edfd7e90// 终端输入treegit cat-file -t 26ef8e8// 终端输入commitgit cat-file -p edfd7e90// 终端输入 100644 blob 61de0edff4ebeeff225da34006cbe6427638fadc    test.txtgit cat-file -p 26ef8e8// 终端输入 tree edfd7e903f8f622f9a52542adfa077552608202dauthor 信息  1612668900 +0800committer author 信息  1612668900 +0800

ed/fd7e90 是一个commit 对象,tree属性指向了26/ef8e8,纪录了文件操作,作者,提交者信息;
26/ef8e8 是一个tree 对象,blob 属性指向了blob对象61/de0edf,纪录了文件名;
61/de0edf 是一个blob 对象,纪录了文件内容。

三个文件关系:

所以当初晓得为什么object文件会很大的吧

3.3 branch

git branch 获取分支列表
列表保留到refs/heads/master 上面

3.4 git对象模型

通过下面3.2的剖析晓得,在git零碎中有四种尅性的对象:
1.commit:指向一个tree,纪录了文件操作,作者,提交者信息;
2.tree:对象关系树,治理tree和blob的关系;
3.blob:保留文件内容;
4.tag:标记提交。

3.5 git生命周期钩子

1.钩子初始化:
下面说到的hooks 上面都是生命周期脚本,初始化仓库(git init)或 git clone 都会初始化.git文件;

2.钩子是本地的,因为不会提交到代码仓库,只不过clone的时候会初始化;

3.钩子分类:

钩子名作用
pre-commit每次git commit之前会触发,很常见的利用就是在package.json联合husky和lint-staged做代码eslint校验
prepare-commit-msg在pre-commit在文本编辑器生成提交信息被调用,不便的批改主动生成的squash和merage提交
commit-msg用户输出提交信息被调用,就是commit -m 前面那个提交信息,能够用来标准提交信息
post-commitcommit-msg后执行,告诉git commit的后果
post-checkoutgit checkout被调用
pre-rebasegit rebase 更改之前运行
pre-receivegit push后执行,存在于近程仓库中,服务端近程钩子
updatepre-receive 后调用
post-receivepush 推送胜利后被调用,告诉push的用户

结语

看到这里git和svn很多蛊惑都解开了吧, 原创码字不易,欢送star!