MyBatis：Maven，Git（TortoiseGit）

1，Maven

Maven是一个非常优秀的项目管理工具，采用一种“约定优于配置（CoC）”的策略来管理项目。使用Maven不仅可以把源代码构建成可发布的项目（包括编译、打包、测试和分发），还可以生成报告、生成Web站点等。

1.1，下载和安装Maven

1，登录Apache官网上个的Maven站点（Maven – Download Apache Maven）下载Maven最新版本。

2，配置Maven的环境变量

• JAVA_HOME：该环境变量应指向JDK安装路径。
• M2_HOME：该环境变量应指向Maven安装路径（即压缩包解压目录）。

• 将%M2_HOME%\bin变量添加到Path下。

3，检验是否安装成功：在cmd中输入 mvn -v。 

1.2，设置Maven

设置Maven行为有两种方式：

• 全局方式：通过Maven安装目录下的conf/settings.xml文件进行设置。
• 当前用户方式：通过用户Home目录的.m2\目录下的settings.xml文件进行设置。

两种行为方式只是起作用的范围不同，他们都使用setting.xml作为配置文件，而且这两种方式中setting.xml文件允许定义的元素也是相同的。

通常来说，Maven允许设置如下参数：

• localRepository：该参数通过<localRepository.../>元素设置，该元素的内容是一个路径字符串，该路径用于设置Maven的本地资源库路径。如果用户不设置该参数，Maven本地资源库默认保存在用户Home目录的.m2/repository路径下。建议设置到其他路径下。（Maven构建项目所用的插件、第三方依赖库都被集中放在本地资源库中）
• interactiveMode：该参数通过<interactiveMode.../>元素设置。改参数设置Maven是否处于交互模式——如果将Maven设为交互模式，每当Maven需要用户输入时，Maven都会提示用户输入。如果将该参数设置为false，那么Maven将不会提示用户输入，而是“智能”地使用默认值。
• offline：该参数Maven是否处于离线状态。如果将该参数设置为false，每当Maven找不到插件、依赖库时，Maven总会尝试从网络上下载。
• proxies：该参数用于为Maven设置代理服务器。该参数可包含多个<proxy.../>，每个<proxy.../>设置一个代理服务器，包括代理服务器的ID、协议、代理服务器地址、代理服务器端口、用户名、密码等信息，Maven可通过代理服务器访问网络。
• mirrors：该参数用于设置一系列Maven远程资源库的镜像。有时候连接不上Maven的国外资源库时，可连接国内资源库。

<mirrors>
    <mirror>
        <id>alimaven</id>
        <mirrorOf>central</mirrorOf>
        <name>aliyun maven</name>
        <url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
    </mirror>
</mirrors>

1.3，pom.xml

pom.xml文件被称为项目对象模型描述文件，Maven使用项目对象模型的方式来管理项目。POM用于描述该项目是什么类型的、该项目的名称是什么、该项目的构建能否自定义，Maven使用pom.xml文件来描述项目对象模型。因此，pom.xml并不是简单的生成文件，而是项目对象模型描述文件。

只要将项目的源文件按照Maven要求的规范组织，并提供pom.xml文件，即使pom.xml只包含极少量的信息，开发者也依然可以使用Maven来编译项目、运行程序，甚至可以运行测试用例、打包项目，这是因为Maven采用了“约定优于配置”的原则，根据此原则，Maven的主要约定有如下几条：

• 源代码应该位于${basedir}/src/main/java路径下。
• 资源文件应该位于${basedir}/src/main/resources路径下。
• 测试代码应该位于${basedir}/src/test路径下。
• 编译生成的class文件应该位于${basedir}/target/classes路径下。

Maven的强大很大程度来自于它的“约定”，Maven预定义了一个固定生命周期，以及一组用于构建和装配软件的通用插件。如果开发者完全遵循这些约定，只需要将源代码放到正确的目录下，Maven即可处理剩下的事情。

使用“约定优先配置”原则的一个缺点是，用户可能觉得它们被迫使用一种固定的流程和方法，甚至对某些约定感到反感。不过不用担心，所有遵循“预定优先配置”原则的技术通常都会提供一种机制允许用户进行配置。

POM文件的元素

Maven使用pom.xml文件来描述项目对象模型，因此pom.xml文件可以包含大量元素用于描述该项目。pom.xml文件包含如下元素：

• <dependencies../>：该元素用于定义依赖关系。该元素可以包含0~N个<dependency.../>子元素，每个<dependency.../>子元素定义一个依赖关系。
• <dependcyManagement.../>：该元素用于定义依赖管理。
• <build.../>：该元素用于定义构建信息。
• <reporting.../>：该元素用于定义站点报告的相关信息。
• <licenses.../>：该元素用于定义该项目的License信息。
• <organization.../>：该元素指定该项目所属的组织信息。
• <developers.../>：该元素用于配置该项目的开发者信息。
• <contributors.../>：该元素用于配置该项目的贡献者信息。
• <issueManagement.../>：该元素用于定义该项目的bug跟踪系统。
• <mailingLists.../>：该元素用于定义该项目的邮件列表。
• <scm.../>：该元素指定该项目源代码管理工具，如CVS，SVN等。
• <repositories.../>：该元素用于定义远程资源仓库的位置。
• <pluginRepositorie.../>：该元素用于定义插件资源库的位置。
• <distributionManagement.../>：该元素用于部署管理。
• <profiles.../>：该元素指定根据环境调整构建配置。

1.4，Maven的生命周期

基本生命周期	核心阶段	描述
clean生命周期	pre-clean	在构建之前执行预清理。
	clean	执行清理：执行该命令会删除项目路径下的target文件，但是不会删除本地的maven仓库已经生成的jar文件。
	post-clean	最后清理
default生命周期	compile	编译项目：只编译选定的目标，不管之前是否已经编译过，会在你的项目路径下生成一个target目录，在该目录中包含一个classes文件夹，里面全是生成的class文件及字节码文件。
	test	单元测试
	package	项目打包：完成compile、test、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库。 实际效果：这个命令会在你的项目路径下一个target目录，并且拥有compile命令的功能进行编译，同时会在target目录下生成项目的jar/war文件。
	install	安装到本地仓库：compile、test、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库。 实际效果：该命令包含了package命令功能，不但会在项目路径下生成class文件和jar包，同时会在你的本地maven仓库生成jar文件，供其他项目使用（如果没有设置过maven本地仓库，一般在用户/.m2目录下。如果a项目依赖于b项目，那么install b项目时，会在本地仓库同时生成pom文件和jar文件，解决了上面打包package出错的问题）。
	deploy	部署到远程仓库：compile、test、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
site生命周期	pre-site	生成站点之前做验证
	site	生成站点
	post-site	生成站点之后做验证
	site-deploy	发布站点到远程服务器

package & install：如果a项目依赖于b项目，打包b项目时，只会打包到b项目下target下，编译a项目时就会报错，因为找不到所依赖的b项目，说明a项目在本地仓库是没有找到它所依赖的b项目，这时就用到install命令了。

build & compile：

• Compile：只编译选定的目标，不管之前是否已经编译过。
• Build：是对整个工程进行彻底的重新编译，而不管是否已经编译过。Build过程往往会生成发布包，这个具体要看对IDE的配置了，Build在实际中应用很少，因为开发时候基本上不用，发布生产时候一般都用ANT等工具来发布。Build因为要全部编译，还要执行打包等额外工 作，因此时间较长。

打包过程：

• clean+package（如果报错，很可能就是jar依赖的问题，一般此问题都出现在第一次打包的情况，直接使用下面方法）
• mvn clean install -Dmaven.test.skip=true -T 4：跳过测试执行。

1.5，其他概念

Maven坐标

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
</dependency>

POM需要为项目提供一个唯一标识，这个标识就被称为Maven坐标。Maven坐标由如下4个元素组成：

• groupId：该项目的开发者的标识名。
• artifactId：执行项目名。
• packaging：指定项目打包的类型。
• version：指定项目的版本。
• scope：依赖范围。

Maven资源库

第一次运行Maven时，Maven会自动从远程资源库下载许多文件，包括各种Maven插件，以及项目所依赖的库。实际上，初始的Maven工具非常小，这是因为Maven工具本身的功能非常有限，几乎所有的功能都是由Maven插件完成的。

Maven资源库用于保存Maven插件以及各种第三方框架。简单来说，Maven用到的插件、项目起来的各种JAR包，都会保存在资源库中。

• 本地资源库：Maven用到的所有插件、第三方框架都会被下载到本地资源库中。只有当本地资源库找不到时才会从远程下载。开发者可以通过Maven安装目录下的conf/settings.xml文件，或者用户Home目录下的.m2/setting.xml文件中的<localRepository.../>元素进行设置。
• 远程资源库：远程资源库通常由公司或团队进行集中维护。通过远程资源库，可以让全公司的项目使用相同的JAR包系统。
• 中央资源库（默认）：中央资源库由Maven官方维护，中央资源库包含了各种公开的Maven插件、第三方项目。几乎所有的开源项目都会选择中央资源库发布框架。

当Maven需要使用某个插件或JAR包时，Maven的搜索顺序为：本地资源库，远程资源库，中央资源库。当Maven从中央资源库下载了某个插件或JAR包时，Maven都会自动在本地资源库中保存它们，只有当Maven第一次使用某个插件或JAR包时，才需要通过网络下载。

依赖管理

在pom.xml中的<dependencies.../>元素内增加<dependency.../>元素——每个<dependency.../>元素定义了一个依赖框架或者依赖库。

<dependency.../>元素可接受如下子元素：

• <groupId.../>：指定依赖框架或依赖类库所属的组织ID。
• <artifactId.../>：指定依赖框架或依赖库的项目名。
• <version.../>：指定依赖框架或依赖库的版本号。
• <scope.../>：指定依赖库起作用的范围。该子元素可接受compile、provided、test、system、runtime、import等值。
• <type.../>：指定依赖框架或依赖库的类型，该元素的默认值是jar。另外，还可以指定war、ejb-client、test-jar等值。
• <optional.../>：指定该依赖库是否为可选的。
• <classifier.../>：指定JDK版本号，如jdk14,jdk15等，指定被依赖的JAR包是在JDK哪个版本下编译的。
• <exclusions.../>：用于排除依赖。

<scope.../>元素用于指定依赖库起作用的范围。该元素可指定如下值：

• compile：默认的范围，编译、测试、打包时需要。
• provided：表示容器会在运行时提供。
• runtime：表示编译时不需要，但测试和运行时需要，最终打包时会包含进来。
• test：只用于测试阶段。
• system：与provided类似，但要求该JAR是系统自带的。
• import：继承父POM文件中dependencyManagement配置的依赖，import范围只能在dependencyManagement元素中使用。

关于Maven的依赖配置，需要说明的是，Maven依赖管理具有传递性，比如配置文件设置了项目依赖a.jar，而a.jar又依赖b.jar，那么该项目无须显示声明依赖b.jar，Maven会自动管理这种依赖的传递。

1.6，IDEA搭建Maven项目

1，创建Maven项目并使用archetype插件。

2，输入项目基本信息

3，指定Maven使用内部元数据

archetypeCatalog表示插件使用的archetype元数据，不加这个参数时默认为remote，local，即中央仓库archetype元数据，由于中央仓库的archetype太多了，所以导致很慢，指定internal来表示仅使用内部元数据。

4，添加指定的目录

 

1.7，创建项目恢复默认Maven设置

如果遇到新建项目恢复默认的Maven设置，可以在File-New Projects Settings-Settings for NewProjects设置。

1.8，Maven生成项目脚手架

脚手架：脚手架是一种提供项目基础结构和通用功能的工具。它能快速搭建起一个项目的框架，包括文件结构、目录和模块等，使开发者能够专注于业务逻辑而不必从头开始构建一个完整的项目。脚手架通常用于创建Web应用程序、移动应用程序和其他类型的软件项目。它们提供一些默认的工程代码，包括配置文件、依赖管理、编译和构建配置等。

使用脚手架的好处包括：

• 快速启动项目：脚手架提供了一个可用的项目框架，可以立即开始编写代码，而不需要自己手动设置项目结构。
• 标准化项目结构：通过使用脚手架，所有项目都将具有相似的结构，使团队成员之间的协作和交接更加容易。
• 提供最佳实践：脚手架通常会集成最佳实践，例如代码规范、自动化测试和部署配置等，使项目更加健壮且易于维护。

Maven Archetype：Maven Archetype插件是Maven的一个重要插件，它的作用是通过定义和配置项目模板，快速生成和初始化新项目的基础结构。相比手动创建项目，使用Archetype插件可以大大提高开发效率。

【Maven生成项目脚手架Demo】

• 创建项目：

.
├── example-client
│   ├── pom.xml
│   └── src
├── example-server
│   ├── pom.xml
│   └── src
├── example-test
│   ├── pom.xml
│   └── src
└── pom.xml

• 要在Maven中配置Archetype插件，需要在项目的pom.xml文件中做如下配置：

<build>  
    <pluginManagement>  
        <plugins>  
            <plugin>  
                <groupId>org.apache.maven.plugins</groupId>  
                <artifactId>maven-archetype-plugin</artifactId>  
                <version>3.0.1</version>  
            </plugin>  
            <plugin>  
                <groupId>org.apache.maven.plugins</groupId>  
                <artifactId>maven-compiler-plugin</artifactId>  
                <version>3.6.1</version>
                <configuration>  
                    <source>1.8</source>  
                    <target>1.8</target>  
                </configuration>  
            </plugin>  
            <plugin>  
                <groupId>org.apache.maven.plugins</groupId>  
                <artifactId>maven-resources-plugin</artifactId>  
                <version>3.0.2</version>
                <configuration>  
                    <encoding>UTF-8</encoding>  
                </configuration>  
            </plugin>  
        </plugins>  
    </pluginManagement>  
</build>

• 在根目录执行：mvn archetype:create-from-project

• 在target目录执行：mvn install

cd target/generated-sources/archetype/
mvn install

• 创建脚手架项目：mvn archetype:generate

mvn archetype:generate -DarchetypeCatalog=local

2，Git

SVN是一个广泛使用的版本控制系统，但SVN的主要弱点在于：它必须时刻连着服务器，一旦断开网络，SVN就无法正常工作。

SVN和Git相比，两者的本质区别在于：SVN是集中式的版本控制系统，而Git是分布式版本控制系统。

• SVN的版本库是集中存放在中央服务器上的，每个开发者工作时，都必须先从中央服务器同步最新的代码（下载最新的版本），然后开始修改，修改完了再提交给服务器。
• Git是分布式版本控制。对于Git而言，每个开发者的本地磁盘上都存放着一份完整的版本库，因此开发者工作时无须联网，直接使用本地版本库即可。只有需要多人相互协作时，才通过“中央服务器”进行管理。

简单来说，相对于SVN：Git的改变相当于让每个开发者都在本地“缓存”了一份完整的资源库，因此开发者对自己开发的项目文件执行添加、删除、返回之前版本时不需要通过服务器来完成。

在使用 Git 进行管理的项目中，不同状态的文件分别对应着不同的保存位置。Git保存文件的位置包括：Git仓库、暂存区以及工作区。其中，Git仓库又分为远程仓库和本地仓库。

• 远程仓库：远程仓库是指项目组共同维护的、托管在网络服务器上的项目仓库。
• 本地仓库：即远程仓库在本地的副本。开发者在开发之前必须要建立本地仓库，在开发过程中还需要基于本地仓库对代码进行修改和维护。
• 暂存区：用户修改的项目文件，在提交至本地仓库前的暂存区域。
• 工作区：用户实际编码的本地项目目录。

2.1，Git下载和安装

1，访问官网（Git），下载最新稳定版本。

2，下载后得到一个Git-2.31.1-64-bit.exe的文件。

3，双击，安装Gti。

4，将git添加到Windows命令行窗口；出于安全考虑，不需要将Unix工具添加到Windows命令行窗口。

5，选择默认的OpenSSH工具，默认的SSH库。

6，一路默认到安装成功，检验是否安装成功。

cmd模式下，输入git --version命令。

2.2，Git操作

【merge & rebase】

• Merge（合并）：在合并分支时，Git会创建一个新的合并提交，将两个分支的历史合并在一起。这个新的合并提交有两个（或更多）父提交，分别代表要合并的两个分支。这种方法保留了每个分支的完整历史，并且是一种非破坏性的合并。

# 切换到目标分支
git checkout target_branch
# 执行合并
git merge source_branch

• Rebase（变基）：Rebase是将一个分支的修改应用到另一个分支上的一种方式。它会将当前分支的修改“移动”到目标分支的最新提交之后。这样看起来就像是目标分支上连续的一系列提交，而不是两个分支的独立历史。Rebase改写了提交的历史，因此要小心在公共分支上使用，以免影响其他开发者。

# 切换到目标分支
git checkout target_branch
# 执行变基
git rebase source_branch

使用merge保留历史，是比较安全的方法，特别是对于公共分支。使用rebase可以帮助保持清晰的提交历史，但要小心在共享分支上使用，以免引起混乱。

3，TortoiseGit

3.1，TortoiseGit下载安装

1，登录TortoiseGit官网（Download – TortoiseGit – Windows Shell Interface to Git），下载TortoiseGit最新版本。

2，启动安装程序，除了安装目录一路默认，这样就装好了，鼠标右键就可看到了。

3，切换语言（不推荐），先下载语言包，直接运行安装。

 

PS：考虑到软件开发者的工作环境（大部分人用英文，甚至与国外开发者协作开发），因此推荐保持英文界面。 

3.2，配置SSH key

生成SSH key

将ssh-rsa复制到github的ssh key中

存储私钥

配置账户和ssh key

3.3，创建本地资源库

1，选择需要版本管理的工作目录，然后在该目录下鼠标右键，单击“Git Create repository here...”。

2，弹出的对话框有一个”Make it Bare“复选框，如果勾选该复选框，则意味着该目录初始化为”纯版本库“，因此此处不要勾选该复选框。

3，对资源库进行一些初步配置。在资源库目录的空白处单击鼠标右键，打开“TortoiseGit——Setting”菜单项。

• General：该分类主要用于设置界面语言、字体、字体大小、颜色等通用信息。
• Git：该分类主要用于设置Git本身的相关信息。
• DiffViewer：该分类用于设置Diff文件比较器的比较页面。
• TortiseGitUDiff：该分类用于设置TortoiseGitUDiff文件比较器的比较页面。

此处主要设置Git相关属性，因此选中Git节点。输入Name、E-mail、Signing key信息，这些信息将作为用户提交代码的标识（就是告诉Git谁在提交代码）。

图中对话框上方的Local单选按钮，表明为当前项目设置Git的范围。当局部信息和全局信息不一致时，局部信息取胜。如果Global选项和Local选项下输入的用户信息不一致，则选中Effective单选按钮，即可查看到实际生效的是Local选项下输入的用户信息。

3.4，添加文件和文件夹

Git添加文件很简单，先把文件和文件夹添加到Git系统管理之下，然后提交修改即可。添加操作相当于git add命令。

3.5，提交修改

添加文件或文件夹之后，还需要执行提交操作才能真正将修改提交到版本库中。实际上，Git的操作总是按“操作—提交”模式执行的，此处操作包括添加文件、修改、删除等。

创建本地资源库之后，Git在资源库下创建一个.git文件夹，该文件被称为Git版本控制库（用于记录各文件的修改历史）。Git版本库中存了很多东西，其中包括名为stage（index）的暂存区。

开发者对文件所做的各种操作（比如添加、删除、修改等），都只保存在stage暂存区中，只有等到执行提交时才会将暂存区中的批量修改提交到指定分支。在创建Git本地资源库时，Git会自动创建唯一的master分支。

3.6，查看文件或文件夹的版本变更 

通过TortoiseGit也可查看文件或文件夹的版本变更历史，并比较两个版本之间的差异。查看文件或文件夹的历史非常简单，在文件夹点击鼠标右键，选择“TortoiseGit—Show log”菜单项，即可查看。

Git会集中管理整个项目的版本变更。我们在窗口上方选择某个提交信息，在窗口中间可以看到本次提交的唯一标识和说明信息；在窗口下方可以看到本次提交涉及的文件。

3.7，删除文件或文件夹

删除文件或文件夹操作同样可按“删除—提交”模式执行。通过TortoiseGit删除指定的文件或文件夹非常简单，按如下步骤执行即可：

• 通过资源管理器删除指定文件或文件夹。
• 在资源库的空白处单击鼠标右键，在弹出的快捷菜单中单击“TortoiseGit—Commit”菜单项，提交修改即可。

删除文件或文件夹后必须执行提交操作；否则，在本地所做的删除操作不会提交到服务器，提交修改同样可使用git commit命令来完成。

3.8，从以前版本重新开始

使用版本管理工具的最大好处在于：开发者可以随时返回以前的某个版本。如果在开发过程中把某个文件改坏了，希望重新找回该文件以前的的某个版本，或者想从前面的某个阶段重新开始，TortoiseGit都提供了方便的操作允许“重返”以前的某个版本。

Git支持如下三种重设类型：

• Soft：软重设，只将指定分支重设到指定版本，不改变当前工作空间和stage暂存区。
• Mixed：混合，将指定分支重设到指定版本，将stage暂存区也重设到指定版本，但不改变工作空间。
• Hard：将指定分支、stage暂存区、工作空间全部重设到指定版本

如果只想让单个文件恢复到指定版本，则可以直接选择文件操作。

3.9，克隆项目

克隆项目就是将所选资源库当前分支的所有内容复制到新的工作空间下。如果当前分支不是master主分支，而是其他分支，那么克隆操作自然是复制其他分支的内容。

进入打算克隆项目的文件夹，在该文件夹单击鼠标右键，在弹出的快捷菜单单击“Git Clone”菜单项。

3.10，创建分支

有些时候不想继续沿着开发主线开发，而是希望试探性地添加一些新功能，这时候就需要在原来的开发主线上创建一个分支（Brancn），进而在分支上进行开发，避免损坏原有的稳定版本。

创建分支的步骤如下：在项目所在工作空间的空白处单击鼠标右键，在弹出的快捷菜单中单击“TortoiseGit—Create Branch”菜单项，系统弹出对话框。

3.11，切换分支

为了沿着分支进行开发，需要先切换到分支所在的版本。

3.12，合并分支

当项目沿着分支探索性开发新功能达到一定的稳定状态之后，还可以将分支和master分支进行合并，从而将分支中的新功能添加到master主分支中。