Solidity是一种语法类似JavaScript的高级语言。它被设计成以编译的方式生成以太坊虚拟机代码。在后续内容中你将会发现，使用它很容易创建用于投票、众筹、封闭拍卖、多重签名钱包等等的合约。注意目前尝试Solidity的最好方式是使用基于浏览器的编译器（需要一点时间加载，请耐心等待）。
欢迎各路区块链及以太坊领域的专家和爱好者参与这一翻译项目，我们会为每位翻译和校对人员署名。特别介绍Solidity 官方文档前一版已经翻译完成90％,内容需要更新。前一版贡献者名单：少平abao志伟jinfengbc大青蛙zhangyaning内容来源英文官方网站：https://solidity.readthedocs.io/官方GitHub仓库：https://github.
有一些Git的问题，我已经藏在毯子下面了。有些可以通过脚本或回调方法轻易地解决，有些需要重组或重定义项目，少数剩下的烦恼，还只能等待。或者更好地，投入进来帮忙。SHA1 的弱点随着时间的推移，密码学家发现越来越多的SHA1的弱点。已经发现对对资源雄厚的组织哈希冲撞是可能的。在几年内，或许甚至一个一般的PC也将有足够计算能力悄悄摧毁一个Git仓库。
我们揭开Git神秘面纱，往里瞧瞧它是如何创造奇迹的。我会跳过细节。更深入的描述参见 用户手册。大象无形Git怎么这么谦逊寡言呢？除了偶尔提交和合并外，你可以如常工作，就像不知道版本控制系统存在一样。那就是，直到你需要它的时候，而且那是你欢欣的时候，Git一直默默注视着你。其他版本控制系统强迫你与繁文缛节和官僚主义不断斗争。
到现在，你应该有能力查阅 git help 页，并理解几乎所有东西。然而，查明解决特定问题需要的确切命令可能是乏味的。或许我可以省你点功夫：以下是我过去曾经需要的一些食谱。源码发布就我的项目而言，Git完全跟踪了我想打包并发布给用户的文件。创建一个源码包，我运行： $ git archive --format=tar --prefix=proj-1.2.
我最初在一个私人项目上使用Git，那里我是唯一的开发。在与Git分布式本性有关的命令中，我只用到了 pull 和 clone，用以在不同地方保持同一个项目。后来我想用Git发布我的代码，并且包括其他贡献者的变更。我不得不学习如何管理有来自世界各地的多个开发的项目，幸运的是，这是Git的长处，也可以说是其存在的理由。我是谁？
Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需要小心：只重写你独自拥有的那部分。正如民族间会无休止的争论谁犯下了什么暴行一样，如果在另一个人的克隆里，历史版本与你的不同，当你们的树互操作时，你会遇到一致性方面的问题。一些开发人员强烈地感觉历史应该永远不变，不好的部分也不变所有都不变。另一些觉得代码树在向外发布之前，应该整得漂漂亮亮的。
即时分支合并是Git最给力的杀手锏。问题 ：外部因素要求必须切换场景。在发布版本中突然蹦出个严重缺陷。某个特性完成的截至日期就要来临。在项目关键部分可以提供帮助的一个开发正打算离职。所有情况逼迫你停下所有手头工作，全力扑到到这个完全不同的任务上。打断思维的连续性会使你的生产力大大降低，并且切换上下文也更麻烦，更大的损失。
在较老一代的版本控制系统里，checkout是获取文件的标准操作。你将获得一组特定保存状态的文件。在Git和其他分布式版本控制系统里，克隆是标准的操作。通过创建整个仓库的克隆来获得文件。或者说，你实际上把整个中心服务器做了个镜像。凡是主仓库上能做的事，你都能做。计算机间同步我可以忍受制作tar包或利用rsync来作备份和基本同步。
与其一头扎进Git命令的海洋中，不如来点基本的例子试试手。它们简单而且实用。实际上，在开始使用Git的头几个月，我所用的从来没超出本章介绍的内容。保存状态要不来点猛的？在做之前，先为当前目录所有文件做个快照，使用： $ git init $ git add .
我将用类比方式来介绍版本控制的概念。更严谨的解释参见维基百科版本修订控制条目。工作是玩我从小就玩电脑游戏。相反，我只是在长大后才开始使用版本控制系统。我想我并不特殊，并且，对比两者工作方式可使这些概念更易解释，也易于理解。编写代码，或编辑文档和玩游戏差不多。在你做出了很多进展之后，你最好保存一下。
Git 教程是以技巧入手，理解每个小技巧如何工作，以及如何组合这些技巧以满足你的需求。
用 git grep 命令查找 Git 库里面的某段文字是很方便的。当然，你也可以用 Unix 下的grep命令进行搜索，但是git grep命令能让你不用签出(checkout)历史文件，就能查找它们。例如，你要看git.git这个仓库里每个使用xmmap函数的地方，你可以运行下面的命令：$ git grep xmmapconfig.c: contents = xmmap(NULL, contents_sz, PROT_READ,diff.c: s->
这里我们要看一下：Git 的客户端和服务器如何交互传输数据。通过 HTTP 协议抓取通过 http 协议的 url 进行的 git 数据抓取，使用了一个比较傻瓜化(dumber)的协议。使用 http 协议，所有的逻辑计算(logic)都是在客户端进行。服务器不需要特别的设置，你只要把 git 目录放到一个可以访问的 web 目录即可。
这一章我们会学习如何在更低的层次操作 Git，以防你需要自己写一个新工具去人工生成 blob(块)，tree(树)或者 commit(提交)对象。如果你想使用更加底层的 Git 命令去写脚本，你会需要用到以下的命令。创建 blob 对象在你的 Git 仓库中创建一个 blob 对象并且得到它的SHA值是很容易的，使用git hash-object就足够了。
这一章将详细描述打包文件(packfile)和打包文件索引(packfile index)的格式。打包文件索引首先，我们来看一下打包文件索引，基本上它只是一系列指向打包文件内位置的书签。打包文件索引有两个版本。版本 1 的格式用于 Git 1.6 版本之前，版本 2 的格式用于 Git 1.6 及以后的版本。 但是版本 2 可以被 Git 1.5.2 及以上的 Git 读取，同时也被后向移植(backport)到了 1.4.4.
Git 索引是一个在你的工作目录和项目仓库间的暂存区(staging area)。有了它，你可以把许多内容的修改一起提交(commit)。如果你创建了一个提交(commit)，那么提交的是当前索引(index)里的内容，而不是工作目录中的内容。查看索引使用 git status 命令是查看索引内容的最简单办法。你运行 git status 命令，就可以看到；
分支(branch)，远程跟踪分支(remote-tracking branch)以及标签(tag)都是对提交的引用。所有的引用是用‘refs’开头，以斜杠分割的路径。到目前为此，我们用到的引用名称其实是它们的简写版本：分支test是refs/heads/test的简写.标签v2.6.18是refs/tags/v2.6.18的简写.origin/master是refs/remotes/origin/master的简写.
我们可以使用cat-file命令去查询特定对象的信息。注意下面只键入了 SHA 值的一部分，不必把 40 个字符全部键入：$ git-cat-file -t 54196cc2commit$ git-cat-file commit 54196cc2tree 92b8b694ffb1675e5975148e1121810081dbdffeauthor J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500committer J. Bruce Fields <bfields@puzzle.fieldses.
这一章会详细讲解 Git 如何物理存储各对象。所有的对象都以 SHA 值为索引用 gzip 格式压缩存储，每个对象都包含了对象类型，大小和内容。Git 中存在两种对象 - 松散对象(loose object)和打包对象(packed object)。松散对象松散对象是一种比较简单格式。它就是磁盘上的一个存储压缩数据的文件。每一个对象都被写入一个单独文件中。
关注时代Java
