导读目录
1.为什么要用Git版本控制
2.Git文件结构和存储原理
3.GitFlow分支开发规范
4.Git 常见问题和解决方案
5.持续集成和敏捷开发
1.Git把内容按元数据方式存储,hash存储方式, 每一次提交都是一个整个项目的镜像.
2.每个客户端的源,都可以作为clone对象.包含所有中心版本库的元素.
源于linux的一句话, 一切系统皆为文件, svn左边, git右边. Git每次提交,都是一个对项目的 完整快照.
当在一个新目录或已有目录执行 git init 时,Git 会创建一个 .git 目录。 这个目录包含了几乎所有 Git 存储和操作的对象。
一切系统都是有文件构成. 这些文件管理着 一个项目的版本.
文件存储, 版本越多,存储信息越大, 运行也就越慢.
下图,是 一次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业务流程
Jenkins管道任务
用Mac, linux, 还是windows,都会有对应的Git图形管理界面, 主要展示idea插件.
以idea为例
github: https//github.com/ccj659/
简书:http://www.jianshu.com/u/94423b4ef5cf
CSDN:http://blog.csdn.net/ccj659/article/