在协同工作和版本控制方面，Git 绝对是一个优秀的工具，但其优点并不被大众所熟知。在过去的几年中，由于大众对于文字处理，电子表格（译者注：这里暗指Word和Excel，下同。）以及其他常用的功能的需求，优秀的协作工具（比如Google Drive）变得越来越受欢迎。然而，这些工具并没有提供好用的版本控制功能——它们只能线性的前进或回退到某一步（版本）上。 如果我们希望通过同一文件不同的版本去测试某个问题的不同方法，或者在同一个内容上做操作，同时又不希望影响到别人或创建一个新的文件，这些工具显 然没办法实现。对于每一个在办公室工作的非程序员，大概都遇到过要把一个工程迅速移动到打有时间戳的文件夹中，这些文件夹又都包含同一个文件。如果你和我 一样，可能会想到把这些文件都放在一个共享网盘中，你可能在这场“游戏”中领先了一步。可惜的是，现状可能就是这样，这也使你在这场“游戏”中，没有任何 借口不去使用Git的那些功能。没错——Git不仅仅能用来编程。 这看起来似乎是个疯狂的主意——Git生来就不是用于处理电子表格和文字处理的。好吧，你知道什么才听起来更疯狂吗？就是把许多含有时间戳的文件放 在每一个人的硬盘中！学会git add，commit，branch，merge和push的使用方法非常简单，而且会让你受益匪浅。 电子表格的版本控制 我们先在MS Excel中试试版本控制。我们可以先创建一个简单的电子表格比如XLSX（Excel表格的默认类型），XLS（比XLSX更高级）和CSV（用逗号分 隔内容）。对于每一个文件的变化，我们创建一个新的分支，加入并提交我们对文件的修改，然后切换回我们的主分支并合并两个分支。 （译注：本文这里没有说的很清楚，拿下文第一个测试为例，作者意思是先对这个编辑好的表格创建新的分支，并在新的分支上删除一行，添加并提交修改，再切换回主分支，合并两个分支，即可看到变化。下同。）
首先，我们对这个电子表格做一些简单的编辑。我们删除其中一行。
这里应该没什么问题。下一步，我们做一些更进一步的修改，我们要加入一些简单的公式（不能加在CSV中，这种类型文件不支持公式）。
很好！我们再快速做一个测试——看看当我们编辑文字类型后会有什么变化，比如修改文字颜色或背景颜色。
同样成功了！太棒了——Git对电子表格足够的智能，可以根据变化创建分支，做出改变并合并回同一个分支。 文字处理的版本控制 接下来该说文字处理了。我们将会按照上面对电子表格一样的处理流程——创建一个新的分支，添加和提交修改，然后切换回主分支在合并两个分支。
效果很好。如果你仔细想想，就会发觉文本文件中的内容与HTML文件中的内容基本上是一回事——它们都是不同语言的纯文本。或者说，它们近乎是相同的，除非你修改你的word文档，比如修改所有的空格，文本类型，颜色或其他什么的。看看那会发生什么？
协作的好处 我们仅仅说了Git版本控制的好处，但是它的协作特性也非常有用。如果你在协作中用到了Github，你和你的小伙伴们都会接触到其更高级的特性。 比如，你可以根据同一个仓库（用来放置文件的地方，译者注）创建一个自己的分支（fork）或拷贝（clone）其一份，对同一个或同一批文件进行操作， 然后更新（push，与后面的pull作用都与公共版本库进行交互，负责更新和同步，译者注）或给团队的队长（比如编辑人员）发一封同步（pull）请 求，以便他可以进行查看。队长甚至可以仅仅选择同意加入某些特定同步请求并拒绝加入其它的同步请求。而且他不需要下载同一个含有相同名字文件或文件夹的二 十个版本，并搞乱自己的桌面。 需要记住的事情 Git也有它的局限性。如果你对一个大文件做了很多大的修改，Git可能会做出奇怪的回应并卡住不动，它会报出基本上处处都存在冲突。虽然这很让人头疼，但是Git至少不会提示一大堆的警告并破坏了你的文件。 建议你将文件按照内容和类型进行分类。Git是为了处理代码的变化而生，这些代码其实都是文本。只要你的工作是处理文本内容，使用Git就不会有问题。而且，你的文件类型越单一，Git就会处理的越好。Github的更新请求功能让人赞叹。 不幸的是，你不能预览某个特定类型的文件的更新请求，比如DOCX，XLSX和其他常用的文件类型。不过，这个功能还可能会对其他类型的文件管用——去找找看！或者把你的文件转换成Github能够接受的文件类型。 TL;DR我是否应该给一堆文件打上时间戳，把它们丢进文件夹中，并给和我一起工作小伙伴们都发上一封邮件？ 欢迎大家使用 http://git.oschina.net/ 译文链接： http://blog.jobbole.com/67393/ |
