一、配置文件存放
位置:
E:\web\idea\installVersion\IntelliJ IDEA 2018.2.3\bin\idea.properties
修改:
再次启动IDEA,就会发现配置信息保存在自己设置的目录下了。重装系统,配置信息也不会丢失。
1、重启后会让选择是否导入配置文件
本机上没有配置文件,选择 not import setting
2、Set UI theme(Darcula黑,intelliJ白)--next--default plugins
3、Tune IDEA to your tasks
- 上图显示了 IntelliJ IDEA 支持的主要的一些扩展功能或者说是工具、插件也可以。你可以根据自己开发的需求进行禁用一些扩展,这样可以稍微减轻 IntelliJ IDEA 运行时所占内存,加快运行速度,但是效果并不会很明显就是。
- 我们这里点击
Java Frameworks
的Customize
进行下一步操作。
4、Java Frameworks
- 上图显示了 IntelliJ IDEA 所以支持的
Java Frameworks
。我们可以根据自己的开发需求不启用指定框架的。去掉框架前面的勾选框就表示不启用该框架功能支持。 - 对于不启用的框架,我们也可以在后期进行重新勾选
点击Save Changes and Go Back--next:featured plugins--Start using intelliJ idea
二、使用
1、启动界面
- IntelliJ IDEA 是没有类似 Eclipse 的工作空间的概念(
Workspaces
),最大单元就是Project
。如果你同时观察多个项目的情况,IntelliJ IDEA 提供的解决方案是打开多个项目实例,你可以理解为开多个项目窗口。 - 命令
Create New Project
创建一个新项目。 - 命令
Import Project
导入一个已有项目。 - 命令
Open
打开一个已有项目,可以直接打开 Eclipse 项目,但是由于两者 IDE 下的项目配置不一样,所以项目还是需要配置的。 - 命令
Check out from Version Control
可以通过服务器上的项目地址 Checkout Github 上面项目或是其他 Git 托管服务器上的项目。
2、Create New Project
2.1、创建一个静态webHTML页面
2.2、首次打开界面
idea首次创建或打开新项目时,都会创建项目索引,此时会有卡顿延迟,不要动
2.3、界面显示
3、主题修改
File--setting--Appearance--Theme
3.1、字体修改(选择支持中文的字体)
代码编辑字体:
控制台输出字体:(输出出现乱码很可能是此处未修改)
4、编辑区主题:
主题细节:
5、文件编码:
对于 Properties
文件,重要属性 Transparent native-to-ascii conversion
主要用于转换 ascii
,一般都要勾选,不然 Properties
文件中的注释显示的都不会是中文。
单独的文件编码修改:
Reload
表示使用新编码重新加载,新编码不会保存到文件中,重新打开此文件,旧编码是什么依旧还是什么。Convert
表示使用新编码进行转换,新编码会保存到文件中,重新打开此文件,新编码是什么则是什么。- 含有中文的代码文件,
Convert
之后可能会使中文变成乱码,所以在转换成请做好备份,不然可能出现转换过程变成乱码,无法还原。
5、由于编码问题引起的编译错误:
- 编译报错:
找不到符号
、未结束的字符串文字
等的解决办法:
- 由于 UTF-8 编码文件有分
有BOM
和无BOM
之分,默认情况下 IntelliJ IDEA 使用的编译器是javac
,而此编译只能编译无BOM
的文件,有很多 Eclipse 用户在使用 IntelliJ IDEA 开发 Eclipse 项目的时候常常会遇到此问题。主要是因为 Eclipse 的编译器是Eclipse
,此编译器支持有BOM
的文件编译。故,解决办法是对于此文件进行 BOM 去除。- 批量去除 BOM,你可以 Google:
批量去除 BOM
、批量转换无 BOM
等关键字,网络上已有提供各种方案。- 除了通过去除 BOM 还有设置 IntelliJ IDEA 的编译器为
Eclipse
,但是一般不建议这样做。- 如果上述问题都无法解决,而且你也确认 IntelliJ IDEA 各个配置编码的地方都是
UTF-8
,报错文件编码也是是UTF-8 无 BOM
的话,那还有一种可能也会出现这种情况:项目配置文件有问题。项目编码的配置文件在:/项目目录/.idea/encodings.xml
。如果你会修改此文件可以进行修改,如果不会,那就删除掉.idea
整个目录,重启 IntelliJ IDEA 重新配置这个项目即可。
6、Tomcat控制台输出乱码:
7、文件类型图标
-
Source root
,你可以理解为源目录,源码的作用就是用来专门放 Java 类文件,相对于编译出来的 class 文件而言,它就是源。我们一般默认名字叫src
的目录就是源目录,但是其实并不是这样的,在 IntelliJ IDEA 中,即使叫srcs
也是可以设置为Source root
,所以源目录跟目录命名是没有关系的,而是在于 IntelliJ IDEA 支持对任意目录进行设置为Source root,
Source root
的作用是标记该目录下的文件是可编译的。 -
Java class located out of the source root
,由于上一条我们知道Source root
目录是用来告诉 IntelliJ IDEA 这是编译目录,而假如你 Java 类文件没有放在该目录或是该目录的子包下,那该 Java 类则无法编译,就会被表示成这个图标。
8、idea索引与缓存:
Java class located out of the source root
。我们也都知道该图标是表示 Java 类文件没有在 Source root
目录下的文件夹下会显示此图标,但是其实还有一种情况也是会显示此图标的。那就是:在 IntelliJ IDEA 创建索引过程中,所有的 Java类 都是这个图标,如果你项目大的话很容易观察到的,几个文件的小项目倒是不一定会看到。所以在 IntelliJ IDEA 创建索引过程即使你编辑了代码也是编译不了、运行不起来的,所以还是安安静静等 IntelliJ IDEA 创建索引完成。
IntelliJ IDEA 的缓存和索引主要是用来加快文件查询,从而加快各种查找、代码提示等操作的速度
某些特殊条件下,IntelliJ IDEA 的缓存和索引文件也是会损坏的
清除缓存和索引:
- 一般建议点击
Invalidate and Restart
,这样会比较干净。- 但是有一个需要提醒的是,清除索引和缓存会使得 IntelliJ IDEA 的
Local History
丢失,所以如果你项目没有加入到版本控制,而你又需要你项目文件的历史更改记录,那你最好备份下你的LocalHistory
目录。目录地址在:C:\Users\当前登录的系统用户名\.IntelliJIdea14\system\LocalHistory
建议使用硬盘的全文搜索,这样效率更高。
通过上面方式清除缓存、索引本质也就是去删除 C 盘下的 system
目录下的对应的文件而已,所以如果你不用上述方法也可以删除整个 system
。当 IntelliJ IDEA 再次启动项目的时候会重新创建新的 system
目录以及对应项目缓存和索引。
如果你遇到了因为索引、缓存坏了以至于项目打不开,那也建议你可以直接删除 system
目录,一般这样都可以很好地解决你的问题。
如果你 C 盘空间不足的情况下,最好转移下 system
目录
9、Java文件编译方式
相比较于 Eclipse 的实时自动编译,IntelliJ IDEA 的编译更加手动化,虽然 IntelliJ IDEA 也支持通过设置开启实时编译,但是不建议,因为太占资源了。IntelliJ IDEA 编译方式除了手工点击编译按钮进行编译之外,还有就是在容器运行之前配置上一个编译事件,先编译后运行。默认下 IntelliJ IDEA 也都是这样的设置,所以实际开发中你也不用太注意编译这件事。虽然 IntelliJ IDEA 没有实时编译,但是对于代码检查完全是没有影响。但是多个类之间的关联关系还是要等 Make 或 Rebuild 触发的时候才会做相关检查的。
- 1、Make:使用最多的编译操作。对选定的目标(Project 或 Module)进行编译,但只编译有修改过的文件,没有修改过的文件不会编译,这样平时开发大型项目才不会浪费时间在编译过程中。注:2018版操作为Build。
- 2、Compile:对选定的目标(Java 类文件),进行强制性编译,不管目标是否是被修改过。注:2018版操作为Recompile。
- 3、Rebuild:对选定的目标(Project),进行强制性编译,不管目标是否是被修改过,由于 Rebuild 的目标只有 Project,所以 Rebuild 每次花的时间会比较长。
运行之前先Build:
- 上图标注 1 所示,也是我们本文前面讲的,IntelliJ IDEA 是支持自动编译的,默认是不开启的,也建议不用开启,原因前面已经说了。
- 上图标注 2 所示,设置编译
heap
大小,默认是700
,建议使用 64 位的用户,在内存足够的情况下,建议改为1500
或以上。如果你在编译的时候出错,报:OutOfMemoryError
,一般也是要来改这个地方。 - 上图标注 3 所示,还可以设置编译时的
VM
参数,这个你可以根据需求进行设置,一般人是用不上的。
编译排除:
- 如上图标注 1 所示,可以添加目录 或 文件进行编译排除。
- 在项目中,如果有任何一个可编译的文件无法编译通过,则 IntelliJ IDEA 是无法运行起来的,必须等你全部问题解决,编译通过之后才可运行。但是可能开发过程中,某一个包目录的文件编译无法通过,但是我们又不急着改,那我们就可以考虑把该包加入到排除编译列表中,则项目就可以运行起来。
- 如上图 所示:
- 1、IntelliJ IDEA 支持常见的几种编译器:
Javac
、Eclipse
、Ajc
等。默认是Javac
,也推荐使用Javac
。 2、Project bytecode version
针对项目字节码编译版本,一般选择的是当前项目主 JDK 的版本。3、Per-module bytecode version
可以针对Project
下各个Module
的特殊需求单独设置不同的bytecode version
,前提是电脑上必须有安装对应的 JDK 版本。
10、项目迁移:
- Eclipse 用户可以看:https://www.jetbrains.com/idea/help/eclipse.html
- NetBeans 用户可以看:https://www.jetbrains.com/idea/help/netbeans.html
Project和Module:
如果你是 Eclipse 用户,并且已经看了上面给的链接,那 IntelliJ IDEA 首先告诉你一个非常重要的事情:IntelliJ IDEA 没有类似 Eclipse 工作空间(workspace)的概念的。很多从 Eclipse 转过来的人总是下意识地要再同一个窗口管理 n 个项目,这在 IntelliJ IDEA 是无法得到。IntelliJ IDEA 提供的体验是:一个 Project 打开一个 Window 窗口。
在 IntelliJ IDEA 中 Project 是最顶级的级别,次级别是 Module。一个 Project 可以有多个 Module。目前主流的大型项目结构都是类似这种多 Module 结构,这类项目一般是这样划分的,比如:core Module、web Module、plugin Module、solr Module 等等,模块之间彼此可以相互依赖。通过这些 Module 的命名也可以看出,他们之间应该都是处于同一个项目业务情况下的模块,彼此之间是有不可分割的业务关系的。
所以我们现在总结:一个 Project
是由一个或多个 Module
组成,模块之间尽量是处在同一个项目业务的的情况下,彼此之间互相依赖关联。这里用的是 尽量
,因为 IntelliJ IDEA 的 Project 是一个没有具备任何编码设置、构建等开发功能的,主要起到一个项目定义、范围约束、规范等类型的效果,也许我们可以简单地理解为就是一个单纯的目录,只是这个目录命名上必须有其代表性的意义。
下面我们以著名的 spring-framework
项目为例介绍多 Module 的结构的:
- 项目主页:https://github.com/spring-projects/spring-framework:
- 该项目的
Project
命名是:spring-framework。该目录主要作用为各个Module
的顶层目录进行约束,告诉协同者,这个目录下都是spring-framework
相关的,我绝不会放 Android 相关源码、文档、文件在上面的。该目录并不是以一个实际性的目录来体现的,所以你访问主页是看不到的,但是当你checkout
的时候,你必须为这个项目命名,至于命名默认就是spring-framework
。- 该
Project
下有二十来个Module
,各个Module
的命名也是有含义的,比如:spring-core
、spring-jdbc
、spring-jms
、spring-orm
、spring-web
、spring-webmvc
等等,我们通过这些命名也能清楚地知道他们要表达的含义,这些 Module 下也都各自有src
编码目录,可以自行编码和构建。
- 相比较于多 Module 项目,小项目就无需搞得这么复杂。只有一个 Module 的结构 IntelliJ IDEA 也是支持的,并且 IntelliJ IDEA 创建项目的时候,默认就是单 Module 的结构的。
- 在输入
Project name
的时候,Module name
和Module file Location
自动进行改变,同时Project location
和Module file Location
完全一样,这也就表示,Project 目录和 Module 目录是同一个,所以此时 Project 目录下就会有src
目录,但是我们应该明白其本质还是 Module 的目录。
11、SDK(Software Development Kit)软件开发工具包:
File--Project Structure
- 按
Ctrl + Shift + Alt + S
弹出项目结构设置区,如上图所示。 - 如上图标注 2 所示,IntelliJ IDEA 支持 6 种 SDK。最常用的就是
JDK
和Android SDK
,其中在创建Android SDK
的时候如果你没有先配置一个JDK
的话,IntelliJ IDEA 则会提示你要先配置一个JDK
,然后才能配置Android SDK
。 - 如上图标注 1 所示,下拉会展示已经创建的所有 SDK,可以很方便地不同 SDK 中切换。在开发 Java 项目过程中,由于 IntelliJ IDEA 支持管理多个
JDK
,所以你完全不用担心你系统上不同项目需要不同JDK
。
- 如上图标注 1 所示,
SDKs
为 SDK 的统一管理处。 - 如上图标注 2 所示,加号可以添加新 SDK,支持的类型如标注 3 所示;减号可以删除光标所选的 SDK。
Language Level:
- JDK 6 的新特性:@Override in interfaces
- JDK 7 的新特性:Diamonds,ARM,multi-catch etc.
- JDK 8 的新特性:Lambdas,type annotation etc.
- JDK 9 的新特性:Jigsaw project etc.
当我们使用 JDK 8 的时候,我们只能向下兼容 JDK 8 及其以下的特性,所以只能选择 8 及其以下的 language level
。所以当我们项目使用的是 JDK 8,但是代码却没有使用 JDK 8 的新特性,最多使用了 JDK 7 的特性的时候我们可以选择 7 - Diamonds,ARM,multi-catch etc.
。
对此我们总结 language level
:限定项目编译检查时最低要求的 JDK 特性。
现在假设我们有一个项目代码使用的 JDK 8 新特性:lambda
语法,但是 JDK 选择的却是 JDK 7,即使 language level
选择了 8 - Lambdas,type annotation etc.
,也是没有多大意义的,一样会编译报错。
Module下的SDK和Language Level:
对于大型项目,各个 Module 用到的 SDK
和 language level
很有可能是各不一样的,IntelliJ IDEA 对此也进行了支持。
如上图所示:可以针对 Module 选择其他 SDK,默认选择的是 Project SDK
- 如上图标所示,可以针对 Module 选择其他
language level
,默认选择的是Project language level
12、第一个idea项目创建:
File--new--project--java--JavaEE
- 如上图标注 所示,如果此时 IntelliJ IDEA 还没有配置任何一个 SDK 的话,可以点击
New...
先进行 SDK 的配置。 - 配置好 SDK 或选择好 SDK 之后,点击
Next
进入下一步。
- 如上图标注所示,可以选择模板快速创建项目。
Command Line App
会自动创建一个带有 main 方法的类。Java Hello World
会自动创建一个带有 main 方法的并且会打印输出 Hello World 的类。- 我们这里不勾选使用模板,而是手工创建,所以我们点击next,进入下一步。
如上图填入项目名称
- 如上图标注 所示,默认
More Settings
是没有展开的,点击此处可以展开更多细节的信息。 - 如上图标注 2所示,IntelliJ IDEA 的项目格式文件主要提供两种方式
.idea (directory based)
创建项目的时候自动创建一个.idea
的项目配置目录来保存项目的配置信息。这是默认选项。.ipr (file based)
创建项目的时候自动创建一个.ipr
的项目配置文件来保存项目的配置信息。
src
目录为蓝色表示Source root
,我们可以再此目录下创建包和类。
src右键--New--Package
- 如上图标注所示,在没有文件的情况下包目录默认是连在一起的,这不方便看目录层级关系。
- 如上图标注 箭头 所示,点击此齿轮,在弹出的菜单中去掉标注选项:
Compact Empty Middle Packages
。
- 如上图所示,在包下可以直接创建
Class
、Interface
、Enum
、Annotation
等常见类型文件。
编写main方法,打印输出HelloWorld: 右键--run
- 如上图所示,
.idea
即为Project
的配置文件目录。 - 如上图 所示,
.iml
即为Module
的配置文件。 - 通过上面的了解我们也知道 IntelliJ IDEA 项目的配置变动都是以这些 XML 文件的方式来表现的,所以我们也可以通过了解这些 XML 文件来了解 IntelliJ IDEA 的一些配置。也因为此特性,所以如果在项目协同中,我们要保证所有的项目配置一致,就可以考虑把这些配置文件上传到版本控制中(包括
.idea
目录和.iml
文件)。如果把这些文件加入到版本控制之后,那又有一点是需要考虑的,那就是协同者 Checkout 项目下来之后,按自己的需求进行项目配置的之后,项目的 XML 文件也会跟着变化。此时协同者的这些变化的文件就不应该再上传到版本控制中。至于如何更好地控制这些不想随时提交的文件,在接下来的版本控制专讲中会进行详细讲解。
- IntelliJ IDEA 是一个没有
Ctrl + S
的 IDE,所以每次修改完代码你只要管着运行或者调试即可,无需担心保存或者丢失代码。
13、版本控制
对于 IDE 来讲,集成版本控制的本身就是它最大的亮点之一
- 很多人认为 IntelliJ IDEA 自带了 SVN 或是 Git 等版本控制工具,认为只要安装了 IntelliJ IDEA 就可以完全使用版本控制应有的功能。这完全是一种错误的解读,IntelliJ IDEA 是自带对这些版本控制工具的支持插件,但是该装什么版本控制客户端还是要照样装的。
- 如上图标注所示,IntelliJ IDEA 对版本控制的支持是以插件化的方式来实现的。旗舰版默认支持目前主流的版本控制软件:CVS、Subversion(SVN)、Git、ClearCase、Mercurial、Perforce、TFS。又因为目前太多人使用 Github 进行协同或是项目版本管理,所以 IntelliJ IDEA 同时自带了 Github 插件,方便 Checkout 和管理你的 Github 项目。
SVN:
- Subversion 官网下载:https://subversion.apache.org/download/#recommended-release
- TortoiseSVN 官网下载:http://tortoisesvn.net/downloads.zh.html
- 如上图标注所示,建议 svn 的路径自己根据安装后的路径进行选择,不然有时候 IntelliJ IDEA 无法识别到会报:
Cannot run program "svn"
这类错误。- 如上图标注所示,当使用一段时间 SVN 以后,发现各种 SVN 相关问题无法解决,可以考虑点击此按钮进行清除一下缓存。
根据目前的使用经验来看,IntelliJ IDEA 下 SVN 的使用经历并不算愉快,至少比 Git 不好用很多,经常遇到很多问题,所以这里也算是先给大家提个醒。如果紧急情况下 IntelliJ IDEA 无法更新、提交的时候,要记得使用 TortoiseSVN 来操作。
GIT
- Git 官网下载:http://git-scm.com/
- TortoiseGit 官网下载:http://download.tortoisegit.org/tgit/
确定好该路径下是否有对应的可执行文件。
GitHub的配置和使用:
登录:
检出:
提交:
支持创建Gist:项目右键--create gist Github 的 Gist 官网地址:https://gist.github.com/
git版本控制主要操作按钮:
Toolbar按钮:
- 第一个按钮:
Update Project
更新项目。 - 第二个按钮:
Commit changes
提交项目上所有变化文件。点击这个按钮不会立马提交所有文件,而是先弹出一个被修改文件的一个汇总框,具体操作下面会有图片进行专门介绍。 - 第三个按钮:
Compare with the Same Repository Version
当前文件与服务器上该文件通版本的内容进行比较。如果当前编辑的文件没有修改,则是灰色不可点击。 - 第四个按钮:
Show history
显示当前文件的历史记录。 - 第五个按钮:
Revert
还原当前被修改的文件到未被修改的版本状态下。如果当前编辑的文件没有修改,则是灰色不可点击。
菜单栏上的操作区:
Git版本控制常用设置:
- 如上图标注所示,当前项目使用的版本控制是
Git
。如果你不愿意这个项目继续使用版本控制可以点击旁边的减号按钮,如果你要切换版本控制,可以点击Git
,会出现 IntelliJ IDEA 支持的各种版本控制选择列表,但是我们一般情况下一个项目不会有多个版本控制的。 - 如上图标注所示,
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
表示弹出提示选项,让开发者决定这些被删除的是否从版本控制中删除。如果不想弹出提示,则选择下面两个选项进行默认操作。
- 如上图标注所示,对于不想加入到版本控制的文件,可以添加要此忽略的列表中。但是如果已经加入到版本控制的文件使用此功能,则表示该文件 或 目录无法再使用版本控制相关的操作,比如提交、更新等。我个人使用过程中发现在 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
后不放,需要注意的是这个跟前面的复选框是没有多大关系的。如上图标注 3 所示,可以在提交前自动对被提交的文件进行一些操作事件(该项目使用的 Git,使用其他版本控制可能有些按钮有差异。):
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
是保持一致的。
- 如上图标注箭头所示,如果你使用的 Git,点击此位置可以切换分支和创建分支,以及合并、删除分支等操作。
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 常见问题
- 更新的时候报:
Can't update: no tracked branch
- 解决办法:打开 git-bash(路径:C:\Program Files\Git\git-bash.exe),切换到这个更新不下来的项目的根目录,然后输入:
git branch --set-upstream-to origin/master master
,回车之后重新回到 IntelliJ IDEA 进行更新,正常就可以了。
- 解决办法:打开 git-bash(路径:C:\Program Files\Git\git-bash.exe),切换到这个更新不下来的项目的根目录,然后输入:
- 输错密码后,弹出验证的登录框没有再出现:
- 解决办法如下图:选择
Do not save, forget passwords after restart
等你确定你的密码没错后再选择保存密码方案。
- 解决办法如下图:选择
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 核心概念
- 必须有的两个核心分支(长期分支):
- master,Git 代码仓库中默认的一条主分支。这条分支上的代码一般都建议为是正式版本的代码,并且这条分支不能进行代码修改,只能用来合并其他分支。
- develop,一般用于存储开发过程的代码分支,并且这条分支也不能进行代码修改,只能用来合并其他辅助分支。
- 根据情况创建的辅助分支(临时分支)
- feature branches(功能分支)
- 基于 develop 分支上创建
- 开发完成后合并到 develop 分支上
- 当要开始一个新功能的开发时,我门可以创建一个 Feature branches 。等待这个新功能开发完成并确定应用到新版本中就合并回 develop
- 对于单人开发的 feature branches,start 之后,开发完成后可以直接 finish。
- 对于多人开发的 feature branches,start 之后,开发完成后先 publish 给其他开发人员进行合并,最后大家都开发完成后再 finish。这个思路也同样适用下面几个辅助分支场景。
- feature branches 开发过程有 bug,直接在 feature branches 上修改、提交。
- release branches(预发布分支)
- 基于 develop 分支上创建
- 测试确定新功能没有问题,合并到 develop 分支和 master 分支上
- 用来做新版本发布前的准备工作,在上面可以做一些小的 bug 修复、准备发布版本号等等和发布有关的小改动,其实已经是一个比较成熟的版本了。另外这样我们既可以在预发布分支上做一些发布前准备,也不会影响 "develop" 分支上下一版本的新功能开发。
- hotfix branches(基于 master 基础上的生产环境 bug 的修复分支)
- 基于 master 分支上创建
- 修复测试无误后合并到 master 分支和 develop 分支上
- 主要用于处理线上版本出现的一些需要立刻修复的 bug 情况
- feature branches(功能分支)
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/
Git Flow Integration 插件的使用
- 如果你已经理解了上面的理论,再看下面这些截图你能理解对应的是什么意思。
以上内容参考自https://youmeek.gitbooks.io/intellij-idea-tutorial,由衷感谢