今天继续部署项目。昨天打包好的jar包我发现居然无法运行！
这时候我试了一下，在cmd中敲java或者java -version之类的，居然毫无反应。注意不是报错，是毫无反应。。。就这个破问题困扰了我一整个上午，我重装jdk两次，重写环境变量两次也没结果。不过冷静下来也确实，真要是环境变量写错了咋可能不报错嘞。。。
将系统环境变量中的C:\Program Files (x86)\Common Files\oracle\Java\javapath和C:\Program Files \Common Files\oracle\Java\javapath这两个自动配置的东西删除。然后重新运行命令发现一切正常了！截个图庆祝一下。。。
好了我们继续去看jar包能否在本地正常运行。在jar包当前文件夹下运行cmd后：
java -jar demo1-0.0.1-SNAPSHOT.jar //后面那是jar包名
本地成功运行。这名字太长了，我把-SNAPSHOT这玩意去掉了。继续使用Xshell利用Xftp将jar文件上传，我选择上传到/home/lxc文件夹下。
接下来要检测防火墙是否开启我们需要的端口（这里是8080）。
firewall-cmd --list-ports好嘛真干脆，人家说了防火墙未启动。。。先手动启动一下吧：
systemctl start firewalld.service //开启服务
systemctl enable firewalld.service //设置开机启动
然后：
systemctl status firewalld //检测防火墙状态下面是全过程的截图：
重新查看开启的端口。可以发现没有开启任何端口。那就开一下，命令如下：
firewall-cmd --zone=public --add-port=xxx/tcp --permanent
然后重启防火墙：
systemctl restart firewalld.service检查完毕后，输入跟本地运行一样的命令，可以发现项目跑起来了。我们打开浏览器，通过公网ip:端口号的方式发现可以访问得到！
这一步就结束了！
昨天下午跟老师确定了一下下一步的学习计划，要在这周内将之前的项目结合Vue3.0部署。对于Linux的学习，还需要了解之前跳过的权限更改。现在回头看一下。
首先是文件的属主和属组，这个光从名字就能知道区别就无须多言了。对于属主和属组可以进行修改，但是一般咱也用不到。
chown更改属主，也可同时更改属组:
chown -R 属主名 文件名 //更改属主
chown -R 属主名:属组名 文件名 //更改属主同时更改属组
chgrp更改属组:
chgrp -R 属组名 文件名 //更改属组接下来是更改文件的9个属性，是必须掌握的重点。在工作时可能遇到这种情况：无权操作此文件，此时就需要进行修改。这里用到的是chmod命令。
首先要明确，Linux文件一共有十位属性。第一位是d或l或者-，d是文件，l是链接，-是普通的东西。后9位对应的都是字母，而且每3位是一组。每组都由rwx构成，其中r代表可读，w代表可写，x则代表可执行。如果可读可写可执行，那就是rwx，可读可写不可执行则为rw-，其他以此类推。这里每三个一组一共分为三组，分别对应的是属主/属组/其他人三组身份。
在对文件的属性进行修改时，为了简便命令量，讲r定位4，w定为2，x定为1，这样可读可写可执行就是7，可读可写不可执行就是6，可以发现这是不可能重复的。因此可以举个例子：如果对于属主/属组/其他人三组均为可读可写可执行，那么就是777。因此修改文件属性的命令就显而易见了：
chmod 权限 文件名好了这次Linux学习到此结束了。根据计划，下面看一下Git commit的规范。
在工作时候，我们修改代码后push到远端之前，都会有一个信息填写，里面主要写的就是本次修改或者做了什么事情。这一部分是有规范要求的。
<type>(<scope>): <subject>
<body>
<footer>注意这三行中间需要用空格进行分割的。首先是标题行，必填，描述了主要的修改类型和内容。然后是主题内容，描述为什么修改，做了什么样的修改以及开发的思路。最后是页脚注释，放置Changes 或 Closed Issues。
type
commit 的类型：
feat: 新功能、新特性
fix: 修改 bug
perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改（例如分号修改）
test: 测试用例新增、修改
build: 影响项目构建或依赖项修改
revert: 恢复上一次提交
ci: 持续集成相关文件修改
chore: 其他修改（不在上述类型中的修改）
release: 发布新版本
workflow: 工作流相关文件修改scope
commit 影响的范围, 比如: route, component, utils, build...subject
commit 的概述body
commit 具体修改内容, 可以分为多行footer
一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接这里约定了一些提交规范：
每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个可选的作用域字段，以及一个必要的冒号（英文半角）和空格。
当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
当一个提交为应用修复了 bug 时，必须使用 fix 类型。
作用域字段可以跟随在类型字段后面。作用域必须是一个描述某部分代码的名词，并用圆括号包围，例如： fix(parser):
描述字段必须紧接在类型/作用域前缀的空格之后。描述指的是对代码变更的简短总结，例如： fix: array parsing issue when multiple spaces were contained in string.
在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
在正文结束的一个空行之后，可以编写一行或多行脚注。脚注必须包含关于提交的元信息，例如：关联的合并请求、Reviewer、破坏性变更，每条元信息一行。
破坏性变更必须标示在正文区域最开始处，或脚注区域中某一行的开始。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，后面紧跟冒号和空格。
在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如： BREAKING CHANGE: environment variables now take precedence over config files.
在提交说明中，可以使用 feat 和 fix 之外的类型。
工具的实现必须不区分大小写地解析构成约定式提交的信息单元，只有 BREAKING CHANGE 必须是大写的。
可以在类型/作用域前缀之后，: 之前，附加 ! 字符，以进一步提醒注意破坏性变更。当有 ! 前缀时，正文或脚注内必须包含 BREAKING CHANGE: description以上就是Git commit的内容，下面将进入Vue的学习。通过了解，选择使用的版本是Vue3.0，是2020年推出的版本，目前的教程还是很少的。
Vue是用来构建用户界面的渐进式框架，可以自底向上逐层应用。
明天正式进入Vue3.0学习吧，今天剩的时间太少了我得写点别的东西。
