Git及SVN入门
因为笔者入职公司需要使用SVN和Git,所以对这两个版本管理工具做一个对比和总结。
最后更新于
因为笔者入职公司需要使用SVN和Git,所以对这两个版本管理工具做一个对比和总结。
最后更新于
感谢广州诗悦网络科技有限公司,这是入职前的服务端岗前作业第二项内容。
这将会成为我接触SVN的第一步。
Git 是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。通俗来说,版本控制系统类似于一个代码云盘,在云端储存代码及修改记录,以便于备份、协作、回滚。
我们通过git init
命令初始化一个代码仓库,初始化后,会在该项目目录下出现一个名为 .git 的目录,所有 Git 需要的数据和资源都存放在这个目录中。
我们通过执行 git clone
命令拉取远程的Git代码仓库,在默认配置下,远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。
通过git add [file_name]
命令,我们可以将文件纳入Git版本管理,即将一个文件从Untracked状态转移到Staged状态,此时文件就被Git版本管理追踪了。
每次修改完已经处于被追踪状态的文件后,需要使用git add [file_name]
命令,将修改储存到暂存区。
通过git status
命令,我们可以获得详细的文件夹下文件的版本控制信息,例如,新添加的未跟踪文件前面有 ??
标记,新添加到暂存区中的文件前面有 A
标记,修改过的文件前面有 M
标记。
我们经常能在一些使用Git进行版本控制的代码仓库里发现 .gitignore
这样的文件,这是为了使Git忽略掉一些不必要的文件,通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等,这些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。通过使用正则表达式匹配,即可在.gitignore
里忽略掉这些文件。
通过git diff
命令,我们可以比较的工作目录中当前文件和暂存区域快照之间的差异。
通过git commit -m "message"
命令,我们可以将暂存区的快照提交到远端仓库中,并附注此次提交的版本信息"message"
。
我们会使用git rm [file_name]
命令去取消Git对一个文件的追踪,这样,在下一次提交时,该文件就不再纳入版本管理了。当然有时我们会在已经执行完git add
命令后,想要删除该文件在暂存区的快照,我们就需要git rm --cached [file_name]
这条指令。
有时候我们提交完了才发现漏掉了几个文件没有添加,或者提交信息写错了。 此时,可以运行带有 --amend
选项的提交命令来重新提交。具体的做法是这样的:
以及,我们可以通过git clone/git pull/git fetch
这三个命令获得远端仓库的最新代码,但是请留意他们之间的区别:git clone
操作更加注重于从无到有的过程,通过git clone
到本地的代码仓库文件夹自带.git文件夹;git pull
是从远端仓库更新代码到本地并自动合并到工作区目录的指令;git fetch
只会从远端仓库拉取指定的HEAD
,然后需要用户手动进行git merge
。可以理解为:git pull = git fetch + git merge
。
最后,我们已经git commit
的部分,可以通过git push
推送到远端仓库。
以上就是,我们在Git使用过程中,80%时间会用到的操作,剩下20%时间所会用到的命令可能会在关键时刻避免一场灾难,他们也很重要,强烈推荐有兴趣研究的读者参考这本书籍。
Apache Subversion 通常被缩写成 SVN,是一个开源的集中式版本控制系统。
svn checkout
操作是用来从中央版本库拉取并创建一个工作副本。工作副本是开发者私人的工作空间,可以进行内容的修改,然后提交到版本库中。
在工作区修改完我们需要编辑的代码文件后(如果我们新增了文件,svn add
命令将该文件加入版本控制),我们要通过命令svn status
进行提交前的检查,以确认本次提交的正确性。
若此时,我们本地修改了一些文件,但是突然又不需要了,想丢弃本地的修改回去SVN上最新的版本,我们需要使用svn revert
指令。
在完成正确性验证后,我们可以通过svn commit
命令提交我们所做的修改到中央仓库。
若此时,中央仓库的代码已经更新到了下一个版本,我们便无法提交我们的代码,此时,我们使用命令svn diff
查看已被修改的文件。
然后,通过svn update
更新我们的工作副本到最新的版本,并重新提交我们的修改。
不巧的是,此时,中央仓库的修改与我们本地的修改发生了冲突,此时,我们就需要手动merge
代码,然后重新发起一次提交。
对于SVN仓库的创建者及管理者来说,最好遵循官方的最佳实践。
Git 和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于 Git 对待数据的方式。
从概念上来说,其它大部分系统以文件变更列表的方式存储信息,这类系统将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 (它们通常称作 基于差异(delta-based) 的版本控制)。
Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中,每当你提交更新或保存项目状态时,它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。
通俗的来说,Git每次提交都是一个完整的工程项目,只不过未被修改的文件是以指针形式存在。
以及,Git的git commit
操作可以在本地进行,等到时机合适,再将其推送到远端服务器就可以,而SVN需要在可以连接到中央仓库时才能进行svn commit
操作。
更加详细的对比可以查看该页面。
SVN对中文支持好,操作简单,学习成本低,美工、产品、测试、运维、实施人员都可轻松上手。使用界面统一,功能完善,操作方便。
Git对程序源代码进行差异化的版本管理,代码库占极少的空间。易于代码的分支化管理。不支持中文,倾向于命令行方式使用,学习成本高,不利于推广。
本作品采用知识共享署名 4.0 国际许可协议(CC BY-NC-SA 4.0)进行许可,转载时请注明原文链接,图片在使用时请保留全部内容,可适当缩放并在引用处附上图片所在的文章链接。