在IT行业，一个团队在开发一个项目的时候往往要将代码托管到一个平台来完成各个版本，分支之间的协调，增加生产力。Git是一个开源的平台，许多知名的开源项目都使用了Git来管理它们的代码。但是，这样一个强大的工具难道是程序员的专享吗？
恐怕Git (pronunciation:/gɪt/)这东西能干的事情，要比它表面上所展现的，要强大得多。
忘了讲了，Git是一个分布式的版本控制系统，最初由Linus Torvalds编写，用作Linux内核代码的管理。Git --- The stupid content tracker, 傻瓜内容跟踪器。Linus Torvalds 是这样介绍 Git 的。在它推出后，Git在其它项目中也取得了很大成功，尤其是在Ruby社区中。目前，包括Rubinius和Merb在内的很多知名项目都使用了Git。Git同样可以被诸如Capistrano和Vlad the Deployer这样的部署工具所使用。使用者可以方便的克隆一个完整的代码仓库到本地，也可以将自己的代码上传到服务器。这个服务会自动记录更改，可供使用者随意的切换版本。它还可以对比不同版本的区别，可以生成差异文档以便发布升级等等……
但任何一个工具都有它的缺点，Git 所能记录更改的，仅有纯文本文档罢了。也就是说，如果你上传两幅图片,Git仅会记录两个图片文件，但当你问: ”hey, Git, 这个图片我都改动什么了？” Git也只能无可奈何地摇摇头 “主人……我不知道” 。而如果你让Git跟踪一个纯文本文档呢？例如所有程序的源代码都是纯文本文档，就是说其中存储的数据时纯粹的字符数据，也可以理解为就是.txt文本文档的内容，名字和后缀名比较特别罢了，Git就会跟你说 “主人，我跟你讲哦，你修改了这里，这里和这里，快夸夸我”
等等,这么一想，是不是只要是文本文档Git就能储存呢？那Git可真是太强大了。比如如果我和另外一个人一起完成毕业论文，我们在方寸之间挥毫泼墨，很快就完成了两篇论文--对，我们在细节上有些分歧，但到最后的时候，我们在Git上合并分支,于是就像基督教《圣经旧约》创世纪一篇所讲，And it was so（于是事就这样成了）。
再比如我和小明在一起写一本小说，我写了引子，他写了大纲。我们顺着大纲一路写下去，行文流利笔锋流畅。有一个晚上我喝高了，看着书中那个女孩心中不爽---于是她老公就死了。可第二天我酒醒了，回想起那些文字，不行！他不能就这么死了。于是我回滚一下……很好，一切就像没发生过一样。有些时候，在一个选择上我持向左走，而我的伙伴想写另外一条线，于是我们拆出来了一条分支，这样我接着写我的柴刀，他写他的好船。当然由于世界线的收束性我们写着写着想合并—这也不是什么困难的事。
Git在事实上的使用中也确实扮演了这样的角色。比如adobe做的一个非常漂亮的字体，日本的宪法，各种菜谱，书目的编辑，各种研究团队的研究项目，学术报告……
我相信看到这里你们的言行恐怕都亮了起来。搞设计的经常会遇到一遍遍修改的情况，这样的话我们可以每次保存都在Git上标一下，以后再改也不困难。但问题来了，我们编辑文档常用的.DOC文件其实并不是纯文本文档，有一个更好的选择是markdown语言，这是一个很简单的标记语言，和HTML的目的有异曲同工之妙，但他与之HTML来讲，要人类化的多得多。限于主主题问题md语言相关的就放到下一个帖子里唠唠吧。

说道Git，我们往往最先想到的就是GitHub。方便的使用，人性化的设计，这样，GitHub就相对来讲成为了一个全球知名的约基网站，在世界范围内的约炮能力宛若天朝的B站---分享，协作，沟通，评论。而这些足以使Git成为你新的社交平台。你可以上传你的文档，来讲Git作为一个数据库使用。而关于使用Git来作为数据库已经不是一个新的概念了。可以拿GitHub作为一个NoSQL数据库。它是一个很好的数据存储器，我们可以将你所编辑的文件PUSH到我们所能创建的私有仓库里。并且这个过程中是持续递增的，你不再需要不断地复制你的文件了——以免丢失造成的影响。而这相对于传统的编辑方式，最主要的是他是增量的，他是继承的。你的一次编辑会为所有使用者--包括你自己，在已有的文字中添加更多的事物，而你可以轻松地通过各种图表来知道这些东西人们喜不喜欢。
所以，在GitHub上创作往往是一个机遇，可能你会因为这个，拿到你所梦寐以求的offer。
好了就到这里我不想接着码了关于使用相关的会在未来的帖子里写。
ref：zhidao.baidu.com github.com www.csdn.net baike.baidu.com

在IT行业，一个团队在开发一个项目的时候往往要将代码托管到一个平台来完成各个版本，分支之间的协调，增加生产力。Git是一个开源的平台，许多知名的开源项目都使用了Git来管理它们的代码。但是，这样一个强大的工具难道是程序员的专享吗？
恐怕Git (pronunciation:/gɪt/)这东西能干的事情，要比它表面上所展现的，要强大得多。
忘了讲了，Git是一个分布式的版本控制系统，最初由Linus Torvalds编写，用作Linux内核代码的管理。Git --- The stupid content tracker, 傻瓜内容跟踪器。Linus Torvalds 是这样介绍 Git 的。在它推出后，Git在其它项目中也取得了很大成功，尤其是在Ruby社区中。目前，包括Rubinius和Merb在内的很多知名项目都使用了Git。Git同样可以被诸如Capistrano和Vlad the Deployer这样的部署工具所使用。使用者可以方便的克隆一个完整的代码仓库到本地，也可以将自己的代码上传到服务器。这个服务会自动记录更改，可供使用者随意的切换版本。它还可以对比不同版本的区别，可以生成差异文档以便发布升级等等……
但任何一个工具都有它的缺点，Git 所能记录更改的，仅有纯文本文档罢了。也就是说，如果你上传两幅图片,Git仅会记录两个图片文件，但当你问: ”hey, Git, 这个图片我都改动什么了？” Git也只能无可奈何地摇摇头 “主人……我不知道” 。而如果你让Git跟踪一个纯文本文档呢？例如所有程序的源代码都是纯文本文档，就是说其中存储的数据时纯粹的字符数据，也可以理解为就是.txt文本文档的内容，名字和后缀名比较特别罢了，Git就会跟你说 “主人，我跟你讲哦，你修改了这里，这里和这里，快夸夸我”
等等,这么一想，是不是只要是文本文档Git就能储存呢？那Git可真是太强大了。比如如果我和另外一个人一起完成毕业论文，我们在方寸之间挥毫泼墨，很快就完成了两篇论文--对，我们在细节上有些分歧，但到最后的时候，我们在Git上合并分支,于是就像基督教《圣经旧约》创世纪一篇所讲，And it was so（于是事就这样成了）。
再比如我和小明在一起写一本小说，我写了引子，他写了大纲。我们顺着大纲一路写下去，行文流利笔锋流畅。有一个晚上我喝高了，看着书中那个女孩心中不爽---于是她老公就死了。可第二天我酒醒了，回想起那些文字，不行！他不能就这么死了。于是我回滚一下……很好，一切就像没发生过一样。有些时候，在一个选择上我持向左走，而我的伙伴想写另外一条线，于是我们拆出来了一条分支，这样我接着写我的柴刀，他写他的好船。当然由于世界线的收束性我们写着写着想合并—这也不是什么困难的事。
Git在事实上的使用中也确实扮演了这样的角色。比如adobe做的一个非常漂亮的字体，日本的宪法，各种菜谱，书目的编辑，各种研究团队的研究项目，学术报告……
我相信看到这里你们的言行恐怕都亮了起来。搞设计的经常会遇到一遍遍修改的情况，这样的话我们可以每次保存都在Git上标一下，以后再改也不困难。但问题来了，我们编辑文档常用的.DOC文件其实并不是纯文本文档，有一个更好的选择是markdown语言，这是一个很简单的标记语言，和HTML的目的有异曲同工之妙，但他与之HTML来讲，要人类化的多得多。限于主主题问题md语言相关的就放到下一个帖子里唠唠吧。

说道Git，我们往往最先想到的就是GitHub。方便的使用，人性化的设计，这样，GitHub就相对来讲成为了一个全球知名的约基网站，在世界范围内的约炮能力宛若天朝的B站---分享，协作，沟通，评论。而这些足以使Git成为你新的社交平台。你可以上传你的文档，来讲Git作为一个数据库使用。而关于使用Git来作为数据库已经不是一个新的概念了。可以拿GitHub作为一个NoSQL数据库。它是一个很好的数据存储器，我们可以将你所编辑的文件PUSH到我们所能创建的私有仓库里。并且这个过程中是持续递增的，你不再需要不断地复制你的文件了——以免丢失造成的影响。而这相对于传统的编辑方式，最主要的是他是增量的，他是继承的。你的一次编辑会为所有使用者--包括你自己，在已有的文字中添加更多的事物，而你可以轻松地通过各种图表来知道这些东西人们喜不喜欢。
所以，在GitHub上创作往往是一个机遇，可能你会因为这个，拿到你所梦寐以求的offer。
好了就到这里我不想接着码了关于使用相关的会在未来的帖子里写。
ref：zhidao.baidu.com github.com www.csdn.net baike.baidu.com