http://wiki.jikexueyuan.com/project/intellij-idea-tutorial/make-introduce.html
编译方式介绍
Compile：对选定的目标（Java 类文件），进行强制性编译，不管目标是否是被修改过。注：2018版操作为Recompile。
Rebuild：对选定的目标（Project），进行强制性编译，不管目标是否是被修改过，由于 Rebuild 的目标只有 Project，所以 Rebuild 每次花的时间会比较长。
Make：使用最多的编译操作。对选定的目标（Project 或 Module）进行编译，但只编译有修改过的文件，没有修改过的文件不会编译，这样平时开发大型项目才不会浪费时间在编译过程中。注：2018版操作为Build。
目录或文件夹的排除
如图标注 1 所示，可以添加目录 或 文件进行编译排除。
在项目中，如果有任何一个可编译的文件无法编译通过，则 IntelliJ IDEA 是无法运行起来的，必须等你全部问题解决，编译通过之后才可运行。但是可能开发过程中，某一个包目录的文件编译无法通过，但是我们又不急着改，那我们就可以考虑把该包加入到排除编译列表中，则项目就可以运行起来。
- 用来排除特定的路径，暂时不修改其中的bug.
IntelliJ IDEA 项目相关的几个重要概念介绍
project 和 module
在 IntelliJ IDEA 中 Project 是最顶级的级别，次级别是 Module。一个 Project 可以有多个 Module。目前主流的大型项目结构都是类似这种多 Module 结构，这类项目一般是这样划分的，比如：core Module、web Module、plugin Module、solr Module 等等，模块之间彼此可以相互依赖。通过这些 Module 的命名也可以看出，他们之间应该都是处于同一个项目业务情况下的模块，彼此之间是有不可分割的业务关系的。
所以我们现在总结：一个 Project 是由一个或多个 Module 组成，模块之间尽量是处在同一个项目业务的的情况下，彼此之间互相依赖关联。这里用的是 尽量，因为 IntelliJ IDEA 的 Project 是一个没有具备任何编码设置、构建等开发功能的，主要起到一个项目定义、范围约束、规范等类型的效果，也许我们可以简单地理解为就是一个单纯的目录，只是这个目录命名上必须有其代表性的意义。
project-根目录，单纯的目录起到项目定义、范围约束、规范类型的效果
module -次级目录 具体功能实现的模块
Hello World 项目创建与项目配置文件介绍
蓝色目录为 source root
-设置包下目录，让目录显示层级关系
如上图标注 1 所示，在没有文件的情况下包目录默认是连在一起的，这不方便看目录层级关系。
如上图标注 箭头 所示，点击此齿轮，在弹出的菜单中去掉选择标注 2 选项：Compact Empty Middle Packages。2
(compact-使简洁，使紧凑）
补充 编译方式
如上图标注 1 所示，Make 的操作有：Make Project、Make Module
如上图标注 2 所示，Compile 的操作有：Compile 指定类
如上图标注 3 所示，Rebuild 的操作有：Rebuild ProjectCompile：对选定的目标（Java 类文件），进行强制性编译，不管目标是否是被修改过。注：2018版操作为Recompile。
Rebuild：对选定的目标（Project），进行强制性编译，不管目标是否是被修改过，由于 Rebuild 的目标只有 Project，所以 Rebuild 每次花的时间会比较长。
Make：使用最多的编译操作。对选定的目标（Project 或 Module）进行编译，但只编译有修改过的文件，没有修改过的文件不会编译，这样平时开发大型项目才不会浪费时间在编译过程中。注：2018版操作为Build。
即：
1. Build,最常用，编译时对修改部分进行编译，其余部分不动
2. Recompile 对某个具体的类强制编译
3. Rebuild，对整个project强制编译，相当于全部重新编译，费时费力，时间最长。
项目配置文件介绍
如上图标注 1 所示，.idea 即为 Project 的配置文件目录。
如上图标注 2 所示，.iml 即为 Module 的配置文件。
通过上面的了解我们也知道 IntelliJ IDEA 项目的配置变动都是以这些 XML 文件的方式来表现的，所以我们也可以通过了解这些 XML 文件来了解 IntelliJ IDEA 的一些配置。也因为此特性，所以如果在项目协同中，我们要保证所有的项目配置一致，就可以考虑把这些配置文件上传到版本控制中（包括 .idea 目录和 .iml 文件）。如果把这些文件加入到版本控制之后，那又有一点是需要考虑的，那就是协同者 Checkout 项目下来之后，按自己的需求进行项目配置的之后，项目的 XML 文件也会跟着变化。此时协同者的这些变化的文件就不应该再上传到版本控制中。至于如何更好地控制这些不想随时提交的文件，在接下来的版本控制专讲中会进行详细讲解。
- .idea(.xml）文件为project的配置文件
- .iml为module的配置文件
- .idea为全局配置文件，在协同项目中，要保证版本控制一致，所以应该将.idea上传到版本控制当中。（后面版本控制上会详细讲解）
版本控制的使用
IntelliJ IDEA 下的版本控制介绍
很多人认为 IntelliJ IDEA 自带了 SVN 或是 Git 等版本控制工具，认为只要安装了 IntelliJ IDEA 就可以完全使用版本控制应有的功能。这完全是一种错误的解读，IntelliJ IDEA 是自带对这些版本控制工具的支持插件，但是该装什么版本控制客户端还是要照样装的。
如上图标注 1 所示，IntelliJ IDEA 对版本控制的支持是以插件化的方式来实现的。旗舰版默认支持目前主流的版本控制软件：CVS、Subversion（SVN）、Git、ClearCase、Mercurial、Perforce、TFS。又因为目前太多人使用 Github 进行协同或是项目版本管理，所以 IntelliJ IDEA 同时自带了 Github 插件，方便 Checkout 和管理你的 Github 项目。
- 支持插件，插件化方式实现，可以在IDEA内进行下载。
SVN配置
要在 IntelliJ IDEA 中使用 SVN，需要先安装 SVN 客户端或是 TortoiseSVN 这类图形化工具，Windows 系统这里推荐安装 TortoiseSVN，即使在不使用 IntelliJ IDEA 也可以方便管理我们的项目。
SVN 主要使用的版本有 1.6、1.7、1.8，最新的是 1.9。推荐大家使用 1.8 的。如果你的项目使用的是 1.6 的版本，在安装 1.8 之后是可以直接对项目文件进行升级的，所以无需担心，也因此更加推荐大家使用 1.8。
- 推荐配置1.8 推荐使用 Tortoise SVN图形化工具
在安装 TortoiseSVN 的时候，默认 command line client tools，是不安装的，这里建议勾选上。
如上图标注 1 所示，勾选 Use command line client
如上图标注 2 所示，建议 svn 的路径自己根据安装后的路径进行选择，不然有时候 IntelliJ IDEA 无法识别到会报：Cannot run program “svn” 这类错误。
如上图标注 3 所示，当使用一段时间 SVN 以后，发现各种 SVN 相关问题无法解决，可以考虑点击此按钮进行清除一下缓存。
根据目前的使用经验来看，IntelliJ IDEA 下 SVN 的使用经历并不算愉快，至少比 Git 不好用很多，经常遇到很多问题，所以这里也算是先给大家提个醒。如果紧急情况下 IntelliJ IDEA 无法更新、提交的时候，要记得使用 TortoiseSVN 来操作。
Git 的配置使用
要在 IntelliJ IDEA 中使用 Git，需要先安装 Git 客户端，这里推荐安装官网版本。
如上图标注 1 所示，确定好该路径下是否有对应的可执行文件。
GitHub的配置使用
-安装，略
如上图标注 1 所示，支持直接从你当前登录的 Github 账号上 Checkout 项目。
如上图标注 1 所示，支持把当前本地项目分享到你的 Github 账号上。
如上图标注 1 所示，支持创建 Gist。Github 的 Gist 官网地址：https://gist.github.com/
版本控制主要操作按钮
如上图标注 1 所示，对目录进行右键弹出的菜单选项。
如上图标注 1 所示，对文件进行右键弹出的菜单选项。
如上图标注红圈所示，为工具栏上版本控制操作按钮，基本上大家也都是使用这里进行操作。
第一个按钮：Update Project 更新项目。
第二个按钮：Commit changes 提交项目上所有变化文件。点击这个按钮不会立马提交所有文件，而是先弹出一个被修改文件的一个汇总框，具体操作下面会有图片进行专门介绍。
第三个按钮：Compare with the Same Repository Version 当前文件与服务器上该文件通版本的内容进行比较。如果当前编辑的文件没有修改，则是灰色不可点击。
第四个按钮：Show history 显示当前文件的历史记录。
第五个按钮：Revert 还原当前被修改的文件到未被修改的版本状态下。如果当前编辑的文件没有修改，则是灰色不可点击。
版本控制相关的常用设置说明
http://wiki.jikexueyuan.com/project/intellij-idea-tutorial/vcs-introduce.html 【08-29】
如上图标注 1 所示，当前项目使用的版本控制是 Git。如果你不愿意这个项目继续使用版本控制可以点击旁边的减号按钮，如果你要切换版本控制，可以点击 Git，会出现 IntelliJ IDEA 支持的各种版本控制选择列表，但是我们一般情况下一个项目不会有多个版本控制的。
如上图标注 2 所示，Show directories with changed descendants 表示子目录有文件被修改了，则该文件的所有上层目录都显示版本控制被修改的颜色。默认是不勾选的，我一般建议勾选此功能。
- 一个项目版本控制一般相同
- show directories with changed descendants 表示子目录有文件被修改，建议勾选
如上图标注 1 所示，When files are created 表示当有新文件放进项目中的时候 IntelliJ IDEA 做如何处理，默认是 Show options before adding to version control 表示弹出提示选项，让开发者决定这些新文件是加入到版本控制中还是不加入。如果不想弹出提示，则选择下面两个选项进行默认操作。
如上图标注 2 所示，When files are deleted 表示当有新文件在项目中被删除的时候 IntelliJ IDEA 做如何处理，默认是 Show options before removing from version control 表示弹出提示选项，让开发者决定这些被删除的是否从版本控制中删除。如果不想弹出提示，则选择下面两个选项进行默认操作。
- 当文件从项目删除、添加的时候是否有提示的选择
- setting-confirmation-when files are created
忽略列表（前面有提到过）
如上图标注 1 所示，对于不想加入到版本控制的文件，可以添加要此忽略的列表中。但是如果已经加入到版本控制的文件使用此功能，则表示该文件 或 目录无法再使用版本控制相关的操作，比如提交、更新等。我个人使用过程中发现在 SVN 上此功能不太好用，Git 上是可以用的。
不想加入版本控制的文件列表。SVN上不好用，Git上好用。
上图所示的弹出层就是本文上面说的 Commit Changes 点击后弹出的变动文件汇总弹出层。
如上图标注 1 所示，可以在文件上右键进行操作。Show Diff 当前文件与服务器上该文件通版本的内容进行比较。
Move to Another Changelist 将选中的文件转移到其他的 Change list 中。Change list 是一个重要的概念，这里需要进行重点说明。很多时候，我们开发一个项目同时并发的任务可能有很多，每个任务涉及到的文件可能都是基于业务来讲的。所以就会存在一个这样的情况：我改了 30 个文件，其中 15 个文件是属于订单问题，剩下 15 个是会员问题，那我希望提交代码的时候是根据业务区分这些文件的，这样我填写 Commit Message 是好描述的，同时在文件多的情况下，我也好区分这些要提交的文件业务模块。所以我一般会把属于订单的 15 个文件转移到其他的 Change list中，先把专注点集中在 15 个会员问题的文件，先提交会员问题的 Change list，然后在提交订单会员的 Change list。我个人还有一种用法是把一些文件暂时不提交的文件转移到一个我指定的 Change list，等后面我觉得有必要提交了，再做提交操作，这样这些文件就不会干扰我当前修改的文件提交。总结下 Change list 的功能就是为了让你更好地管理你的版本控制文件，让你的专注点得到更好的集中，从而提升效率。
Jump to Source 打开并跳转到被选中。
如上图标注 2 所示，可以根据工具栏按钮进行操作，操作的对象会鼠标选中的文件，多选可以按 Ctrl 后不放，需要注意的是这个跟前面的复选框是没有多大关系的。
Reformat code 格式化代码，如果是 Web 开发建议不要勾选，因为格式化 JSP 类文件，格式化效果不好。如果都是 Java 类则可以安心格式化。
Rearrange code 重新编排代码，IntelliJ IDEA 支持各种复杂的编排设置选项，这个会在后面说。设置好了编码功能之后，这里就可以尝试勾选这个进行自动编排。
Optimize imports 优化导入包，会自动去掉没有使用的包。这个建议都勾选，因其只对 Java 类有作用，所以不用担心有副作用。
Perform code analysis 进行代码分析，这个建议不用在提交的时候处理，而是在开发完之后，要专门养成对代码进行分析的习惯。IntelliJ IDEA 集成了代码分析功能。
Check TODO 检查代码中的 TODO。TODO 功能后面也会有章节进行讲解，这里简单介绍：这是一个记录待办事项的功能。
Cleanup 清除下版本控制系统，去掉一些版本控制系统的错误信息，建议勾选（主要针对 SVN，Git 不适用）。
如上图标注 4 所示，填写提交的信息。
如上图标注 5 所示，Change list 改变列表，这是一个下拉选项，说明我们可以切换不同的 Change list，提交不同的 Change list 文件。
如上图标注箭头所示，我们可以查看我们提交历史中使用的 Commit Message，有些时候，我们做得是同一个任务，但是需要提交多次，为了更好管理项目，建议是提交的 Message 是保持一致的。
仓库的增删改查操作
- change list 把部分修改代码放入另外的 changelist 以便之后再提交，可以让你专注当前的代码段。同时也可以用来根据业务的不同，分离代码的修改提交。（change list的操作在左下角，待会有图说明）
- message建议用心填写
SVN的使用——暂时待学
SVN 的这个窗口有的 IntelliJ IDEA 上叫 Changes，有的叫 Version Control，具体是什么原因引起这样的差异，我暂时还不清楚。但是不管叫法如何里面的结构是一样的，所以对使用者来讲没多大影响，但是你需要知道他们其实是一样的功能即可。
上图 Local Changes 这个 Tab 表示当前项目的 SVN 中各个文件的总的情况预览。这里的 Default 是 IntelliJ IDEA 的默认 change list 名称，no commit 是我自己创建的一个change list，我个人有一个习惯是把一些暂时不需要提交的先放这个 list 里面。change list 很常用而且重要，本文前面也有强调过了，所以一定好认真对待。unversioned Files 表示项目中未加到版本控制系统中的文件，你可以点击 Click to browse，会弹出一个弹出框列表显示这些未被加入的文件。
上图 Repository 这个 Tab 表示项目的 SVN 信息汇总，内容非常的详细，也是我平时用最多的地方。如果你点击这个 Tab 没看到数据，是因为你需要点击上图红圈这个刷新按钮。初次使用下默认的过滤条件不是我上图这样的，我习惯根据 User 进行过滤筛选，所以上图箭头中的 Filter 我是选择 User。选择之后，如上图标注 1 所示，显示了这个项目中参与提交的各个用户名，选择一个用户之后，上图标注 2 所以会显示出该用户提交了哪些记录。选择标注 2 区域中的某个提交记录后，标注 3 显示对应的具体提交细节，我们可以对这些文件进行右键操作，具体操作内容跟本文上面提到的那些提交时的操作按钮差不多，这里不多讲。
总的来说，SVN 这个功能用来管理和审查开发团队中人员的代码是非常好用的，所以非常非常建议你一定要学会该功能。
Git Flow 的介绍
Git Flow 概念
Git Flow 是一个 git 扩展集，按 Vincent Driessen 的分支模型提供高层次的库操作。这里的重点是 Vincent Driessen 的分支模型思想，下面讲解的内容也是基于 Vincent Driessen 思想。 Vincent Driessen 的观点：http://nvie.com/posts/a-successful-git-branching-model/
- Git Flow 是一个 git 扩展集 你可以理解 Git Flow 是一个基于 Git 的插件，这个插件简化了 Git 一些复杂的命令，比如 Git Flow 用一条命令，就可以代替 Git 原生 10 条命令。
- Git Flow 对原生的 Git 不会有任何影响，你可以照旧用 Git 原生命令，也可以使用 Git Flow 命令
还有其他的一些分支管理模型思想，具体可以看：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
Git Flow 安装
Windows：如果你安装 Git 用的是 Git for Windows，那它已经内置了。
Mac：brew install git-flow-avh
Linux：wget –no-check-certificate -q https://raw.githubusercontent.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh && sudo bash gitflow-installer.sh install stable; rm gitflow-installer.sh
更多版本：https://github.com/petervanderdoes/gitflow-avh/wiki/Installation
在系统环境上支持之后，再安装 IntelliJ IDEA 对 Git Flow 支持的插件：https://plugins.jetbrains.com/plugin/7315-git-flow-integration
Git Flow 基础命令资料
https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html
http://www.jianshu.com/p/9e4291078853
http://stormzhang.com/git/2014/01/29/git-flow/
gitflow的相关文章(https://www.jianshu.com/p/9e4291078853）