Maven&Git

典型回答 在Git中，merge和rebase是两种不同的代码合并策略，它们用于将一个分支的更改合并到另一个分支。它们的主要区别在于合并的方式和提交历史的表现上 在介绍区别之前，我们先看下当我们从主干（Main）创建了一个新的分支（Feature）开始开发代码时，然后另外有人把自己的代码提交到主干（Main）之后，就会产生分叉的提交记录。 这时候你想把你的代码也提交到主干中，就有两个选择了：merge(合并)，rebase(变基) merge 1 2 git checkout feature git merge main 1 git merge feature main 以上两种都是把一个主干(main)的最新代码合并(merge)到分支(featrue)的方式。 这个操作会在分支中创建一个新的“merge commit”，它将两个分支的更改合并到一个新的提交中。 如上图，就是我们把Main中的新提交Merge到我们的Feature分支中。 rebase 作为merge的替代方法，您可以使用以下命令将功能分支重新设置为主分支： 1 2 git checkout main git rebase feature 这会将整个main移动到feature分支的顶端，从而有效地将所有新提交合并到 feature 中。但是，rebase不是使用merge commit，而是通过为原始分支中的每个提交创建全新的提交来重写项目历史记录。 如上图，就是我们将Main中新的提交，通过rebase的方式合并到我们的Feature分支中。 总结下区别 当我们想要把一个分支合并到主干的时候，merge操作会通过merge commit的方式在主干上新建一个节点，并一次性的把分支中的修改合并到主干中。它的优点是分支代码合并后不破坏原分支的代码提交记录，缺点就是会产生额外的提交记录并进行两条分支的合并。 而rebase操作，不会在主干上新建节点，而是把分支上的所有历史提交都合并到主干中，形成一个完成的线性提交记录。他的优点是无须新增提交记录到目标分支，rebase后可以将对象分支的提交历史续上目标分支上，形成线性提交历史记录，进行review的时候更加直观。 所以，merge rebase可以保留完整的历史提交记录。 当你想要保留原始分支的提交历史，并且不介意在合并中产生额外的合并提交时，可以使用merge。在多人协作或公共分支上，merge是一个更安全和常见的选择，因为它保留了每个开发者的提交历史，易于跟踪和回溯。 当你想要保持提交历史的整洁、线性，并且愿意改写提交历史时，可以使用rebase。在个人开发分支上，为了保持提交历史的简洁和易于阅读，rebase用的更多。 一般来说，在公司内部做团队开发，使用merge的情况会更多一些，我在工作中基本上90%的时间都是使用merge的 扩展知识 不建议在公共分支做rebase 一般来说，我们在工作中的开发模式都是基于分支开发，基于主干发布的模式。什么意思呢？ 就是仓库中有一份主干的代码，线上运行的就是这套代码，当我们有需求要开发的时候，不会直接在主干上开发，而是基于主干拉一个分支出来，在分支中进行开发，开发好之后，再把这个分支的代码通过发布的方式合并到主干中。 在业内有一个rebase黄金法则：不要对已经提交到共享仓库（如远程仓库）的提交执行 rebase。 为什么要遵守这个黄金法则呢？ rebase会将所有的Main分支上的提交移动到Feature分支的顶端，问题是这个操作只发生在你自己的本地仓库中，所有的其他开发者是完全不感知的，因为他们是使用旧的Main分支创建的分支。 这时候如果我们的Feature变更被推送到远程仓库后，其他人的Feature想要在提交的时候，就会产生大量的冲突。 所以，在多人协作中，应该遵循以下指导原则： 在个人开发分支上进行 rebase：如果你在个人开发分支上进行 rebase，这不会对其他开发者产生影响，因为这个分支只属于你个人。 在共享仓库的主分支上使用 merge：在共享仓库的主分支（如 master 或 main）上，推荐使用 merge 来将开发的功能或修复合并回主分支。这样可以保留每个开发者的提交历史，易于跟踪和回溯。 协作时协商：如果有特殊情况需要在共享仓库的分支上进行 rebase，应该与其他开发者进行充分协商，并确保大家都知道并同意这个变更。

典型回答 Git和SVN都是版本控制系统，它们都是用来帮助团队协同开发，管理代码版本的。但是，Git和SVN在实现方式、使用方法、特性等方面都存在一些差异。 分布式 vs 集中式 这是二者之间最大的区别。 Git是分布式版本控制系统，每个开发者本地都有一份完整的代码仓库，可以离线工作、本地提交、本地回滚等操作，不依赖于中央服务器。而SVN是集中式版本控制系统，开发者需要从中央仓库中获取代码，并将更改提交到中央仓库中。 版本号 vs 版本序号 Git使用SHA-1散列值作为每个提交的唯一标识，可以看作是一个版本号。SVN使用版本序号来标识每个提交。 分支管理灵活 Git在分支管理方面表现出色。Git可以轻松地创建、合并、删除分支，支持多个分支并行开发，并提供了一些高级分支管理工具，如rebase、cherry-pick等。而SVN在分支管理方面不如Git灵活。 内部实现 Git和SVN在内部实现上也存在差异。Git使用一种名为“快照”的方式存储版本信息，每次提交都会生成一个快照。而SVN使用一种名为“增量式差异”的方式存储版本信息，每个版本只存储与上一个版本的差异。 大小限制 Git可以处理非常大的代码仓库，因为每个开发者都有一份完整的仓库，不需要集中式仓库的所有数据。而SVN受到服务器性能和带宽的限制，对于非常大的仓库可能会出现性能问题。

典型回答 在使用Maven进行项目构建的应用中，如果在应用运行期发生了NoSuchMethodError、ClassNotFoundException等异常或者错误时，需要考虑Jar包冲突的问题。 如果在应用中，我们同时依赖了两个第三方的jar包A，B，而A，B中又都依赖了C包，但是依赖的C的版本不同，那么就可能发生jar包冲突，导致最终编译打包后，应用的classpath中只有一个C的jar包。 那么，因为maven有一定的Jar包依赖传递原则，所以有可能他最终选择的jar包并不是我们真正想用的 ，那这时候怎么办呢？就需要我们手动的进行依赖仲裁，通过人工干预的方式来保留我们需要的jar包。 扩展知识 依赖传递 几乎所有的Jar包冲突都和依赖传递原则有关，所以我们先说Maven中的依赖传递原则，主要由以下两个默认的原则： 最短路径优先原则 假如引入了2个Jar包A和B，都传递依赖了Z这个Jar包： A -> X -> Y -> Z(2.5) B -> X -> Z(2.0) 那其实最终生效的是Z(2.0)这个版本。因为他的路径更加短。 最先声明优先原则 如果路径长短一样，优先选最先声明的那个。 A -> Z(3.0) B -> Z(2.5) 这里A最先声明，所以传递过来的Z选择用3.0版本的。 显然这种默认的原则并不一定能使我们一定能获得自己真正想用的jar包，那么就需要人工仲裁了。 ...

典型回答 如果没有maven，我们在开发一个应用的时候，需要自己先确定需要引入哪些第三方的jar包，并且要去找到这些jar包，把他们导入到项目中，而且最痛苦的时候各个jar包之间的兼容性和冲突的问题。 jar包弄好了之后，我们想要把应用打包整一个war包又很麻烦，将一个应用做编译、测试和部署都特别麻烦。 而有了maven之后，这些问题都能迎刃而解了。 Maven就是专门为Java项目打造的管理和构建工具，它的主要功能有： 提供了一套依赖管理机制（jar包导入、冲突解决） 提供了一套标准化的构建流程（编译，测试，打包，发布……）； 提供了一套标准化的项目结构；

典型回答 Git的代码回滚考察的是纯纯的实操了，根据代码所在的位置不同，回滚的方式也不一样。 一般一个文件要经历几个过程： 本地文件修改 -> commit到分支上 -> push到仓库中 首先，说本地文件修改，如果你只是想撤销本地文件的修改并恢复到上一次提交时的状态，可以使用**git checkout**命令。例如，如果你想撤销对文件example.txt的修改，可以运行以下命令：git checkout example.txt。 如果你的代码本地修改后，使用了git** commit或者push提交到了分支上**，想要撤销这一次的提交的话，那么可以使用**git revert**和**git reset**命令。 例如，如果你想撤销指定的某一次提交，如这次提交的hash值是abcdefg，可以运行以下命令：git revert abcdefg或者 git reset --hard abcdefg。 扩展知识 revert和reset的区别 revert和reset都能用来回退git的提交，那么他们的区别是什么呢？ reset的回退比较暴力，是彻底回退到指定的版本。并且执行的本次reset动作也没有产生记录，就像一切都没有发生过一样，如果使用–hard的话，还会把这次提交之后的所有其他提交也都一并清除。 而revert是仅仅撤销指定的那一次修改，对于这次commit之后的commit其实是没有影响的。使用 revert会保留更改历史记录，并且可以反复使用以前的更改。每个撤消提交都会添加到历史记录中，并且必须将其合并到目标分支中。 reset 的三种模式 reset命令有三种模式，分别是soft、mixed和hard。 –soft 模式会重置指针，但不会修改工作目录或索引。这意味着之前的更改仍然存在于工作区中，并且可以重新提交。 –mixed 模式是默认模式，它重置指针并更新索引以匹配指定的提交。这将取消索引中的所有更改，但工作目录中的更改将保留。 –hard 模式会重置指针，索引和工作区。这意味着所有更改都将永久删除，并且没有办法撤销或恢复这些更改。

典型回答 JAR（Java Archive）和WAR（Web Archive）是Java中常见的两种打包文件格式。 **JAR包是一种用于打包Java类和相关资源的归档文件格式。**通常情况下，JAR包用于将一组相关的Java类（.class文件）和资源（文本文件，图片等）打包在一起，方便进行分发和部署。 通常JAR包用于在Java应用中引入其他的库文件，也可以作为Java应用程序的可执行文件运行。 1 java -jar path/to/mytest.jar 以上就是运行一个jar文件的方式。 **WAR包是一种用于打包Web应用程序的归档文件格式。**它通常包含Web应用程序的所有文件和资源，如JSP文件、HTML文件、JavaScript文件、CSS文件、Java类文件、配置文件等等。 WAR包是将Web应用程序打包和部署的标准方式（通常包含一个WEB-INF目录，其中包括了web.xml，以及类文件、库和资源文件），我们可以方便地将Web应用程序部署到Web容器中，如Tomcat、Jetty等。WAR包还可以包含Web应用程序的依赖库和其他资源文件。 扩展知识 除了常见的jar包和war包以外，Java开发者还会接触到其他的类型，如EAR包、SAR包以及APK包。 EAR包 EAR（Enterprise Archive）包是一种用于打包Java EE的归档文件格式。EAR包包含多个模块，如EJB模块、WAR模块、JAR模块等等。EAR包是一种高级别的打包格式，用于将多个应用程序打包在一起，并在Java EE服务器上进行部署。 SAR包 SAR（Service Archive）包通常用于将Java EE应用程序部署在JBoss应用服务器上。JBoss应用服务器提供了一种基于SAR包的服务部署机制，可以方便地将Java EE应用程序部署为服务，并对服务进行管理、监控和控制。其他一些应用服务器也支持SAR包的部署方式，如WebLogic、WebSphere等。SAR包中包含了Java EE服务的所有组件，如EJB、JMS、JCA等等。SAR包还包含了服务的描述文件和配置文件，如jboss-service.xml和jboss-app.xml等。 APK包 APK（Android Package）包是一种用于打包Android应用程序的归档文件格式。APK包包含Android应用程序的所有资源文件、代码文件、配置文件、库文件等等。APK包是Android平台上应用程序的标准打包格式，可以在Android设备上进行安装和部署。

典型回答 Fat JAR（也称为uber-jar）是一种包含所有依赖项的 JAR 文件，这些依赖项通常需要在运行时加载。Fat JAR 的存在是因为在传统的 Java 开发中，通常需要将多个 JAR 文件打包到一个应用程序中。但是，在部署和维护应用程序时，需要管理所有这些 JAR 文件以及它们的依赖关系，这是一项繁琐的任务。Fat JAR 解决了这个问题，将所有的依赖项打包到一个 JAR 文件中，这样可以方便地部署和维护应用程序。 Fat JAR 发生的原因通常是在使用构建工具（例如 Maven 或 Gradle）构建应用程序时，将所有依赖项打包到一个 JAR 文件中。这通常是通过配置构建脚本中的插件来完成的，这些插件负责将所有依赖项复制到单个 JAR 文件中。 在 Spring Boot 中，使用 Maven 或 Gradle 构建项目时，默认会生成一个包含所有依赖项的 fat jar。这种做法简化了应用的部署和运行，但也会导致 jar 文件过大，不利于网络传输和存储。 为了解决这个问题，可以采取以下几种方式： 优化依赖管理：移除不必要的依赖，避免冗余依赖。 使用外部依赖管理工具：将依赖项存储在独立的仓库中，通过类似 Docker 的方式进行部署和管理。 拆分 fat jar：将应用程序和依赖项分开打包，避免单个 jar 文件过大，可以方便地进行部署和更新。 扩展知识 SpringBoot如何加载fat jar ✅SpringBoot和传统的双亲委派有什么不一样吗？