版本控制Git（全集）
1.1 版本控制的方式
(1) 集中式版本控制工具：集中式版本控制工具，版本库是集中存放在中央服务器的，team里每个人work时从中央服务器下载代码，是必须联网才能工作，局域网或互联网。个人修改后然后提交到中央版本库。
举例：SVN和CVS
(2) 分布式版本控制工具：分布式版本控制系统没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样工作的时候，无需要联网了，因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方，就能互相看到对方的修改了。
举例：Git
1.2 Git
Git是分布式的，Git不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用Git并且有个中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的PC是一样的。我们可以把它当做一个开发者的pc就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不过“交换”修改不方便而已。
git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Git是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。 同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众多的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002 年间）。到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代 码。
到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标：
速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
1.3 Git工作流程
命令如下：
clone（克隆）: 从远程仓库中克隆代码到本地仓库
checkout （检出）:从本地仓库中检出一个仓库分支然后进行修订
add（添加）: 在提交前先将代码提交到暂存区
commit（提交）: 提交到本地仓库。本地仓库中保存修改的各个历史版本
fetch (抓取) ： 从远程库抓取到本地仓库，不进行任何的合并动作，一般操作比较少。
pull (拉取) ： 从远程库拉到本地库，自动进行合并(merge)，然后放到到工作区，相当于
fetch+merge
push（推送） : 修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库
2.1 Git常用指令
要使用Git对我们的代码进行版本控制，首先需要获得本地仓库
在电脑的任意位置创建一个空目录（例如test）作为我们的本地Git仓库
进入这个目录中，点击右键打开Git bash窗口
执行命令git init
如果创建成功后可在文件夹下看到隐藏的.git目录
2.2 Git分支常用指令
2.3 开发中分支使用原则与流程
几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。
在开发中，一般有如下分支使用原则与流程：
master （生产） 分支：线上分支，主分支，中小规模项目作为线上运行的应用对应的分支；
develop（开发）分支：是从master创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到master分支，准备上线。
feature/xxxx分支：从develop创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完成后合并到develop分支，之后该分支可以删除。
hotfix/xxxx分支：从master派生的分支，一般作为线上bug修复使用，修复完成后需要合并到master、test、develop分支。
还有一些其他分支，在此不再详述，例如test分支（用于代码测试）、pre分支（预上线分支）等
等。
4.1 在idea中配置git
4.2 在idea中操作git
4.2.1 创建项目远程仓库
4.2.2 初始化本地仓库
4.2.3 提交到本地仓库
4.2.4 推送到远程仓库
4.2.5 克隆远程仓库到本地仓库
4.2.6 创建分支
4.2.7 切换分支及其他分支相关操作
IDEA集成GitBash作为Terminal
