IntelliJ IDEA 下的版本控制介绍

这一章节放在这么靠前位置来讲是因为版本控制在我心目中的地位比后面的实战知识点都来得重要。不管是个人开发或是团队开发，版本控制都是可以很好地被使用的，目前我找不到任何开发者不使用版本控制的理由。而且对于 IDE 来讲，集成版本控制的本身就是它最大的亮点之一，很多开发者也是为此而使用它。

在本章节中也会对 IntelliJ IDEA 的相关版本控制进行了介绍，会开始涉及到一些 IntelliJ 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 项目。

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。

• Subversion 官网下载：http://tortoisesvn.net/downloads.zh.html

• 如上图箭头所示，在安装 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 客户端，这里推荐安装官网版本。

Git 主要的版本有 1.X、2.X，最新的是 2.X，使用版本随意，但是不要太新了，不然可能 IntelliJ IDEA 小旧版本会无法支持可能。

• Git 官网下载：http://download.tortoisegit.org/tgit/

如上图标注 1 所示，确定好该路径下是否有对应的可执行文件。

Github 的配置和使用

• 如上图标注 1 所示，填写你的 Github 登录账号和密码，点击 Test 可以进行测试是否可以正确连上。

• 如上图标注 1 所示，支持直接从你当前登录的 Github 账号上 Checkout 项目。

• 如上图标注 1 所示，支持把当前本地项目分享到你的 Github 账号上。

• 如上图标注 1 所示，支持创建 Gist。Github 的 Gist 官网地址：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 命令。

还有其他的一些分支管理模型思想，具体可以看：<a rel="nofollow" href="http://www.ruanyifeng.com/blog/2015/12/git-workflow.html" "="" style="padding: 0px; margin: 0px; background-color: transparent; color: rgb(45, 133, 202);">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 情况