版本控制系统(Version Control System - VCS)
版本控制系统(VCS)最基本的功能是版本管理。所谓版本控制,意思就是在文件的修改历程中保留修改历史,让你可以方便地撤销之前对文件的修改操作。
①:基本功能(版本管理)
当我们在编辑文件的时候误改或者误删的时候,我们会通过ctrl+z来撤销自己的操作,回到前一步甚至前几十步的操作,版本控制也有这样一个功能,它可以使你的文件,目录,项目很容易回到前几个版本,但是这里说的git不会自动帮你记录你的每一次修改操作,它只会记录你主动提交
到版本仓库的文件或者项目。
②:中央仓库(多人合作开发)
版本控制系统可以帮你记录任何一个项目的版本,但是在实际开发中,一个项目往往由许多人一起共同开发,所以版本控制系统就提供了一个中心仓库来存储所有人共同开发的代码,所有人改动后上传的代码都会被中心仓库记录,我们可以很方便的查看每个人的更改记录,也可以很方便的回退到以前的任何一个版本。
所以根据上面所说的
版本控制
、主动提交
、中央仓库
这三个要素,共同构成了版本控制系统(VCS)的核心:开发团队中的每个人向中央仓库主动提交自己的改动和同步别人的改动,并在需要的时候查看和操作历史版本,这就是版本控制系统。
集中式版本控制(CVCS)和分布式版本控制(DVCS)
集中化的版本控制系统(Centralized Version Control Systems,简称 CVCS)。 这类系统,诸如 CVS、Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。
集中式版本控制虽然简单,但是也存在很大的风险,当所有人都依赖这台中央电脑的时候,这台电脑崩了,所有人都会在这台电脑恢复之前不能开发,如果这台电脑只是单纯的崩了,好了之后大家又都可以使用,当这台电脑磁盘坏了,所有数据都没了,那就损失大了,没有一个人有完整的代码,所以这样存在很大的风险。
分布式版本控制系统(Distributed Version Control System,简称 DVCS)。 在这类系统中,像 Git、Mercurial、Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照,而是把代码仓库完整地镜像下来。 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
所以在分布式版本控制系统中,即使中央仓库没了 ,每个人本地仓库中都会有一份完整的代码,
但是分布式也有缺点:
- 由于每一个机器都有完整的本地仓库,所以初次获取项目(Git clone)的时候会比较耗时;
- 由于每个机器都有完整的本地仓库,所以本地占用的存储比中央式 (CVCS) 要高。
Git,Github,以及Gitlab
才接触这些东西的时候是相当懵的,根本不知道这些都是干嘛的 ,现在想想也把它们都记录下来吧。
Git:
分布式版本控制系统,记录文件或者项目的每一次修改。
GitHub:
是2008年由Ruby on Rails编写而成。GitHub同时提供付费账户和免费账户。这两种账户都可以创建公开的代码仓库,但是付费账户也可以创建私有的代码仓库。我们可以通过Git命令代码存放在github仓库中。
Gitlab:
GitLab拥有GitHub拥有的一切,但他拥有更多——让团队对它们的repositories拥有更多的控制,它的特色:
- 非常便捷的用户界面,在同一界面上获取到:projects,最近的projects,用户,最近的用户,群组和状态;
- 允许设置仓库权限是公用的还是私有的;
- “Snippet support”让用户分享一个project的部分代码,而不是整个project。
- 受保护的分支是一种提升代码安全性的新方法,它们允许用户设置project的获取权限,所以一个团队中只有特定的人可以push,force push或者删除一个分支的代码。
- Authentication levels更进一步的提升安全性,允许用户给人读写以外的权限。举例来说,你可以给一个组员跟踪变动的权限却不给他获取代码的权限。
- 你可以设置获取到团队的整体的改进进度,而不是你个人的进度。
- 开发者通过打上“仍在进行中”状态标签让其他成员知道代码没有完成,从而阻止未完成的代码合并到其他的代码中。
- “innersourcing”公司的资源如果员工不再权限范围内,将不知道这个资源的存在。