当编写代码的时候,想要删除一个函数或一段代码,又怕以后需要时无法恢复怎么办?可以先把当前的文件另存为一个新的文件,然后修改,修改到一定程度后,再另存为一个新的文件,这样一直修改下去,最后如图6-27所示。
图6-27 早期文件管理模式
过了一周,若又想找回被删除的代码,可能已经记不清楚删除前的代码保存在哪个文件里了,只好逐个文件去找,非常麻烦。
1.集中式文件管理系统与分布式文件管理系统
文件管理系统可以帮助用户对存储的文件进行版本控制。早期出现的文件管理系统是集中式文件管理系统,其有一个单一的集中管理的服务器,保存所有文件的修改版本,而协同合作的开发人员通过客户端连接到这台服务器,取出最新的文件或者提交更新。在集中式文件管理系统中(图6-28),版本库是集中存放在中央服务器的,开发人员工作时用的是自己的计算机,所以首先需要从中央服务器上提取最新的文件版本,然后开始工作,等工作完了,再把自己的工作提交到中央服务器。这里中央服务器就好比是一个图书馆,要修改其中的一本书,必须先要从图书馆里把书借出来,然后修改(更新),修改之后再把书放回图书馆。
图6-28 集中式文件管理系统
集中式文件管理系统必须联网才能工作,所以它对网络环境要求比较高。
分布式文件管理系统(图6-29)没有中央服务器的概念,开发人员使用相关的客户端提取的不只是最新的文件,而是把代码仓库完整地镜像下来,这相当于每个开发人员的计算机都是一个完整的版本库,这样任何一处协同工作的服务器出现故障都可以用任何一个镜像出来的本地仓库恢复,并且即便网络环境比较差也不用担心,因为版本库就在本地计算机上。
图6-29 分布式文件管理系统
关于集中式文件管理系统和分布式文件管理系统,可以总结以下3点内容:
(1)分布式文件管理系统下的本地仓库包含代码库和历史库,在本地可以查看版本历史;
(2)集中式文件管理系统下的历史仓库存在于中央仓库,每次对比与提交代码都必须连接到中央仓库;
(3)多人开发时,如果充当中央仓库的代码仓库出现故障,任何一个开发人员都可以随时创建一个新的中央仓库,然后通过同步恢复中央仓库。
2.文件管理系统仓库分层
文件管理系统的工作总共分4层,其中3层是在本地,包括工作目录、暂存区和本地仓库,如图6-30所示。
图6-30 仓库分层
(1)工作目录执行一切文件操作的地方。
(2)暂存区和本地仓库只用来存放数据。
(3)第4层叫作远程仓库,它处于中心服务器,也就是开发人员做好工作之后将代码推送到远程仓库,或者从远程仓库拉取最新代码到本地。
为了更好地理解和使用文件管理系统,引入一个全新的概念——Git。Git可以有效、高速地处理从很小到非常大的项目版本管理,也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Git早期是用于Linux内核开发的版本控制工具,与常用的版本控制工具CVS、Subversion等不同,它采用分布式版本库的方式,不必服务器端软件支持,使源代码的发布和交流极其方便。Git的速度很快,这对于诸如Linux Kernel这样的大项目来说很重要。
其实仓库分层说的就是Git仓库分层,Git所存储的是一系列文件快照,然后Git跟踪这些文件快照,发现哪个文件快照有变化,就会提示需要添加到暂存区或提交到本地仓库来保证工作目录是“干净”的。
将本地代码推送到远程文件管理系统仓库,需要经历几个过程:add(添加)到暂存区,commit(提交)到本地仓库,最后push(推送)到远程仓库。
当在文件管理系统上创建好账号后就可以开始创建一个版本库,用来管理代码文件。首先,创建一个空目录,然后在这个目录下输入“git init”,这样Git仓库就创建完成了,在文件夹下会有一个“.git”的隐藏目录。Git的版本库里存放了很多东西,其中最重要的是称为stage的暂存区,还有Git自动创建的第一个分支master,以及指向master的一个指针HEAD。工作区(Working Directory)就是在计算机里能看到的目录,比如刚刚创建的文件夹就是一个工作区。
代码提交逻辑如图6-31所示。
把文件往文件管理系统版本库里添加的时候,是分两步执行的:
第一步,使用“git add<filename>”把文件添加进去,实际上就是把文件修改添加到暂存区,这里需要注意的是该文件在工作区是有改动的,如果没有改动,也就添加不了。
第二步,使用“git commit”提交更改,实际上就是把暂存区的所有内容提交到当前分支。可以简单理解为,需要提交的文件修改都放到暂存区,然后一次性提交暂存区的所有修改到远程仓库。
图6-31 代码提交逻辑
3.文件管理系统的工作流程
文件管理系统是一个用于仓库管理的系统,是使用Git作为代码管理工具,并在此基础上搭建起来的Web服务。文件管理系统一般用于在企业、学校等内部网络搭建私人服务器,它对软件工程质量管理非常重要。
文件管理系统的工作流程是怎么样的呢?其实非常简单,开发人员在文件管理系统里提交文件的修改,然后文件管理系统会将这些修改通过WebPub网站发布系统发布出来,WebPub作为中间人,会从文件管理系统拉取代码,经过加工,再转发到FTP服务器,如图6-32所示。
(www.xing528.com)
图6-32 文件管理系统的工作流程
一切操作都可以通过WebPub页面进行。其实在文件管理系统的后台,WebPub会先把修改提交到文件管理系统,然后再从文件管理系统拉取代码,最后重新在WebPub上进行发布。这是为了保持版本的一致性,降低出错的概率,让所有修改变得有历史记录可查。
接下来简单介绍文件管理系统的界面。当使用账号、密码登录系统后就可以看到账号的基本信息,比如近期的Activity,所属的Group、提交的项目、个人项目、已开始的项目等,如图6-33所示。
在“Activity”区域,可以看到近期的Activity,如图6-34所示。
“Personal projects”区域会显示该账号提交的所有项目信息,如图6-35所示。
图6-33 文件管理系统界面
图6-34 近期Activity清单
图6-35 个人项目清单
选择一个项目就可以进入项目详情页面,在项目详情页面,可以看到项目的概要信息、项目的名称、项目的ID、项目的地址等信息,如图6-36所示。
图6-36 项目详情
下面通过一个实例让读者对文件管理系统的使用有一个更加全面的了解。
1)添加项目文件
在项目详情页面,单击“Upload File”按钮,在弹出的“Upload New File”页面中选择想要提交的文件,并且在“Commitmessage”框中输入本次修改的目的以及概要等信息,然后单击“Upload file”按钮,如图6-37所示。
图6-37 提交代码
项目文件提交完成后如图6-38所示。
图6-38 项目文件提交成功
2)修改项目文件
那么如何修改已经提交的项目文件的代码呢?在项目详情页面中选择“Repository”→“Files”选项,选中想要修改的文件,单击“Edit”按钮,在修改完成后,在“Commit message”框中输入本次修改的目的以及概要等信息,然后单击“Commit changes”按钮完成本次修改,如图6-39所示。
图6-39 修改项目文件
3)查看历史
在项目详情页面,在菜单栏中选择“Repository”→“Commits”选项,进入提交列表页面,如图6-40所示。
单击每条提交记录后面的文件夹图标,可以看到本次提交后代码仓库中存在的文件情况。
如果想要查看单个文件的修改历史,则需要在菜单栏中选择“Repository”→“Files” 选项,选中想要查看的文件,然后在页面上单击“History”按钮,就可以看到当前文件的所有修改历史清单,如图6-41所示。
图6-40 提交列表页面
图6-41 单文件修改历史
单击其中一条修改记录就可以查看本次的修改详情,例如本次修改的提交编号、上次修改的提交编号、修改的文件数、增加的行数、删除的行数等,另外也可以通过单击“Inline”“Side-By-Side”按钮来切换查看源码的模式,在源码显示窗口中,红色代表删除的行,绿色则代表增加的行,如图6-42所示。
4)回退到历史版本
最最简单的方式是从提交记录里找到想要回退的历史版本,然后手工把历史版本中文件的代码复制,粘贴到当前版本的该文件中即可。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。