为什么要用版本管理
手动合并文件十分的繁琐。
分布式与集中式的对比
分布式:
每个计算机都有一个仓库,服务器上也有一个仓库
集中式(典型的有svn):
只有服务器上有仓库。
Git阵营的两大神器
Gitlab和GitHub
Git相关命令
// 创建仓库
git init --bave // 创建裸仓库,裸仓库存储的是差异文件
git init // 创建非裸仓库,非裸仓库存储的是具体的文件
// 将代码提交到暂存区
git add . // 提交所有文件
git add xxx // 提交xxx文件
// 将暂存区的代码提交到仓库中
git commit -m "xxx" // xxx是备注信息,提交与仓库中不同的文件
git commit xxx -m "yyy" // xxx是某个文件
// 将仓库中的代码提交到远程仓库
git push origin 分支名
// 克隆远程仓库到本地仓库
git clone 用户名@xxx:yyy // xxx远程仓库url,yyy是workspace目录
// 分支操作
git checkout -b xxx // 创建xxx分支,并切换成xxx分支
git checkout xxx // 切换xxx分支
git branch xxx // 创建xxx分支,不切换分支
git branch // 查看分支
// 拉取远程仓库的文件到工作区
git pull
ssh加密(非对称加密):
提交数据:在本地提交数据时通过私钥进行加密,在远端获取数据时通过公钥进行解密。
拉取数据:远端用公钥加密,本地用私钥解密。
Git的原理
git的四个区域
Workspace: 工作区,就是你平时存放项目代码的地方
Index / Stage: 暂存区,用于临时存放你的改动,事实上它只是一个文件,保存即将提交到文件列表信息
Repository: 仓库区(或版本库),就是安全存放数据的位置,这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本。.git文件夹是本地仓库
Remote: 远程仓库,托管代码的服务器,可以简单的认为是你项目组中的一台电脑用于远程数据交换
工作流程
git的工作流程一般是这样的:
1、在工作目录中添加、修改文件;
2、将需要进行版本管理的文件add到暂存区域;
3、将暂存区域的文件commit到git仓库;
4、本地的修改push到远程仓库,如果失败则执行第5步
5、git pull将远程仓库的修改拉取到本地,如果有冲突需要修改冲突。回到第三步
因此,git管理的文件有三种状态:已修改(modified),已暂存(staged),已提交(committed)
文件的四种状态
Untracked : 未跟踪, 此文件在文件夹中,但并没有加入到git库,不参与版本控制, 通过git add 状态变为Staged。
Unmodify: 文件已经入库且未修改, 即版本库中的文件快照内容与文件夹中完全一致,这种类型的文件有两种去处,如果它被修改, 而变为Modified,如果使用git rm移出版本库, 则成为Untracked文件。
Modified: 文件已修改,仅仅是修改,并没有进行其他的操作,这个文件也有两个去处,通过git add可进入暂存staged状态,使用git checkout 则丢弃修改,返回到unmodify状态, 这个git checkout即从库中取出文件,覆盖当前修改
Staged:暂存状态,执行git commit则将修改同步到库中,这时库中的文件和本地文件又变为一致,文件为Unmodify状态。
git版本管理
Master :稳定压倒一切,禁止尚review和测试过的代码提交到这个分支上,Master上的代码是可以随时部署到线上生产环境的。
Develop :开发分支,我们的持续集成工作在这里,code review过的代码合入到这里,我们以下要讲的BUG fix和feature开发都可以基于develop分支拉取,修改完之后合入到develop分支。
Feature :功能开发和change request的分支,也即我们每一个feature都可以从devlop上拉取一个分支,开发、review和测试完之后合入develop分支。
Hotfix :紧急修改的分支,在master发布到线上出现某个问题的时候,算作一个紧急布丁。从master分支上拉取代码,修改完之后合入develop和master分支。
Release :预发布分支,比如0.1、0.2、1.12版本,我们一般说的系统测试就是基于这些分支做的,如果出现bug,则可以基于该release分支拉取一个临时bug分支。
Bug : bug fix的分支,当我们定位、解决后合入develop和Release分支,然后让测试人员回归测试,回归测试后由close这个bug