最全Pycharm教程（39）——Pycharm版本控制之本地Git用法
　　1、主题
　　介绍如果通过Pycharm使用本地Git集。
　　2、准备工作　　
　　（1）PyCharm版本为2.7或更高
　　（2）已经创建一个工程
　　（3）Git插件可用，对应可执行文件在 Git page页面正确配置
　　3、创建一个Git集
　　按下Alt+`显示常用的VCS命令（也可以通过主菜单VCS&VCS Operations Popup），选择Create Git repository命令：
　　Git通过在父目录下创建一个.git文件夹来安装本地版本库。此处我们选择在根目录下创建.git目录：
　　4、Pycharm用户界面变化
　　（1）出现Changes tool window窗口
　　（2）Solver.py文件名变色
　　 这也意味着这个新的文件尚未添加版本控制（稍后介绍）。
　　（3）打开设置对话框（Ctrl+Alt+S），单击 Version Control，发现MySimpleApplication目录已经和Git关联：
　　5、为文件添加版本控制
　　方法put a file under version control，这里例举一种。选择Solver.py文件，按下Ctrl+Alt+A。
　　Solver.py文件变为绿色，意味着已经进行了版本控制，但尚未托管：
　　6、提交本地版本库
　　在Changes tool window窗口中选择 Solver.py文件，按下Ctrl+K，输入信息，单击Commit。
　　打开Changes tool window的Log tab选项卡查看;
　　7、查看当前分支
　　两种方式：
　　第一，使用主菜单命令VCS&Git&Branches，在弹出的窗口中查看：
　　第二，使用状态栏上的Git：
　　8、更改主分支代码
　　以重命名为例。将光标定位在discr符号上，按下Shift+F6，输入新名字discriminant。
　　注意此时左槽会产生相应标记：
　　单击这个标记，Pycharm会弹出窗口提示当前所做更改。按下Ctrl+K快捷键更新代码。
　　9、创建一个新的分支
　　单击状态栏上的分支图标，输入名称：
　　新分支现在在当前 Changes tool window窗口中，作为一个选项卡：
　　接下来再从主分支中创建第二个分支（Branch2）。
　　10、更改新分支中的代码
　　切换到分支1：
　　将光标定位在discriminant符号上，按下Shift+F6，输入简写，例如dis，然后按下Ctrl+K托管更改。
　　对分支2进行同样操作。
　　11、合并分支
　　只能将当前分支合并到其他分支上。使用VCS&Git&Merge Changes的主菜单命令：
　　选择接受这些更改并托管，再次查看，发现比之前更复杂了：互联网产品开发：为什么版本控制如此重要？
如果说什么是软件开发项目一定要使用的基础工具，那么版本控制系统应该算最重要的部分。不管是个人开发或是团队协作开发，都可以通过版本控制系统获得巨大的好处。
没有版本控制系统的话，代码可能被别人或自己不小心覆盖或遗失、也不知道是谁因为什么原因改了这段代码、也没办法可以复原回前几天的修改。有了版本控制系统，开发人员只要将每次程式码的变更都纪录（Commit）起来，并且透过版本控制系统中进行更新。
有了版本控制系统，我们可以浏览所有开发的历史纪录，掌握团队的开发进度，而且作任何修改都不再害怕，因为你可以轻易的复原回之前正常的版本。我们也可以透过分支和标签的功能来进行软件发行的不同版本，例如稳定版本、维护版本和开发中版本。
很多项目需求方还没有明白开发的定义，这里必须要跟大家说一点老生常谈的段子：“开发永远是个过程，而不是结果。”所以开发者一定要使用版本控制系统，Git或Mercurial是免费开源的版本系统系统、随处可用的网络、便宜的云端服务器，甚至有现成的第三方服务Github。
如果你还没有使用的话，建议马上为你的软件开发项目建立版本控制。接下来是几点使用版本控制系统的建议：
1.将所有东西都放进版本控制系统
是的，所有项目开发过程中的产出物都放到版本控制系统之中，这包括了程序源代码、测试程序、文件、设定档、各种自动化脚本等等。除了新成员可以很容易拉出最新的版本马上开始工作之外，我们也希望在测试环境、正式环境中，也可以随时更新到我们所指定的版本，因此将所有变更的纪录保存起来是非常重要的。
例如，数据库的变更也必须纳入版本控制。首先，在数据库中纪录它目前的版本编号。接着我们每次的修改都透过一个自动化脚本来执行，并将这个脚本放入版本控制之中，而不是手动用指令去修改纲要。这样的好处是团队中每个人都可以透过版本控制系统看到这个变更，并且升级他的数据库。测试和正式的服务器环境，也会透过这个脚本来自动进行升级。笔者熟悉的Ruby on Rails中就有内置这样的Migration机制，其他程序语言也有类似的数据库工具。
另外，以服务器应用来说，光是有源代码还是无法100%让软件工作起来，我们还需要知道服务器的配置设定，包括基础网络设定、操作系统设定、依赖的套件版本等等。因此最好这些配置设定也可以纳入版本管理系统之中。近年来云端技术的进步，已经可以将这些基础设施设定当作程序，无缝地让每个成员和所有环境都使用完全相同的设定，减少出错的可能性。
2.频繁且适当大小的递交
如果久久才递交一次修改到版本控制系统，那么你只是把版本控制系统当作一种备份工具而已，而没有享受到它真正的好处。频繁的递交可以帮助团队开发进度的透明化，减少多人开发时的代码冲突。当多人同时修改同一块代码时，解决代码冲突是很麻烦的事情。还有，我们也希望每一次的递交有适当的粒度大小，也就是每个提交的内容应该有高度相关性和独立性。例如是一个小功能或是一个小改进。如果你同时在做新功能A和修旧Bug，那么就应该分开两次递交。语法错误无法建构的程序也不应该提交从而造成团队困扰。
有良好大小的代码提交习惯的好处除了版本的历史纪录更加清楚之外，我们可以非常轻易的做代码的复原或移植，假设上述的新功能A有问题，我们可以只复原A而不影响修好的Bug，或是只挑选修Bug的移植到不同分支去。
3.良好的递交信息
每一次的递交都必须附上一段解释信息，说明修改的内容和原因。这除了可以帮助团队合作之外，更重要的是让软件有更好的维护性，以便将来备查，以下的场景相信开发者都不陌生：
软件发现一个Bug，然后指派给你修复。
你追代码追到一段看不懂的程序，也没有任何注释。
透过版本控制系统，你找到了同事在一年前加了这行，递交的信息是BUG或简单的错误提示。
同事还在公司，可是他也不记得当初是哪一个BUG了。或是他已经下班或离职了，反正找不到。
你强行改了这行代码，发布出去。
这个功能是修好了，但是发现另一个功能又出现问题。
继续加班到凌晨，悲催ing....
一个好的递交信息应该包括一行摘要信息，描述你为什么做这段变更，可能是新增、移除、修正某个功能，而不是描述新增或修改哪些档案，重点应放在备注为什么修改而不是这段是bug这么简单。因为修改了哪些档案和行数我们看版本差异就知道了，无须重复描述。如果你发现很难摘要，那可能表示你包含太多变更在同一次递交了，请试着拆开。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
程序员的经纪人
程序员客栈是远程工作开创者，企业的远程技术中心
今日搜狐热点版本控制(Revision control)是一种技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。
版本控制透过文档控制（documentation control）记录程序各个模组的改动，并为每次改动编上序号。这种方法是工程图（engineering drawings）维护（maintenance）的标准做法， 它伴随着工程图从图的诞生一直到图的定型。 一种简单的版本控制形式，例如，赋给图的初版一个版本等级&A&。当做了第一次改变后，版本等级改为&B&，以此类推等等。
1.软件系统的版本控制是指可以自行运行的各子系统的版本控制。
2.软件系统的由评测小组的人员确定，由评测小组进行版本控制工作。
3.软件系统的版本号由3部分构成，即主版本号+次版本号+修改号。主版本号1位，只有当系统在结构和功能上有重大突破改进后才发生变化；次版本号有2位；修改号8位，采用提交时的日期，当系统进行任何修改后，包括数据库结构发生变化，修改号都要随之改变。例如：Ver3.31.
4.各子系统的版本号独立。
5.各软件系统应该有显示详细版本号的功能。例如help菜单下的about功能。系统提交存档时，评测服务部要进行检查。
6.新系统开发完成、或已存档的系统进行修改，修改完成后，进行提交存档时，由评测评测小组工程师确定新版本号、或更改版本号。
7.软件系统，产生新的版本后，老版本的软件系统是否继续保存，取决于以下条件：
a.老版本的系统如果有客户还在使用，在客户升级以前，必须继续保存。
b.老版本的系统已经没有客户使用了，并且新版本的系统已经把老系统的文档完整地升级过来，这样可以删除或覆盖老版本的系统资源。
c.对于要删除或覆盖的老版本系统，可以统一备份起来。
4.常用的版本控制优缺点
Visual&SourceSafe：微软的工具，仅支持Windows操作系统。虽然简单好用，但是仅适用于团队级开发，不能胜任企业级的开发工作。
VSS优点：安装、配置、使用均较简单，很容易上手使用；操作简单，容易掌握；权限划分可到文件夹级，有Read、Check-Out&&&Check-In、Add/Rename/Delete、Destroy四种权限级别。
缺点：权限管理基于文件共享形式，只能从文件夹共享的权限设定对整个库文件夹的权限，而且必须要有可写权限；版本管理和分支管理只能靠人为的手工设置；版本发行时，只能手工挑选对应的版本文件进行发布；安全性不高，基于文件系统共享实现对服务器的访问，需要共享存储目录，这样用户可以对VSS的文件夹执行删除操作。
CVS是一个典型的服务器/客户端软件，有Unix版本的CVS&、版本的CVS和Windows版本的CVS。CVS支持远程管理，项目组分布开发时一般都采用CVS。安装、配置较复杂，但使用比较简单，只需对配置管理做简单培训即可。安全性高，CVS服务器有自己专用的数据库，文件存储并不采用&&共享目录&方式，所以不受限于局域网。CVS可以跨平台，支持并发版本控制，而且免费。CVS不支持文件改名，只针对文件控制版本而没有针对目录的管理,并且缺少相应的技术支持，许多问题的解决需要自已寻找资料，甚至是研究源代码。但也可以根据自己的需要进行编程。
相对功能单一、简陋，适用于几个人的小型团队，在数据量不大的情况下，性能可以接受。
SVN（Subversion）&是一种版本管理系统，其前身是CVS。SVN是根据CVS&的功能为基础来设计的，它除包括了CVS&的大多数特点外，还有一些新的功能，如：文件目录可以方便的改名、基于数据库的版本库、操作速度提升、权限管理更完善等。
CVS与SVN比较
是否依赖系统帐号
可否对分支授权
是否支持LDAP认证
图形化帐号管理
是(集中管理平台)
用户可否获取忘记口令，修改口令
是(集中管理平台)
目录，文件名变更
创建分支时间
分支可见、查询
二进制文件
二进制优化
二进制文件标识
二进制文件（图形文件）被破坏
修改提交说明
可否指定换行符类型
检查换行符设定，避免跨平台开发带来的混乱
hooks&脚本
网络带宽占用
ClearCase（闭源集中式）
ClearCase提供了全面的配置管理&&包括版本控制、工作空间管理、建立管理和过程控制，而且无须软件开发者改变他们现有的环境、工具和工作方式。
ClearCase包括两套：ClearCase&LT和ClearCase&(MultiSite)。前者可以用于在同一个局域网的开发小组，适合于中小型开发组织；ClearCase&(MultiSite)则适应于分布于不同地理位置、不同局域网的开发小组，适合于大型的开发组织。
增加团队效率――通过对并行开发的支持来实现，包括图形比较和归并、标签、版本目录结构。
增加个人效率&――通过自动的工作空间管理来实现，如：直接的版本访问、消除了在拷贝文件上的时间的浪费。
简单的维护和提高对客户的支持――通过快速准确的重建先前的版本来实现。
快速准确的产品发布&――通过保证构造的准确性和对软件的每一个元件进行版本控制来实现。
减少错误发生&――通过事件发生以后对每一个元件的变更进行追踪来实现。
硬件资源的优化&――通过分布式构造、减少文件拷贝、可用对象的共享等功能来实现。
提高项目协调和编制&――通过文件注释和开发周期阶段变更的自动关联来实现。
提高产品质量&――通过灵活的进程控制，和图形接口定制，使得软件开发在实际中保持一致。
更加有效的团队扩展――通过减少系统管理和维护的负担来实现。
支持分布式结构使得团队成长――通过Client/Server结构进行多点复制和及时的对象版本的更新来实现。
使用配置管理工具而降低风险――由于它不干扰软件程序员的工作，所以可以使用常用的工具和文件系统接口。
增加了软件的安全性和保护性&――通过使用分布式的存储结构，所有的软件资源会随时更新、在硬盘或网络出现错误时那些被ClearCase存储的版本信息会立刻恢复。
减少培训和实现成本&――ClearCase通过采用透明结构以及和标准开发工具进行集成来实现。
强有力的开发和维护&――通过和其它工具（如：缺陷追踪）、系统、结构进行集成。
支持不同种类的开发&――通过兼容不同平台的软件配置管理系统，如：Windows&NT、UNIX、和一些Client端的软件，如：Windows&95、Windows&NT、Windows&3.1和Windows&for&Workgroups。
缺点：ClearCase&太贵，易用性差，培训费用很贵，没有培训，很难上手使用。
StarTeam（闭源集中式）
StarTeam属于高端的工具，在易用性，功能和安全性等方面都很不错。&StarTeam的用户界面同VSS的类似，它的所有的操作都可通过图形用户界面来完成，同时，对于习惯使用命令方式的用户，StarTeam也提供命令集进行支持。而且StarTeam的随机文档也非常详细。&StarTeam还提供了流程定制的工具，用户可跟据自己的需求灵活的定制流程。与VSS和CVS不同，VSS和CVS是基于文件系统的配置管理工具，而StarTeam是基于数据库的。StarTeam的用户可根据项目的规模，选取多种数据库系统。StarTeam无需通过物理路径的权限设置，而是通过自己的数据库管理，实现了类似Windowsnt的域用户管理和目录文件ACL控制。StarTeam完全是域独立的。这个优势可以为用户模型提供灵活性，而不会影响到现有的安全设置。StarTeam的非常灵活并且系统。您可以对工程、视图、文件夹一直向下到每一个小的item设置权限。对于高级别的视图（view），访问控制可以与用户组、用户、项目甚至视图等链接起来。&StarTeam是按license来收费的，比起VSS，CVS来，企业在启动StarTeam进行配置管理需要投入一定资金。
优点：权限设置功能强大方便。StarTeam的图形化界面，能够使初学者易于接收，而且其缺陷控制功能的功能（基于数据库的Change&Request），是相应工具中独树一帜的。
缺点：不支持并行开发，不能很好解决Merge的问题；不支持分支的自动合并，需要手动来处理；速度慢，一定程度上影响开发效率；故障恢复困难，需要有专职管理员维护；没有中文版本；另外，StarTeam集成度较高，移植过程复杂，需要的管理负担大，需要完善的备份计划。
GIT（开源分布式）
GIT&是一款免费的、开源的、分布式的版本控制系统。旨在快速高效地处理无论规模大小的任何软件工程。与常用的版本控制工具&CVS,&Subversion&等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。每一个GIT克隆都是一个完整的文件库，含有全部历史记录和修订追踪能力。其最大特色就是&分支&及&合并&操作快速、简便。支持离线工作，GIT是整个项目范围的原子提交，而且GIT中的每个工作树都包含一个具有完整项目历史的仓库。
GIT&本来是面向&Linux&操作系统开发的软件。在&Linux&平台上使用GIT非常简单，都是命令行模式。但对windows以及中文的支持不是很好。
Mercurial（开源分布式）
Mercurial&是一种轻量级分布式版本控制系统，采用&Python&语言实现，易于学习和使用，扩展性强。其是基于&GNU&General&Public&License&(GPL)&授权的开源项目。
相对于传统的版本控制，具有如下优点：
更轻松的管理。传统的版本控制系统使用集中式的reptory，一些和repository相关的管理就只能由管理员一个人进行。由于采用了分布式的模型，Mercurial&中就没有这样的困扰，每个用户管理自己的repository，管理员只需协调同步这些repository。
更健壮的系统。分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统通常不会因为一两个节点而受到影响。
对网络的依赖性更低。由于同步可以放在任意时刻进行，Mercurial&甚至可以离线进行管理，只需在有网络连接时同步。
简单易学、易于使用；轻量级，运行快速；可扩展性，易于根据用户需求自行定义、扩展。
Monotone（开源分布式）
Monotone是一个免费的分布式版本管理系统。提供了简单的文件事务版本存储，可离线操作，高效的点对点同步协议，支持历史版本敏感的合并操作、轻量级分支处理以及集成代码评审和第三方测试工具。使用加密的版本命令方式和客户端&RSA&认证，很好的支持国际化，不依赖第三方工具，支持跨平台。&可运行在Linux，Solaris，Mac&OSX，Windows和其他Unixes上，遵循GPL协议。
5.SVN和GIT的区别
SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。
git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。[2]&&Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
1.GIT是分布式的，SVN不是：
这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如,&等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。
GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。
同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。就是一个这样的优秀案例。
有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。
2.GIT把内容按元数据方式存储，而SVN是按文件：
所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。
3.GIT分支和SVN的分支不同：
分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。
然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。
4.GIT没有一个全局的版本号，而SVN有：
目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。
更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。
5.GIT的内容完整性要优于SVN：
GIT的内容存储使用的是哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
阅读(...) 评论()版本控制的使用
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 官网下载：
TortoiseSVN 官网下载：
如上图箭头所示，在安装 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 官网下载：
TortoiseGit 官网下载：
如上图标注 1 所示，确定好该路径下是否有对应的可执行文件。
Github 的配置和使用
如上图标注 1 所示，填写你的 Github 登录账号和密码，点击 Test 可以进行测试是否可以正确连上。
如上图标注 1 所示，支持直接从你当前登录的 Github 账号上 Checkout 项目。
如上图标注 1 所示，支持把当前本地项目分享到你的 Github 账号上。
如上图标注 1 所示，支持创建 Gist。Github 的 Gist 官网地址：
版本控制主要操作按钮
如上图标注 1 所示，对目录进行右键弹出的菜单选项。
如上图标注 1 所示，对文件进行右键弹出的菜单选项。
如上图标注红圈所示，为工具栏上版本控制操作按钮，基本上大家也都是使用这里进行操作。
第一个按钮：Update Project 更新项目。
第二个按钮：Commit changes 提交项目上所有变化文件。点击这个按钮不会立马提交所有文件，而是先弹出一个被修改文件的一个汇总框，具体操作下面会有图片进行专门介绍。
第三个按钮：Compare with the Same Repository Version 当前文件与服务器上该文件通版本的内容进行比较。如果当前编辑的文件没有修改，则是灰色不可点击。
第四个按钮：Show history 显示当前文件的历史记录。
第五个按钮：Revert 还原当前被修改的文件到未被修改的版本状态下。如果当前编辑的文件没有修改，则是灰色不可点击。
如上图标注 1 所示，菜单栏上的版本控制操作区。
版本控制相关的常用设置说明
如上图标注 1 所示，当前项目使用的版本控制是 Git。如果你不愿意这个项目继续使用版本控制可以点击旁边的减号按钮，如果你要切换版本控制，可以点击 Git，会出现 IntelliJ IDEA 支持的各种版本控制选择列表，但是我们一般情况下一个项目不会有多个版本控制的。
如上图标注 2 所示，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 表示弹出提示选项，让开发者决定这些被删除的是否从版本控制中删除。如果不想弹出提示，则选择下面两个选项进行默认操作。
如上图标注 1 所示，对于不想加入到版本控制的文件，可以添加要此忽略的列表中。但是如果已经加入到版本控制的文件使用此功能，则表示该文件 或 目录无法再使用版本控制相关的操作，比如提交、更新等。我个人使用过程中发现在 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 进行更新，正常就可以了。
输错密码后，弹出验证的登录框没有再出现：
解决办法如下图：选择 Do not save, forget passwords after restart 等你确定你的密码没错后再选择保存密码方案。
Git Flow 的介绍
Git Flow 概念
Git Flow 是一个 git 扩展集，按 Vincent Driessen 的分支模型提供高层次的库操作。这里的重点是 Vincent Driessen 的分支模型思想，下面讲解的内容也是基于 Vincent Driessen 思想。
Vincent Driessen 的观点：
Git Flow 是一个 git 扩展集 你可以理解 Git Flow 是一个基于 Git 的插件，这个插件简化了 Git 一些复杂的命令，比如 Git Flow 用一条命令，就可以代替 Git 原生 10 条命令。
Git Flow 对原生的 Git 不会有任何影响，你可以照旧用 Git 原生命令，也可以使用 Git Flow 命令。
还有其他的一些分支管理模型思想，具体可以看：
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 情况
Git Flow 安装
Windows：如果你安装 Git 用的是 ，那它已经内置了。
Mac：brew install git-flow-avh
Linux：wget --no-check-certificate -q
/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh && sudo bash gitflow-installer. rm gitflow-installer.sh
更多版本：
在系统环境上支持之后，再安装 IntelliJ IDEA 对 Git Flow 支持的插件：
Git Flow 基础命令资料
Git Flow Integration 插件的使用
如果你已经理解了上面的理论，再看下面这些截图你能理解对应的是什么意思。