本篇文章给大家谈谈一篇文章了解Git和SVN的区别，以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

git和svn命令

我们先回顾一下Ha命令

影响

git

SVN

存储库初始化

git初始化

创建svn

克隆

克隆

svn co（结账）

添加

git add (.remove .gitignore, *所有文件)

svn添加

犯罪

git 提交

svn提交

拉

git拉

svn更新

推

git 推送

–

检查工作状态

git 状态

svn状态

创建分支

git分支分支名称

svn cp 分支名称

删除分支

gitbranch -d 分支名称

svn rm 分支名称

分支合并

git合并分支名称

svn 合并分支名称

工作空间差异

git 不同(-cached/head)

svn 差异

更新历史版本

git checkout 提交

svn更新-r版本

开关标签

git 结账标签

svn 切换标签

切换分支

git checkout 分支

svn切换分支

恢复文件

git 结帐路径

svn 恢复路径

删除文件

gitrm路径

svn rm 路径

移动文件

git mv 路径

git mv 路径

清除未跟踪的文件

清理干净

svn 状态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目录

您可能不熟悉这些目录结构。没关系。只需在终端中输入git help gitrepository-layout 并按Enter 键即可。你会发现浏览器会打开一个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 推送触发器 pre-rebase.sample pre-receive.sample prepare -commit-msg.sample update.sample 更新触发器 info 排除忽略的文件 object git 数据对象，包括提交、树、二进制对象、标签等 COMMIT_EDITMSG 一次commit的注释信息记录每个refs的历史信息refs每个分支指向哪个提交本项目的config配置信息，包括仓库地址、分支、用户账号等描述项目描述 HEAD 当前分支的最后一次提交index索引文件，存放git add要添加的项目packed-refs分支标识文件所以可见git比svn 中处理代码

3..git文件动态分析

3.1 add阶段

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

2、新建test.txt，写入一些内容，执行git status

在分支master //默认是主分支还没有提交Untracked files: //未提交的文件（使用’git add file.’ 包含在将提交的内容中） test.txt 没有添加任何内容到提交，但存在未跟踪的文件（使用’ git添加’到跟踪）运行find 。 -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./index3。执行git add text.txt 并显示

在分支master 上尚未提交更改要提交的： （使用’git rm –cached file.’ 取消暂存）新file: test.txt 运行find 。 -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 。样本./hooks/pre-applypatch.sample./hooks/pre-push.sample./hooks/update.sample./index4。总结：可以看到test.txt在git add之后被标记为staged，并且object多了一个61/de0edff文件，所以object可以以二进制的方式存储git仓库的内容。

3.2 commit阶段

1.执行git commit -m ‘add test’

1 个文件已更改，1 个插入(+)创建模式100644 test.txt2。运行查找. -f型

./test.txt./.git/config./.git/objects/61/de0edff4ebeeff225da34006cbe6427638fadc./.git/objects/ed/fd7e903f8f622f9a52542adfa077552608202d./.git/objects/26/ef8e81bc27b4 a67f2 51145a4f83782364fa9fa./.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后，多了两个基于添加。文件ed/fd7e90 和26/ef8e8。从归档路径和文件的命名可以看出，git使用SHA-1算法来验证文件内容。

还有一个额外的COMMIT_EDITMSG，里面包含了上次提交的评论信息。

三个文件关系：

现在您知道为什么目标文件非常大了吧？

3.3 branch

gitbranch获取分支列表并保存在refs/heads/master下

3.4 git对象模型

3.5 git生命周期钩子

1.钩子初始化：上面提到的钩子都是生命周期脚本。初始化仓库（git init）或git clone会初始化.git文件；

2、hook是本地的，因为它不会提交到代码仓库，但在clone的时候会被初始化；

3.挂钩分类：

钩子名称

影响

预提交

它会在每次git 提交之前触发。一个很常见的应用是结合husky 和lint-staged 在package.json 中进行代码eslint 验证。

准备-提交-消息

在pre-commit中，调用文本编辑器生成提交信息，可以方便地修改自动生成的squash和merge提交。

提交消息

用户输入调用的提交信息，即commit -m之后的提交信息，可以用来规范提交信息。

提交后

commit-msg后执行，通知git提交结果

结帐后

git checkout 被调用

预变基

在进行更改之前运行git rebase

预接收

git push后执行，存在于远程仓库，服务器端远程hook

更新

预接收后调用

接收后

推送成功后调用push，通知推送用户

用户评论

温柔腔

终于找到解释Git 和 SVN区别的文章了！我之前一直弄不明白这两个版本控制系统到底哪里不同，总是混淆概念。这篇文章讲得真清楚简单，终于明白这些不同的点要怎么使用才能更有效率地管理代码啦！

    有6位网友表示赞同！

〆mè村姑

写得好！以前也觉得SVN和Git不太理解，这次读完，感觉两者的区别还是很明显的。Git 真是太强大，分布式版本控制，可以离线工作还能随时分享修改，SVN 的集中式模式确实有些局限性。

    有7位网友表示赞同！

淡抹丶悲伤

赞同作者的观点！对于初学者来说，Git 的学习曲线的确会 steeper 一点，但是掌握了以后效率提高是相当可观的。个人觉得选择 Git 更适合现在的开发环境，毕竟分布式协作越来越常见了。 <br>

    有10位网友表示赞同！

微信名字

这篇博文虽然解释得很详细，但我觉得还是缺少一些实战案例的说明，比如用实际项目来展示Git和SVN的区别，也许更能帮助读者理解。

    有19位网友表示赞同！

命里缺他

这篇文章真的对我很有用！之前一直在用 SVN ，突然想尝试 Git 试试，结果就一头雾水，幸好找到了这篇博文指明方向啦！

    有13位网友表示赞同！

不离我

作者说得重点太少了，我只想知道 Git 和 SVN 的具体应用场景是什么？哪种版本控制系统更适合大型项目开发？这篇文章里没有提到啊。

    有16位网友表示赞同！

迁心

虽然 Git 更灵活强大，但它也确实比较复杂。SVN 对于一些小型项目或熟悉的人来说也许还是不错的选择，毕竟它的操作简便易上手

    有16位网友表示赞同！

安之若素

我同意 Git 更适应现代软件开发流程，分布式管理太方便了，每次提交修改都可以保存到自己的仓库。但是我还是觉得 SVN 更稳定可靠，不太容易出现问题，对于一些关键的项目来说可能更安心。

    有6位网友表示赞同！

有你，很幸福

说Git 是强项还是弱项取决于项目的规模和团队合作方式吧！大型项目、多人协作 Git 就更有优势了；如果是小型项目，SVN 能满足需求也更容易上手。 这次博文的分析很有帮助

    有14位网友表示赞同！

空谷幽兰

这篇博文写的挺好，但没考虑到一些新兴的版本控制工具，像 Github, Bitbucket 等等，这些平台都基于Git，对开发者来说也许更方便。

    有11位网友表示赞同！

棃海

我建议作者可以加一段关于如何选择 Git 和 SVN 的技巧，因为每个项目都有不同的需求，选择合适的版本控制系统才能提高工作效率。

    有15位网友表示赞同！

醉枫染墨

我一直在学习 Git ，这篇文章给我不少启发啊！原来 Git 比 SVN 更适合大型项目和分布式开发，之前我一直以为这两个系统差不多…

    有7位网友表示赞同！

轨迹！

这篇博文确实很有帮助! 我一直使用 Git, 但偶尔会遇到一些奇怪的问题，读完这篇文章后对 Git 的原理有更深入的理解了。

    有8位网友表示赞同！

败类

作者应该多提供一些实践案例，这样更容易理解 Git 和 SVN之间的区别！例如，用一个简单的例子来说明如何用Git 分支管理代码等…

    有5位网友表示赞同！

不要冷战i

其实我觉得很多时候选择版本控制系统并不那么重要。 最重要的是掌握正确的开发习惯和流程，无论使用哪个工具都能保证代码的稳定和安全可靠！

    有10位网友表示赞同！

暮光薄凉

同意作者的说法，Git 和 SVN 各有优缺点。 Git 适合分布式合作、灵活管理代码，而 SVN 更适合一些小团队或简单项目。

    有16位网友表示赞同！