一、版本控制
版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理,是软件配置管理的核心思想之一。
1、版本控制的功能:
(1)追踪文件的变更
它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。
每一次文件的改变,文件的版本号都将增加。
(2)并行开发
软件开发往往是多人协同作业,版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题,提高协同开发的效率。
并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。
2、版本控制的发展历程
(1)本地版本控制系统
本地版本控制系统有很多,大多都是采用某种简单的数据库来记录文件的历次更新差异。其中最流行的一种叫做 RCS ,现今许多计算机系统上都还看得到它的踪影。
RCS 的工作原理:在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。
(2)集中化的版本控制系统
集中化的版本控制系统解决了本地版本控制系统中不同系统上的开发者无法协同工作的缺点。
集中化的版本控制系统中有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。
多年以来,这已成为版本控制系统的标准做法。 各个开发者都是通过同一个集中管理的服务器进行工作,所以在一定程度上每个开发者都可以看到其他人的工作内容,另外,作为项目的管理者也可以轻松掌控每个开发者的权限,这比在各个客户端上维护本地数据库来得轻松容易。
当然因为是单点集中管理,存在较大的缺点:
- 中心服务器宕机后,所开发者都无法工作
- 中心数据库丢失,所有文件都丢失,每个开发者本地保存的只是部分数据的快照,并不完整。
(3)分布式版本控制系统(Git)
采用分布式版本控制系统的客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录。(过程中对文件的所有操作都是会被完整记录下来的)
这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。
因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。 分布式版本控制系统和集中化的版本控制系统的最大区别在于:集中化版本控制系统的部分机器保存的只是部分数据的快照,而分布式版本控制系统保存的是整个代码仓库的镜像。
二、Git
1、Git的结构
2、命令行的操作
(1)本地库初始化
1. cd +路径
2. cd ..
3. git init
4. ll
5. ls -al
- 选定想作为工作区的文件夹
- 使用 cd 命令进入该文件夹目录下
- git init 初始化(若在该文件夹里出现 .git 文件,则说明初始化成功)
.git 是隐藏目录需要采用 ls -al 命令: .git 目录中存放的是本地库相关的子目录和文件,不要删除,也不要胡乱修改
(2)设置签名
所谓的签名就是设置一个用户名称和一个用户email,此处的签名只看作是一个特定的字符串(email也不需要真实有效),只用来区分不同的开发人员,并不作他用。
这里的签名就是一个标志!
辨析:这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。
- 项目级别/仓库级别:仅在当前本地库范围内有效
git config user.name + 名字
git config user.email + 邮箱
签名信息保存在 .git 目录下的 config 文件中
2.系统用户级别:登录当前操作系统的用户范围
git config --global user.name 0
git config --global user.email 0@0
信息保存位置:~/.gitconfig (根目录下的 .gitconfig文件中)
对于种签名的优先级如下:
(3)状态查看(提交前后)
查看状态:包括当前所在分支,是否有待添加到缓冲区的内容,是否有待提交到本地库的内容
git status
vim + 文件名
git add + 文件名
git commit [-m "注释" +文件名]
(4)查看历史版本记录
git log
git log --pretty=oneline
git log --oneline
git reflog
(5)版本的前进/后退
(6)比较文件间差异
3、分支操作
git branch + 分支名
git branch -v
git checkout + 分支名
git merge + 有新内容的分支
解决分支冲突
当两个分支都修改了同一个地方,而且修改为的内容各不相同,此时执行合并命令的时候就会发生冲突,git本身无法决定应该以哪个分支的修改为准,此时,git会进入人工编辑状态,有用户自行决定!
|