1.dependencyManagement
- 在该元素下声明的依赖不会实际引入到模块中，只有在 dependencies 元素下同样声明了该依赖，才会引入到模块中。该元素能够约束 dependencies 下依赖的使用
- 即 dependencies 声明的依赖若未指定版本，则使用 dependencyManagement 中指定的版本，否则将覆盖 dependencyManager 中的版本
- dependencyManager 可以传递给子模块，所以在子模块中可以引用父模块 dependencyManagement 定义好的依赖
<!--在dependencyManagement 声明的依赖不会实际引入到模块中 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>2.7.5</version>
</dependency>
</dependencies>
</dependencyManagement>如果需要使用该依赖，则应该在 dependencies 中重新声明该依赖
代码语言：xml复制<!--如果需要使用,在dependencies中声明该依赖,无须指定版本-->
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>如果是在子类中，需要先引入父模块，再引用依赖
代码语言：xml复制<!--引入父模块, parent标签可以理解为java中的继承关系-->
<parent>
<groupId>父类 groupId</groupId>
<artifactId>父类 artifactId</artifactId>
<version>父类 version</version>
</parent>
<!--如果需要使用,在dependencies中声明该依赖,无须指定版本-->
<dependencies>
<dependency>
<!--如果指定了版本号,则会覆盖父模块 dependencyManagement 定义的版本(不建议这
做,dependencyManagement的作用本来就是用来统一版本,防止依赖冲突)-->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>使用 dependencyManagement 可以统一声明依赖版本，进行集中管理，避免依赖冲突
2.distributionManagement
distributionManagement 的作用是"分发构件至远程仓库":
mvn install 会将项目生成的构件安装到本地 Maven 仓库，mvn deploy 用来将项目生成的构件分发到远程 Maven 仓库。本地 Maven 仓库的构件只能供当前用户使用，在分发到远程 Maven 仓库之后，所有能访问该仓库的用户都能使用你的构件。
我们需要配置 POM 的 distributionManagement 来指定 Maven 分发构件的位置。给出 Maven 部署当前项目的构件到远程库时，关于远程库的配置。
代码语言：xml复制<distributionManagement>
<repository>
<id>随便起</id>
<url>你自己maven环境下setting文件里面的私有库</url>
</repository>
<snapshotRepository>
<id>随便起t</id>
<url>你自己maven环境下setting文件里面的快照库</url>
</snapshotRepository>
</distributionManagement>3.使用总结
- modules 中的 module 标签顺序，随意放置就好，不用按照子模块依赖顺序来设置，maven 会自动按照依赖顺序为你打包
- modules 中的 module 标签作用：modules 只能在模块的打包方式是 pom 的时候才能使用，比如 packaging 设置为 pom，modeule 标签中的名称是其他模块 artifactId 名称，无论该模块是否打包方式为 pom 模块的子模块，都是可以的；在对父模块进行 mvn clean install 的时候，所有在 module 标签中的模块都会自动按照模块之间的依赖顺序进行 mvn clean install
- 当我们从 maven 私服中下载子模块 jar 包的时候，该子模块 jar 包会去寻找用到的父模块 jar 包，主要目的是确定用到依赖的版本，所以我们把子模块 jar 包发布到 maven 仓库的时候，也一定要同步把父模块 jar 包发布到 maven 仓库，这样在下载子模块的时候才不会报错
- 发布打包方式为 pom 的父模块到 maven 仓库的时候，我们可以删除父模块的 module 标签吗，我认为是可以的，因为 module 标签的作用在上面 2 中已经说明了，所以它只和打包方式为 pom 的模块进行 mvn clean install 的时候有关，也就是说只和开发的时候 mvn clean install 有关，和其他的地方没啥关系
Git 是一个开源的分布式版本控制系统，由 Linus Torvalds 创建，用于有效、高速地处理从小到大的项目版本管理。Git 是目前世界上最流行的版本控制系统之一，广泛应用于软件开发中。
以下是 Git 的一些核心概念和功能：
- 分布式版本控制：与集中式版本控制系统（如 SVN）不同，Git 允许每个开发者拥有完整的代码库副本，包括完整的历史记录。
- 分支（Branching）：Git 支持快速创建和合并分支。分支是指向代码库中特定提交的可移动指针。
- 合并（Merging）：合并是将两个或多个开发历史合并在一起的过程。
- 标签（Tagging）：用于标记特定的提交，通常用于版本发布。
- 暂存区（Staging Area）：也称为索引，是准备下一次提交的文件列表。
- 提交（Commit）：保存项目历史和文件快照的记录。
- 远程仓库（Remote Repositories）：可以是服务器上的仓库，用于与他人共享代码。
- 克隆（Cloning）：从远程仓库复制代码库到本地。
- 拉取（Pull）：从远程仓库拉取最新的代码并合并到本地。
- 推送（Push）：将本地的提交推送到远程仓库。
- 拉取请求（Pull Requests）：在分布式开发环境中，用于请求将你的更改合并到主分支。
- 分支策略：Git 支持多种分支策略，如 Git Flow、GitHub Flow 等。
- 钩子（Hooks）：Git 允许在特定事件发生时执行脚本，如提交前、推送前等。
- 子模块（Submodules）：允许将一个 Git 仓库作为另一个 Git 仓库的子目录。
- 工作流：Git 支持多种工作流，如集中式工作流、功能分支工作流等。
Git 的命令行工具非常强大，但同时也有图形用户界面（GUI）客户端，如 GitHub Desktop、SourceTree、GitKraken 等，使得非技术用户也能轻松使用 Git。
Git 通常与 GitHub、GitLab 或 Bitbucket 等在线托管服务一起使用，这些服务提供了额外的功能，如代码审查、持续集成/持续部署（CI/CD）、项目管理工具等。
