关于 Java 插件Gradle 是一个通用的构建工具，它能构建任何基于你的构建脚本的东西。开箱即用，当然除非你添加代码到你的构建脚本里，不然它不会构建任何东西。很多 Java 项目都有类似的基本流程：编译 Java 源文件，运行单元测试，创建 JAR 文件。如果你不是把代码从头写到尾，那还能接受。现在有了 Gradle 就不用忍受这些。解决问题的方法就是 插件。
在 Gradle 中两个顶级概念：project（项目）和 task （任务）所有 Gradle 都有一个或多个 project 构成。project 的展现取决于 Gradle 所做的工作。举例。 project 可以是一个 JAR 库 或者是 web 应用。它可以是由项目生产 JAR 组成发布的 ZIP。一个 project 不一定代表一个东西要构建。它可能是一件要做的事，如将应用程序部署到工作台或生产环境。
处理问题当你遇到问题，首先是更新到最新版本。最新版一般是修复了 bug 和添加了新特性。如果您使用的是 Gradle Daemon 守护进程，尝试暂时禁用该守护进程（您可以通过命令行 --no-daemon）。有关故障排除的守护进程的更多信息，位于Chapter 19. The Gradle Daemon 守护进程获取帮助在线论坛http://forums.gradle.org. 可以提问或者建议。
前置条件Gradle 需要 Java JDK 或者 JRE，版本是 6 及以上。Gradle 将会装载自己的 Groovy 库，因此，Groovy 不需要被安装。任何存在的 Groovy 安装都会被 Gradle 忽略。Gradle 使用你 path 中的 JDK,或者，您可以设置 java_home 环境变量来指向所需的 JDK 安装目录。下载下载 Gradle 的发布包.解压Gradle 的发布包被打包成 ZIP。
特性下面列出了一些 Gradle 的特性：声明式构建，符合公约gradle 的核心是在 基于 Groovy 对 Domain Specific Language (DSL)语言进行一个丰富的扩展。根据喜好，Gradle 将陈述建立下一级提供声明性语言元素。这些元素也提供支持 Java，Groovy，OSGi，Web和Scala 项目。甚至更多，这说明语言是可扩展的。
Gradle 为Java（JVM）世界提供快速构建的工具。提供如下功能：一个非常灵活的通用构建工具,如 Ant方便从 Maven 中切换过来。但我们从不强制对多项目构建非常支持很强的依赖性管理（基于 Apache Ivy）对你现有的 Maven 或者 Ivy 库全力支持支持传递依赖管理，不需要远程仓库或者 pom.xml 和 ivy.
Gradle 是一款基于 Groovy 语言的构建工具，它既保持了 Maven 的优点，又通过使用 Groovy 定义的 DSL 克服了 Maven 中使用 XML 繁冗以及不灵活的缺点。Gradle 2.0 是 Gradle 版本发展史上的一个重要里程碑，大版本的发布意味着 Gradle 更加成熟。新版本的 Gradle 除修复了大量Bug外，还移除了很多已经过时的特性以及 API，并引入了依赖管理系统，并加入对 Java 8 的支持。
在远程仓库一节中，我们讲了远程仓库实际上和本地仓库没啥不同，纯粹为了 7x24 小时开机并交换大家的修改。GitHub 就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给 GitHub 交保护费，那就只能自己搭建一台 Git 服务器作为私有仓库使用。
有没有经常敲错命令？比如 git status？status 这个单词真心不好记。如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。我们只需要敲一行命令，告诉 Git，以后 st 就表示 status：$ git config --global alias.st status好了，现在敲git st看看效果。
在 安装 Git一节中，我们已经配置了 user.name 和 user.email，实际上，Git 还有很多可配置项。比如，让 Git 显示颜色，会让命令输出看起来更醒目：$ git config --global color.ui true这样，Git 会适当地显示不同的颜色，比如git status命令：文件名就会标上颜色。我们在后面还会介绍如何更好地配置 Git，以便让你的工作更高效。
我们一直用 GitHub 作为免费的远程仓库，如果是个人的开源项目，放到 GitHub 上是完全没有问题的。其实 GitHub 还是一个开源协作社区，通过 GitHub，既可以让别人参与你的开源项目，也可以参与别人的开源项目。
如果标签打错了，也可以删除：$ git tag -d v0.1Deleted tag 'v0.1' (was e078af9)因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。如果要推送某个标签到远程，使用命令git push origin <tagname>：$ git push origin v1.0Total 0 (delta 0), reused 0 (delta 0)To git@github.com:michaelliao/learngit.
发布一个版本时，我们通常先在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。Git 的标签虽然是版本库的快照，但其实它就是指向某个 commit 的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。
当你从远程仓库克隆时，实际上 Git 自动把本地的 master 分支和远程的 master 分支对应起来了，并且，远程仓库的默认名称是 origin。要查看远程库的信息，用git remote：$ git remoteorigin或者，用git remote -v显示更详细的信息：$ git remote -vorigin git@github.com:michaelliao/learngit.git (fetch)origin git@github.com:michaelliao/learngit.
软件开发中，总有无穷无尽的新的功能要不断添加进来。添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。现在，你终于接到了一个新任务：开发代号为 Vulcan 的新功能，该功能计划用于下一代星际飞船。
软件开发中，bug 就像家常便饭一样。有了bug就需要修复，在 Git 中，由于分支是如此的强大，所以，每个 bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
通常，合并分支时，如果可能，Git 会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用 Fast forward 模式，Git 就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。
人生不如意之事十之八九，合并分支往往也不是一帆风顺的。准备新的 feature1 分支，继续我们的新分支开发：$ git checkout -b feature1Switched to a new branch 'feature1'修改 readme.txt 最后一行，改为：Creating a new branch is quick AND simple.在 feature1 分支上提交：$ git add readme.
在版本回退里，你已经知道，每次提交，Git 都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在 Git 里，这个分支叫主分支，即 master 分支。HEAD 严格来说不是指向提交，而是指向 master，master 才是指向提交的，所以，HEAD指向的就是当前分支。
分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 Git 的时候，另一个你正在另一个平行宇宙里努力学习 SVN。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 Git 又学会了 SVN！分支在实际中有什么用呢？
关注时代Java
