导读目录
1.为什么要用Git版本控制
2.Git文件结构和存储原理
3.GitFlow分支开发规范
4.Git 常见问题和解决方案
5.持续集成和敏捷开发
当前的版本控制系统有以下几种:
1.Git把内容按元数据方式存储,hash存储方式, 每一次提交都是一个整个项目的镜像.
2.每个客户端的源,都可以作为clone对象.包含所有中心版本库的元素.
源于linux的一句话, 一切系统皆为文件, svn左边, git右边. Git每次提交,都是一个对项目的 完整快照.
当在一个新目录或已有目录执行 git init 时,Git 会创建一个 .git 目录。 这个目录包含了几乎所有 Git 存储和操作的对象。
一切系统都是有文件构成. 这些文件管理着 一个项目的版本.
Git的文件存储结构, 不恰当的类比java中 hashMap的存储的(位桶数组+单向链表或红黑树) 桶链存储结构, 通俗的讲: 先用桶用分类规则.把一堆数据,装进筒子里,如下图所示.
文件存储, 版本越多,存储信息越大, 运行也就越慢.
下图,是 一次commit产生的一棵树(一个快照).
只要文件内容相同, 那么就是一个blob, (不管他的路径是否一样),
Git的一次提交, commit信息会刷新,这次产生变化的文件的hash值,也就是blob,
git使用hash值作为文件名,主要是为了对比差异,只要文件变了,那么该文件的hash值就会变,与老版本的文件名就不同,就可以据此判定有差异,这个信息会随着文件夹向上传递,也就催生了不同的tree包含这些不同的blob。
Emm…沿着思路想下去…
一个文件,修改后,内容变化了, 产生两个blob,
修改次数越多, blob 越多.内存占用越来越大?
git gc 了解一下….
Git 往磁盘保存对象时默认使用的格式叫松散对象 (loose object) 格式。Git 时不时地将这些对象打包至一个叫 packfile 的二进制文件以节省空间并提高效率。当仓库中有太多的松散对象,或是手工调用 git gc 命令,或推送至远程服务器时,Git 都会这样做.
打开项目Git目录, 寻找出一个分支,并打开,查看里面的sha-1字符串.
我们可以在分支间随意切换,并且都是瞬间切换完成。
Git的基本操作命令, 在这里不做过多赘述,本节会着重讲解Git中的两个疑惑点。
git reset
回滚代码到 某commit点,删除之前版本(想恢复到之前某个提交的版本,且那个版本之后提交的版本我们都不要了,就可以用这种方法).
Git revert
如果我们想恢复之前的某一版本,而不删除之前版本(该版本不是merge类型,但是又想保留该目标版本后面的版本,记录下这整个版本变动流程,就可以用这种方法)。
add 命令 现在暂时有两个作用:1 将文件添加到被跟踪状态 2:将文件从工作区放到暂存区
Commit 文件,提交到版本库。
明确了为啥要用git了, 那这里就要开始准备SVN迁移git啦~
明确了为啥要用git了, 那这里就要学习git的分支管理和gitflow流程啦~
也是用于部署生产环境的分支,确保master分支稳定性
master
分支一般由develop
以及hotfix分支合并,任何时间都不能直接修改代码
develop
为开发分支,始终保持最新完成以及bug修复后的代码
一般开发的新功能时,feature分支都是基于develop
分支下创建的
货运,调度 ,等等.
业务线module/货运
开发新功能时,以develop为基础创建feature分支
开头的为特性分支,例如实验性且效果不好的代码变更
可以从develop分支发起feature分支
代码必须合并回develop分支
分支命名: feature/
命名规则:feature/分享功能
、 module/货运_feature/login功能
、 feature/sonar扫描错误修改
release分支专为 发布版本而建的分支.也可以叫预生产环境.也可以用master分支+tag
方式来代替.
一般从develope分支创建.当develop分支上的代码
已经包含了所有将发布的版本中计划的功能
,并且已通过所有测试
时,我们就可以考虑准备创建release分支.
也就是说, 开发完成,测试完毕后,准备发布版本的分支release/v1.0.0
,
创建后,只允许做小的缺陷修正,以及准备发布版本所需的各项说明信息(版本号、发布时间,渠道分布等等).确定没问题合并到master和develop,可以删除分支,后期有需要直接从master分支的tag中找到并checkout为release/xxx
分支,进行bug修复.
等发布成功后, 切记要把将新的release/v1.0.0
的代码合并到develope中.
issue分支:用于项目代码评审,或者整改gitlab提出的issue. 命名为issue/代码安全加固
hotfix分支:用于线上bug修复,在特定release分支上创建,完成后需要同时推到 对应release 分支,待测试没有问题后, 推送到develop分支,以及master分支.
普通迭代思路
–>新建项目->创建develope分支,master分支—>需求->在develope分支进行开发->merge其他人代码-> 完成功能->测试在develope分支进行测试->测试结束->切换到master分支,merge develope代码->封包,打上tag标签v1.0.0----->下一个需求.
敏捷迭代思路
不建议修改某个commit的 messge!!!
commit修改,会同时修改掉commitid, 也就意味着这是一次新的提交, 会打乱提交树的顺序.
1.local,在.git/config里面,针对当前仓库的配置,git配置默认为local级别
git config [--local] user.name 本仓库的用户名
git config [--local] user.email 本仓库的用户邮箱
2.global,在个人home目录下的,针对当前系统用户的仓库
git config --global user.name 本仓库的用户名
git config --global user.email 本仓库的用户邮箱
3.system,在git安装目录的下,针对当前操作系统所有用户的仓库。(该级别通常不用于配置用户信息)
git config --system user.name 本仓库的用户名
git config --system user.email 本仓库的用户邮箱
使用.ignore
文件
.ignore
放到和.git
同级的目录中.可以自定义规则
PS:如果之前添加到了git管理, 但是现在想忽略掉怎么办?
编辑你的.ignore
文件后,执行以下命令
git rm -r --cached .
git add .
git commit -am "Remove ignored files"
git push 你的远端仓库
git revert
你的commitID
//将代码状态撤回到该commitID
之前.
commit
?cherry-pick
了解一下.
commit
cherry-pick
操作git reflog
了解一下, 结合git rebase
要指向的commitID
自己分支merge不到,说别人没提交代码?
Git是分布式的,狂点refresh没用的!!!…
需要重新pull远端代码, 来更新本地仓库.才会有最新的提交记录.
Git的commit排序, 是按照时间排序的!!! Commit时间越新,越靠前
还有看 log是否是当前branch.
####9.其他注意事项
git push -f
不能使用. 他会清空之前的commit记录.master
和 develop
,不能进行 rebase
操作,原则上只能改自己的分支.可持续集成又叫Continuous integration(CI)
,一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。
有两种方式
gitlab+Jenkins
gitlab+gitlabCI
Jenkins 是一个可扩展的持续集成引擎。
主要功能
主要可配置项目
Jenkins业务流程
用Mac, linux, 还是windows,都会有对应的Git图形管理界面, 主要展示idea插件.
以idea为例