1、Git简介
Git 是一个免费的、开源的分布式版本控制系统,可以快速高效地处理从小型到大型的各种 项目。
Git 易于学习,占地面积小,性能极快。 它具有廉价的本地库,方便的暂存区域和多个工作 流分支等特性。其性能优于 Subversion、CVS、Perforce 和 ClearCase 等版本控制工具。
1.1、何为版本控制
版本控制是一种记录文件内容变化,以便将来查阅特定版本修订情况的系统。 版本控制其实最重要的是可以记录文件修改历史记录,从而让用户能够查看历史版本, 方便版本切换。
1.2、为什么需要版本控制
个人开发过渡到团队协作
1.3、版本控制工具
- 集中式版本控制工具
- CVS、SVN(Subversion)、VSS…… 集中化的版本控制系统诸如 CVS、SVN 等,都有一个单一的集中管理的服务器,保存 所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或 者提交更新。多年以来,这已成为版本控制系统的标准做法。 这种做法带来了许多好处,每个人都可以在一定程度上看到项目中的其他人正在做些什 么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个集中化的版本控制系统,要 远比在各个客户端上维护本地数据库来得轻松容易。 事分两面,有好有坏。这么做显而易见的缺点是*服务器的单点故障。如果服务器宕 机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。
- 分布式版本控制工具
- Git、Mercurial、Bazaar、Darcs…… 像 Git 这种分布式版本控制工具,客户端提取的不是最新版本的文件快照,而是把代码 仓库完整地镜像下来(本地库)。这样任何一处协同工作用的文件发生故障,事后都可以用 其他客户端的本地仓库进行恢复。因为每个客户端的每一次文件提取操作,实际上都是一次 对整个文件仓库的完整备份。 分布式的版本控制系统出现之后,解决了集中式版本控制系统的缺陷: 1. 服务器断网的情况下也可以进行开发(因为版本控制是在本地进行的) 2. 每个客户端保存的也都是整个完整的项目(包含历史记录,更加安全)
1.5、Git 工作机制
1.6、Git 和代码托管中心
代码托管中心是基于网络服务器的远程代码仓库,一般我们简单称为远程库。
- 局域网
- GitLab
- 互联网
- GitHub(外网)
- Gitee 码云(国内网站)
2、安装Git
- 官网下载安装包,点击打开
到此,安装完成,鼠标右键出现菜单,打开bash终端,输入git --version,出现版本信息就说明安装成功。
3、Git常用命令
命令名称 | 作用 |
---|---|
git config --global user.name 用户名 | 设置用户名 |
git config --global user.email 邮箱 | 设置用户签名 |
git init | 初始化本地库 |
git status | 查看本地库状态 |
git add 文件名 | 添加到暂存区 |
git commit -m "日志信息" 文件名 | 提交到本地库 |
get reflog | 查看历史记录 |
git reset --head 版本号 | 版本穿梭 |
3.1、设置用户签名
说明: 签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看 到,
以此确认本次提交是谁做的。Git 首次安装必须设置一下用户签名,否则无法提交代码。
※注意:这里设置用户签名和将来登录 GitHub(或其他代码托管中心)的账号没有任 何关系。
3.2、初始化本地库
在项目中打开git终端,输入命令
3.3、查看本地库状态
首次查看没有任何文件
创建一个文件,添加点内容试试
检测到未追踪的文件,也就是这个文件还在工作区
3.4、添加到暂存区
颜色变成绿色,该文件已经被添加到暂存区
3.5、从暂存区中移除
git rm --cached 文件名 可以将文件移除暂存区,取消追踪该文件
3.6、提交本地库
git commit -m "日志信息" 文件名
提交之后,查看本地库状态,提示没有文件需要提交
将文件修改之后,再次查看本地库状态
提示文件被修改过,并且变成了红色
再次添加到暂存区
3.7、历史版本
语法:
- git reflog 可以查看所有分支的所有操作记录(包括已经被删除的 commit 记录和 reset 的操作),
- git log 则不能察看已经删除了的commit记录
可以看到当前只有一个版本,再次提交,产生一个新的版本
再次查看,出现了一个新的版本
3.8、版本穿梭
基本语法:git reset --hard 版本号
先查看一下现在本地库的文件
现在回退到第一次提交的版本
再次查看文件
已经回退到第一次提交的版本
git版本切换,其实操作的就是head指针
head指向分支,分支指针指向版本
3.9、关于版本切换和head指针
git中的head指针用于记录当前工作的位置,可以指向commit版本,也可以指向分支
通常,我们工作在某一个分支上,比如 master 分支。当指向branch时commit提交后,master 指针和 HEAD 指针一起前进的,每做一次提交,这两个指针就会一起向前挪一步。
但是在某种情况下(例如 checkout 了某个commit),master 指针 和 HEAD 指针这种「绑定」的状态就被打破了,变成了分离头指针状态。下图就是处于分离头指针状态的情况:
HEAD 游离状态的利弊
好处:HEAD 处于游离状态时,开发者可以很方便地在历史版本之间互相切换,比如要回到某次提交,只需要 对应的 或者 名即可。
弊端:若在该基础上进行了提交,则会新开一个「匿名分支」;也就是说我们的提交是无法可见保存的,一旦切换到别的分支,原游离状态以后的提交就不可追溯了。
可以看到之后head指针指向了这个版本,而且有一个匿名分支
提交信息和当前文件也已经回到了这个版本的状态
切换回其他分支,此匿名分支就不见了
在head指针处于游离状态时,我们所做的add和commit都是没有意义的,切换到其他分支之后,head游离状态会消失,该分支也会消失
解决方法:在git checkout到提交的版本之后,创建一个新分支,然后我们所有操作都会保存到这个分支,之后在合并就好
另外,checkout还可以用于撤销文件修改,git checkout 文件名
该命令主要用于检出某一个指定文件。
如果不填写commit id,则默认会从暂存区检出该文件,如果暂存区为空,则该文件会回滚到最近一次的提交状态。
例如:
当暂存区为空,如果我们想要放弃对某一个文件的修改,可以用这个命令进行撤销:
3.10、关于git reset
reset有三种模式
-
--hard:重置位置的同时,直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区。
-
--soft:重置位置的同时,保留working Tree工作目录和index暂存区的内容,只让repository中的内容和 reset 目标节点保持一致,因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变,暂存区原有的内容也不变,只是原节点和Reset节点之间的所有差异都会放到暂存区中。
-
--mixed(默认):重置位置的同时,只保留Working Tree工作目录的內容,但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致,因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。
假设现在有两次提交,first commit和second commit,以下演示各自的区别
1、--hard,从second commit重置到first commit,second commit 提交记录消失,工作区和暂存区都回到first commit提交时的状态,也就是相当于first commit(第一次提交)-->直接撤销所有修改
2、--soft,从second commit重置到first commit,second commit 提交记录消失,工作区内容不变,将第二次修改的内容添加到暂存区,也就是相当于first commit(第一次提交)-->修改内容-->git add
3、--mixed(默认),从second commit重置到first commit,second commit 提交记录消失,工作区内容不变,暂存区回到没有将修改添加进暂存区的状态,也就是相当于first commit(第一次提交)-->修改内容-->
4、Git分支操作
4.1、什么是分支
在版本控制过程中,同时推进多个任务,为每个任务,我们就可以创建每个任务的单独 分支。
使用分支意味着程序员可以把自己的工作从开发主线上分离开来,开发自己分支的时 候,不会影响主线分支的运行。
对于初学者而言,分支可以简单理解为副本,一个分支就是 一个单独的副本。(分支底层其实也是指针的引用)
4.2、分支的好处
同时并行推进多个功能开发,提高开发效率。 各个分支在开发过程中,如果某一个分支开发失败,不会对其他分支有任何影响。失败 的分支删除重新开始即可。
4.3、分支的操作
命令名称 | 作用 |
---|---|
git branch 分支名 | 创建分支 |
git branch -v | 查看分支 |
git checkout 分支名 | 切换分支 |
git merge 分支名 | 把指定的分支合并到当前分支上 |
4.3.1、查看分支
4.3.2、创建分支
此时已经有两个分支(新建分分支是当前分支的副本)
在当前分支做修改,也就是master分支
再次提交到本地库
4.3.3、切换分支
git checkout -b 分支名
可以创建并切换分支
再次查看文件
可见,当前文件没有被修改
修改当前分支
切换回master分支,准备合并
4.3.4、合并分支
- 正常合并
创建一个文件,add和commit
创建一个新的分支并修改文件内容,add和commit
切换回master分支,合并新分支
可以看到文件直接修改了,并且提示信息是Fast-forward
- 合并冲突
首先创建一个文件
add和commit
创建并切换分支
在新分支里做如下修改
add和commit,切换回master分支
修改文件的同一行,add和commit
合并分支
提示合并发生冲突
查看本地库状态
打开修改的文件
手动修改之后
再次add和commit,查看本地库状态
合并之后提交必须全部一起提交,不然会报错
fatal: cannot do a partial commit during a merge.(无法在合并期间部分提交)
关于两个分支修改同一个文件,合并时产生的情况
修改同一个文件同一个区域会产生冲突
什么是文件的同一区域?
- 文件的同一行
- 文件的相邻行
演示:
master分支
新建分支修改文件
切换回master分支修改文件
合并发生冲突
打开文件
同样案例修改相隔一行:
分支修改文件
切换回master分支修改文件
合并分支
没有出现冲突,代码直接合并
5、Git团队协作机制
- 1、团队内协作
- 2、跨团队协作
6、GitHub操作
远程仓库国内可以使用gitee,访问速度更快,使用方法和github一样,这里只介绍github
注册账号,创建一个仓库
创建完成之后
上面的地址就是仓库地址
6.1、常用操作
命令名称 | 作用 |
---|---|
git remote | 查看所有远程仓库 |
git remote -v | 查看所有远程仓库详细信息 |
git remote add 别名 远程地址 | 添加远程仓库并起别名 |
git push 远程仓库(可以别名) 分支 | 推送本地分支上的内容到远程库 |
git clone 远程地址 | 将远程仓库的内容克隆到本地 |
git pull 远程仓库 远程分支名 | 将当前远程仓库对于分支最新内容拉下来与当前本地分支直接合并 |
git remote rm 远程仓库 | 远程仓库 |
6.2、推送-git push
git push 远程仓库 本地分支名:远程分支名
若当前分支和远程分支名字相同,则可以省略
git push 远程仓库 分支名
注意:
第一次提交会要求选择登陆方式,如果浏览器登陆过了直接用浏览器登陆就好
这里登陆的账户和提交代码的账户没有关系,登陆之后只是说明这台电脑再次登陆github不需要用户名密码(以及验证这个账号对该仓库的权限), 具体提交代码的用户是谁看git设置的邮箱
如果git-email和github-email不一致,则即使github-username和git-username用户名相同,用户在本地git和在github上操作也会被认为是不同的用户在操作,意味着:github-email用户创建了仓库,git-email用户从本地上传的代码
如果git-email和github-email一致,则认为是同一用户,意味着:用户在本地git上操作再push到github上,和直接在github上操作没有区别
总结:第一次上传代码输入用户名密码只是为了这台电脑可以正常访问github
git的email和github的email相同,则github认为是本人操作
git的email和github的email不相同,也可以正常push,但是显示的是另外一个人
另外,同一台可以设置不同用户名密码
优先级:local > global > system
6.3、拉取代码-git pull
git pull 远程仓库 分支
拉取远程分支到本地当前分支,并且自动合并
6.4、克隆远程仓库-git clone
克隆远程仓库不需要登陆,公开仓库读权限对所有人公开
克隆也不需要初始化仓库,直接git clone 远程仓库地址
完成了克隆
6.5、团队内协作
合作者模式:
团队内协作先要邀请开发人员,不然是无法push的,提示
remote: Permission to Z-HaiHua/GitTest.git denied to FH0524.
仓库的所有者把邀请合作者一起开发这个项目(git提交代码会用这个账号进行权限验证,具体提交的人还是看git设置里面的邮箱),需要加入项目的人需要同意
成为合作者之后,才能通过这个登陆github的账户提交代码到仓库
关于合作模式
git有两种合作模式:
- 合作者模式(collaborator)
需要仓库主人将该用户添加进合作者,邀请该用户参与开发
每个合作者新建自己部分的feature branch,在这个新分支上进行代码修改,提交合并
如果希望项目既有collaborator同时又可以限制他们的读写权利,尤其是限制其“写”的权利,可利用organization来为team成员赋予不同等级的权力。
另外,合作者在主页看不到自己合作的仓库,需要到setting下的repository部分才能看到自己合作的项目
- 贡献者模式(contributor)--跨团队协作
每个贡献者在他们fork的仓库上进行代码修改、发布自己负责的部分,再向主仓库提起pull request
6.6、跨团队协作
参加协作的人fork项目到自己的库当中,然后自己库中也会有一个和原仓库一模一样的仓库,进行修改之后,通过pull request 向原项目发送拉取请求
fork之后会出现
修改代码提交之后,点击 pull request,发送拉取请求
选择好合并的分支
再次点击pull request,打开刚才的pull request
仓库会收到pull request
打开之后
点击合并之后,可以看到仓库中代码已经改变
7、SSH免密登陆
使用命令:
ssh-keygen -t rsa -C "#”
t是加密方式
c是备注消息,便于自己记住此密钥是干嘛的,可以随便填写
之后三次回车,什么都不输入即可(第一次输入文件保存位置,默认在c盘用户目录下.ssh文件夹,第二次输入密码,第三次确认密码)
第一次使用SSH连接会提示
Are you sure you want to continue connecting (yes/no)? yes
输入yes即可,以后这台电脑连接github就不需要账号密码了
8、IDEA集成Git
8.1、配置忽略文件
在项目开发中 ,我们肯定不希望整个项目的所有文件都被git追踪,比如idea的配置文件,编译之后的class文件,这时候我们就需要配置忽略文件
1、创建忽略规则配置文件xxx.ignore(前缀随便,文件后缀必须是这个)该文件放在哪里都行
java项目中常用的ignore文件
*.class
# Eclipse
.project
.classpath
.settings/
# Intellij
*.ipr
*.iml
*.iws
.idea/
# Maven
target/
# Gradle
build
.gradle
# Log file
*.log
log/
# out
**/out/
# Mac
.DS_Store
# others
*.jar
*.war
*.zip
*.tar
*.tar.gz
*.pid
*.orig
temp/
然后配置到git当中,可以配置到系统、用户组、仓库
[core]
...
excludesfile = D:/git/GitTest01/.git/.gitignore
8.2、idea中使用Git
8.2.1、配置Git
在idea中使用git进行版本控制
点击版本控制设置
8.2.2、配置Git忽略文件
将文件或者文件夹添加进忽略名单
忽略的文件
8.2.3、基本使用
添加暂存区和提交都是鼠标右键--->Git--->.......
切换版本
在idea中打开log窗口,可以查看所有提交记录,右键选择checkout或者reset
新建分支:右键-->Git-->branch-->New Branch
切换分支:右键-->Git-->branch-->选择要切换的分支-->点击-->checkout
删除分支:当前分支不能删除,需要切换到其他分支才可以删除当前分支,右键-->Git-->branch-->选择要删除的分支-->点击-->delete
合并分支
合并冲突
9、IDEA集成GitHub
使用令牌登陆,首先创建令牌
令牌创建之后要立马复制下来,不然之后看不到了
然后到IDEA中添加账号
之后把令牌填上去就可以登陆了,登陆之后
9.1、IDEA中创建github仓库并分享项目
IDEA自带的github插件可以在idea中远程创建github仓库以及分享项目
9.2、IDEA中操作github
在idea中创建仓库必须要用账号密码登陆,其他操作可以用SSH免密登陆
添加一个SSH连接的git仓库就好
push和pull,都是右键-->Git-->push/pull
克隆项目
输入链接即可克隆项目
Maven基础
1、Maven是什么
在Javaweb开发中,需要使用大量的jar包,我们手动去导入;
如何能够让一个东西自动帮我导入和配置这个jar包。由此,Maven诞生了!
Maven的本质是一个项目管理工具,将项目开发和管理过程抽象成一个项目对象模型(POM)
Maven是用Java语言编写的。他管理的东西统统以面向对象的形式进行设计,最终它把一个项目看成一个对象,而这个对象叫做POM(project object model),即项目对象模型。
我们说一个项目就是一个对象,作为对象的行为、对象的属性都有哪些呢?
Maven说我们需要编写一个pom.xml文件,Maven通过加载这个配置文件就可以知道我们项目的相关信息了!到这里我们知道了Maven离不开一个叫pom.xml的文件。因为这个文件代表就一个项目。
提个问题大家思考,如果我们做8个项目,对应的是1个文件,还是8个文件?肯定是8个!
那Maven是如何帮我们进行项目资源管理的呢?这就需要用到Maven中的第二个东西:依赖管理。这也是它的第二个核心!
所谓依赖管理就是maven对项目所有依赖资源的一种管理,它和项目之间是一种双向关系,即当我们做项目的时候maven的依赖管理可以帮助你去管理你所需要的其他资源,当其他的项目需要依赖我们项目的时候,maven也会把我们的项目当作一种资源去进行管理,这就是一种双向关系。
那maven的依赖管理它管理的这些资源存在哪儿呢?主要有三个位置:本地仓库,私服,*仓库
本地仓库顾名思义就是存储在本地的一种资源仓库,如果本地仓库中没有相关资源,可以去私服上获取,私服也是一个资源仓库,只不过不在本地,是一种远程仓库,如果私服上也没有相关资源,可以去*仓库去获取,*仓库也是一种远程仓库。
Maven除了帮我们管理项目资源之外还能帮助我们对项目进行构建,管理项目的整个生命周期,当然它的这些功能需要使用一些相关的插件来完成,当然整个生命周期过程中插件是需要配合使用的,单独一个无法完成完整的生命周期。
1.2、Maven的作用
Maven的作用我们可以分成三类:
(1)项目构建:提供标准的,跨平台的自动化构建项目的方式
(2)依赖管理:方便快捷的管理项目依赖的资源(jar包),避免资源间的版本冲突等问题
(3)统一开发结构:提供标准的,统一的项目开发结构,如下图所示:
各目录存放资源类型说明:
src/main/java:项目java源码
src/main/resources:项目的相关配置文件(比如mybatis配置,xml映射配置,自定义配置文件等)
src/main/webapp:web资源(比如html,css,js等)
src/test/java:测试代码
src/test/resources:测试相关配置文件
src/pom.xml:项目pom文件
2、下载和安装
旧版下载
解压即安装完成
各目录结构说明:
bin:可执行程序目录,
boot:maven自身的启动加载器
conf:maven配置文件的存放目录
lib:maven运行所需库的存放目录
配置环境变量
path环境变量中
输入命令
即安装成功
由于maven下载依赖默认从国外的*仓库下载,网速会很慢,所以要配置镜像
打开conf下的settings文件
配置好镜像
<mirror>
<id>aliyunmaven</id>
<mirrorOf>central</mirrorOf>
<name>阿里云公共仓库</name>
<url>https://maven.aliyun.com/repository/public</url>
</mirror>
由于maven默认把依赖下载到c盘,这里改一下路径
3、Maven基础概念
3.1、仓库
关于仓库,我们前面讲到了有三种:本地仓库,私服,*仓库,其中私服和*仓库都属于远程仓库
*仓库:maven团队自身维护的仓库,属于开源的
私服:各公司/部门等小范围内存储资源的仓库,私服也可以从*仓库获取资源
本地仓库:开发者自己电脑上存储资源的仓库,也可从远程仓库获取资源
私服的作用:
(1)保存具有版权的资源,包含购买或自主研发的jar
(2)一定范围内共享资源,能做到仅对内不对外开放
3.2、坐标
我们说maven的仓库里存储了各种各样的资源(jar包),那这些资源我们如何找到它们呢?我们需要知道它们具体的一个位置才能知道如何找到它们,这个就叫坐标
坐标:maven中的坐标用于描述仓库中资源的位置
maven坐标的主要组成如下:
groupId:定义当前资源隶属组织名称(通常是域名反写,如:org.mybatis;com.itheima)
artifactId:定义当前资源的名称(通常是项目或模块名称,如:crm,sms)
version:定义当前资源的版本号
packaging:定义资源的打包方式,取值一般有如下三种
-
jar:该资源打成jar包,默认是jar java工程打包为jar
-
war:该资源打成war包 web工程打包为war
-
pom:该资源是一个父资源(表明使用maven分模块管理),打包时只生成一个pom.xml不生成jar或其他包结构
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<!--指定pom的模型版本-->
<modelVersion>4.0.0</modelVersion>
<!--打包方式 web工程打包为war java工程打包为jar-->
<packaging>war</packaging>
<!--组织id-->
<groupId>com.zh</groupId>
<!--项目id-->
<artifactId>web01</artifactId>
<!--组织id release代表完成版,SNAPSHOT代表开发版-->
<version>1.0-SNAPSHOT</version>
<!--设置当前工程的所有依赖-->
<dependencies>
<!--具体的依赖-->
<dependency>
</dependency>
</dependencies>
</project>
3.3、插件
Maven 实际上是一个依赖插件执行的框架,它执行的每个任务实际上都由插件完成的。Maven 的核心发布包中并不包含任何 Maven 插件,它们以独立构件的形式存在, 只有在 Maven 需要使用某个插件时,才会去仓库中下载。
Maven 默认为一些核心的生命周期阶段绑定了插件目标,当用户调用这些阶段时,对应的插件目标就会自动执行相应的任务。
运行web项目可以添加tomcat插件
<build>
<plugins>
<!--打war包插件-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.0</version>
</plugin>
<!--Tomcat插件 -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</build>
3.4、依赖
Maven项目可以通过声明式导入所需要的资源,需要什么,写几行代码,Maven就会自动把资源下载并添加到资源库中
<!--项目依赖-->
<dependencies>
<!--具体依赖的jar包配置文件-->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
</dependencies>
3.5、POM文件
pom.xml 是Maven的核心配置文件
<?xml version="1.0" encoding="UTF-8"?>
<!--Maven版本和头文件-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.zh</groupId>
<artifactId>javaweb-01-maven</artifactId>
<version>1.0-SNAPSHOT</version>
<!--Package:项目的打包方式
jar:java应用
war:JavaWeb应用
-->
<packaging>war</packaging>
<!--配置-->
<properties>
<!--项目的默认构建编码-->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!--编码版本-->
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<!--项目依赖-->
<dependencies>
<!--具体依赖的jar包配置文件-->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
</dependencies>
<!--项目构建用的东西-->
<build>
<plugins>
<!--打war包插件-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.0</version>
</plugin>
<!--Tomcat插件 -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</build>
</project>
4、创建Maven项目
创建一个最简单的Maven项目
这就是一个最简单的Maven项目
创建完成记得看一眼是不是用的自己的Maven仓库
5、Maven依赖管理
依赖传递:
依赖具有传递性,分两种
(1)直接依赖:在当前项目中通过依赖配置建立的依赖关系
(2)间接依赖:被依赖的资源如果依赖其他资源,则表明当前项目间接依赖其他资源
依赖传递冲突
依赖传递的冲突问题:
在依赖传递过程中产生了冲突,我们有三种优先法则
(1)路径优先:当依赖中出现相同资源时,层级越深,优先级越低,反之则越高
(2)声明优先:当资源在相同层级被依赖时,配置顺序靠前的覆盖靠后的
(3)特殊优先:当同级配置了相同资源的不同版本时,后配置的覆盖先配置的
以一个项目为根,直接依赖称为1度资源,直接依赖的直接依赖称为2度资源,直接依赖的直接依赖的直接依赖称为3度资源。
当然依赖冲突在这里我们并不需要记,后面会有如何解决此问题的办法。
可选依赖
可选依赖指的是对外隐藏当前所依赖的资源-->不透明
加一个optional属性
<dependencies>
<dependency>
<groupId>Junit</groupId>
<artifactId>Junit</artifactId>
<version>4.12</version>
<optional>true</optional>
</dependency>
</dependencies>
排除依赖
排除依赖指主动断开依赖的资源,被排除的资源无需指定版本
<dependencies>
<dependency>
<groupId>Junit</groupId>
<artifactId>Junit</artifactId>
<version>4.12</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</dependency>
</dependencies>
依赖范围
依赖的jar默认情况可以在任何地方可用,可以通过scope标签设定其作用范围
这里的范围主要是指以下三种范围
(1)主程序范围有效(src/main目录范围内)
(2)测试程序范围内有效(src/test目录范围内)
(3)是否参与打包(package指令范围内)
此外:scope标签的取值有四种:
- compile
- test
- provided
- runtime
这四种取值与范围的对应情况如下:
6、Maven生命周期与插件
Maven对项目构建的生命周期划分为3套
clear:清理工作
default:核心工作,例如编译、测试、打包、部署等
site:产生报告、发布站点等
6.1、clear生命周期
clean:清理工作
pre-clean:执行一些在clean之前的工作
clean:移除上一次构建产生的所有文件
post-clean:执行一些在clean之后立刻完成的工作
6.2、default生命周期
default:核心工作,例如编译,测试,打包,部署等
对于default生命周期,每个事件在执行之前都会将之前的所有事件依次执行一遍
6.3、site生命周期
site:产生报告,发布站点等
pre-site:执行一些在生成站点文档之前的工作
site:生成项目的站点文档
post-site:执行一些在生成站点文档之后完成的工作,为部署做准备
site-deploy:将生成的站点文档部署到特定的服务器上
7、Maven资源导出问题
pom文件中加入如下配置
<!--在build中配置resources,来防止我们资源导出失败的问题-->
<!--resources下的properties、xml都可以导出-->
<!--java下的properties、xml都可以导出-->
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<includes>
<include>**/*.properties</include>
<include>**/*.xml</include>
</includes>
<filtering>true</filtering>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.properties</include>
<include>**/*.xml</include>
</includes>
<filtering>true</filtering>
</resource>
</resources>
</build>
Maven进阶
1、分模块开发与设计
按模块划分之后,将需要使用的模块使用引入资源的方式引入即可,注意,在引入之前,需要先将该模块安装到本地库中
2、聚合模块
作用:快速构建maven工程,处理多模块工程比较方便
使用:创建一个空模块,打包类型为pom,此模块不需要src
<packaging>pom</packaging>
定义当前模块构建时关联的其他模块名称
<modules>
<module>ssm-controller</module>
<module>ssm-service</module>
<module>ssm-dao</module>
<module>ssm-pojo</module>
</modules>
参与集合的模块构建顺序与模块间的依赖有关,与配置无关
3、继承
作用:通过继承,可以实现在子工程中沿用父工程中的配置
使用:在子工程中声明父工程坐标与对应路径
注意,继承和聚合一样,父工程中也只有一个pom文件
<parent>
<groupId>. . .</groupId>
<artifactId>. . .</artifactId>
<version>. . .</version>
<relativePath>. . .</relativePath>
</parent>
在父工程中管理依赖
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>${springframework.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
插件管理
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
这里声明只是为子工程设定版本,并不是实际的去引用依赖
子工程继承之后,不在需要写完整的GAV,让父工程统一管理
<groupId>com.juvenxu.mvnbook.account</groupId>
<artifactId>account-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
只需要写
<artifactId>account-parent</artifactId>
同时,在依赖和插件中也只需要写
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
版本通过父工程继承
可继承的pom元素
- groupId:项目组ID,项目坐标的核心元素
- version: 项目版本, 项目坐标的核心元素
- description: 项目的描述信息
- organization: 项目的组织信息
- inceptionYear: 项目的创始年份
- url: 项目的URL地址
- developers: 项目开发者信息
- contributors: 项目的贡献者信息
- distributionManagement: 项目的部署配置
- issueManagement: 项目的缺陷跟踪系统信息
- ciManagement: 项目的持续集成系统信息
- scm: 项目的版本控制系统信息
- mailingLists: 项目的邮件列表信息
- properties: 自定义的maven属性
- dependencies: 项目的依赖配置
- dependencyManagement: 项目的依赖管理配置
- repositories: 项目的仓库配置
- build: 包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置等
- reporting: 包括项目的报告输出目录配置、报告插件配置等
继承与聚合
- 作用
- 聚合用于快速构建项目
- 继承用于快速配置
- 相同点
- 聚合与继承的pom文件打包方式都为pom,可以将两种关系制作在同一个pom文件中
- 聚合与继承属于设计模式,并无实际的模块内容
- 不同点
- 聚合是在当前模块中配置关系,聚合可以感知到参与聚合的模块有哪些
- 继承是在子模块中配置关系,父模块无法感知哪些子模块继承了自己
4、属性
Maven中允许自定义属性,相当于变量,在需要的地方引用
<properties>
<spring.framework>4.0.4.RELEASE</spring.framework>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.framework}</version>
</dependency>
</dependencies>
此外,maven属性分为
- 内部属性
- 内置属性
- 项目属性
- setting属性
- 自定义属性
- 外部属性
- java系统属性
- 环境变量属性
具体不在这里赘述
5、版本管理
工程版本
- SNAPSHOT (快照版本)
- 项目开发过程中,为方便团队成员合作,解决模块间相互依赖和时时更新的问题,开发者对每个模块进行构建的时候,输出的临时性版本叫快照版本(测试阶段版本)
- 快照版本会随着开发的进展不断更新
- RELEASE (发布版本)
- 项目开发到进入阶段里程碑后,向团队外部发布较为稳定的版本,这种版本所对应的构件文件是稳定的,即便进行功能的后续开发,也不会改变当前发布版本内容,这种版本称为发布版本
工程版本号约定
- 约定规范:
- <主版本>.<次版本>.<增量版本>.<里程碑版本>
- 主版本:表示项目重大架构的变更,如: spring5相较 于spring4的迭代
- 次版本:表示有较大的功能增加和变化,或者全面系统地修复漏洞
- 增量版本:表示有重大漏洞的修复
- 里程碑版本:表明- -个版本的里程碑(版本内部)。这样的版本同下一-个正式版本相比,相对来说不是很稳定,有待更多的测试
- 范例:
5.1.9.RELEASE
6、资源配置
maven支持配置文件使用pom文件里面配置的属性
使用:在pom文件中定义属性和属性值,在配置文件中使用${属性} 的方式引用
<properties>
<jdbc.url>jdbc:mysql://localhost:3306/de01</jdbc.url>
</properties>
.....
配置资源文件对应的信息
<resources>
<resource>
<!-设定配置文件对应的位置目录,支持使用属性动态设定路径-->
<directory>${project.basedir}/src/main/resources</directory>
<!--开启对配置文件的资源加载过滤-->
<filtering>true</ filtering>
</resource>
</resources>
7、多环境开发配置
<!--多环境配置-->
<!--创建多环境-->
<profiles>
<!--定义具体的环境:生产环境-->
<profile>
<!--定义环境对应的唯一名称-->
<id>pro_ env</id>
<!--定义环境中专用的属性值-->
<properties>
<jdbc.ur1>jdbc:mysql://127.1.1.1:3306/ssmdb</jdbc.ur1>
</ properties>
<!--设置默认启动-->
<activation>
<activeByDefault>true</ activeByDefault>
</activation>
</profi1e>
<!--定义具体的环境:开发环境-->
<profile>
<id>dev_env</id>
....
</profi1e>
</profiles>
8、跳过测试
- 使用命令跳过测试
mvn 指令 -D skipTests
-
使用idea界面操作
-
通过配置插件
<plugin>
<artifactId>maven- surefire -plugin</artifactid>
<version>2.22. 1</version>
<configuration>
<skipTests>true</ skipTests><!--设置跳过测试-->
<includes> <!-- 包含指定的测试用例-->
<include>**/User*Test.java</include>
</includes>
<excludes><!--排除指定的测试用例-->
<exclude>**/User*TestCase.java</exclude>
</excludes>
</configuration>
</p1ugin>
9、私服
Nexus仓库类型
Nexus仓库类型有三种:
1.hosted:宿主仓库(服务器本地仓库):通常我们上传自己的依赖到这一类型的仓库,比如公司的第二方库。
2.proxy:代理仓库:它们被用来代理远程的公共仓库,如maven*仓库
3.group:仓库组:仓库的集合,把多个仓库的依赖都整合到一个大的集合中来;用来合并多个hosted/proxy仓库,当你的项目希望在多个repository使用资源时就不需要多次引用了,只需要引用一个group即可。
安装好Nexus后,系统会预先自带几个仓库:如图:
下面说说,另外三种仓库的作用:
1.Releases: 这里存放我们自己项目中发布的构建,通常是Release版本的,已经正式发布的。
2.Snapshots:存放临时的依赖,非最终版本、非稳定版本的依赖,比如你正在开发的starter,你的同事需要引用里面的类,就可以发布到这个类型的仓库中。
3.3rd Party:存放第三方的依赖。
安装nexus
下载之后直接解压即可
启动nexus
切换到安装目录下的bin目录下的命令行
启动:./nexus start
关闭:./nexus stop
端口修改:端口可以在配置文件中修改 xxx/nexus-3.28.1-01/etc/nexus-default.properties
浏览器访问 \http://localhost:8081即是nexus登陆页面
登录
账户:admin
密码:查看 sonatype-work/nexus3/admin.password
基础操作
./nexus status 查看启动状态
./nexus stop 停止
./nexus restart重启
配置私服的镜像路径
获取资源的路径,配置仓库组,表示从仓库组中获取资源
在settings.xml 文件的 mirrors 内添加以下镜像地址
<mirror>
<id>maven-public</id>
<name>maven-public</name>
<mirrorOf>*</mirrorOf>
<url>http://localhost:8081/repository/maven-public/</url>
</mirror>
配置服务器信息
本地访问仓库的权限,用于上传资源
<!-- 服务器的账户密码配置-->
<servers>
<server>
<!-- id可以随便取 但是在pom中引用的时候需要保持一致-->
<id>maven_release</id>
<username>admin</username>
<password>admin</password>
</server>
<server>
<id>maven_snapshots</id>
<username>admin</username>
<password>admin</password>
</server>
<server>
<id>maven-central</id>
<username>admin</username>
<password>admin</password>
</server>
</servers>
配置当前项目访问私服上传资源保存位置(pom.xml)
<distributionManagement><!-- 远程部署管理信息 -->
<!-- 项目部署到私服配置 id和上面server中配置的id一致-->
<repository><!--部署项目产生的构件到远程仓库需要的信息 -->
<id>maven_release</id>
<name>maven-releases</name>
<url>http://localhost:8081/repository/maven-releases/</url>
</repository>
<snapshotRepository><!-- 如果没有配置该元素,默认部署到repository元素配置的仓库 -->
<id>maven_snapshots</id>
<name>maven-snapshots</name>
<url>http://localhost:8081/repository/maven-snapshots/</url>
</snapshotRepository>
</distributionManagement>
发补资源到私命令
mvn deploy