非程序员如何使用 Git——版本控制你的生活

oschina
 oschina
发布于 2014年05月19日
收藏 98

在协同工作和版本控制方面,Git 绝对是一个优秀的工具,但其优点并不被大众所熟知。在过去的几年中,由于大众对于文字处理,电子表格(译者注:这里暗指Word和Excel,下同。)以及其他常用的功能的需求,优秀的协作工具(比如Google Drive)变得越来越受欢迎。然而,这些工具并没有提供好用的版本控制功能——它们只能线性的前进或回退到某一步(版本)上。

如果我们希望通过同一文件不同的版本去测试某个问题的不同方法,或者在同一个内容上做操作,同时又不希望影响到别人或创建一个新的文件,这些工具显 然没办法实现。对于每一个在办公室工作的非程序员,大概都遇到过要把一个工程迅速移动到打有时间戳的文件夹中,这些文件夹又都包含同一个文件。如果你和我 一样,可能会想到把这些文件都放在一个共享网盘中,你可能在这场“游戏”中领先了一步。可惜的是,现状可能就是这样,这也使你在这场“游戏”中,没有任何 借口不去使用Git的那些功能。没错——Git不仅仅能用来编程。

这看起来似乎是个疯狂的主意——Git生来就不是用于处理电子表格和文字处理的。好吧,你知道什么才听起来更疯狂吗?就是把许多含有时间戳的文件放 在每一个人的硬盘中!学会git add,commit,branch,merge和push的使用方法非常简单,而且会让你受益匪浅。

电子表格的版本控制

我们先在MS Excel中试试版本控制。我们可以先创建一个简单的电子表格比如XLSX(Excel表格的默认类型),XLS(比XLSX更高级)和CSV(用逗号分 隔内容)。对于每一个文件的变化,我们创建一个新的分支,加入并提交我们对文件的修改,然后切换回我们的主分支并合并两个分支。

(译注:本文这里没有说的很清楚,拿下文第一个测试为例,作者意思是先对这个编辑好的表格创建新的分支,并在新的分支上删除一行,添加并提交修改,再切换回主分支,合并两个分支,即可看到变化。下同。)
1

首先,我们对这个电子表格做一些简单的编辑。我们删除其中一行。
2

这里应该没什么问题。下一步,我们做一些更进一步的修改,我们要加入一些简单的公式(不能加在CSV中,这种类型文件不支持公式)。
3

很好!我们再快速做一个测试——看看当我们编辑文字类型后会有什么变化,比如修改文字颜色或背景颜色。
4

同样成功了!太棒了——Git对电子表格足够的智能,可以根据变化创建分支,做出改变并合并回同一个分支。

文字处理的版本控制

接下来该说文字处理了。我们将会按照上面对电子表格一样的处理流程——创建一个新的分支,添加和提交修改,然后切换回主分支在合并两个分支。
5
效果很好。如果你仔细想想,就会发觉文本文件中的内容与HTML文件中的内容基本上是一回事——它们都是不同语言的纯文本。或者说,它们近乎是相同的,除非你修改你的word文档,比如修改所有的空格,文本类型,颜色或其他什么的。看看那会发生什么?
6
好吧,没能成功。令人惊讶的是,当我们不修复冲突并试图合并时,似乎Git报出了警告信息。当然,我们还是可以继续编辑内容。只要我们在演示之前修改我们的内容,就不会有问题。

协作的好处

我们仅仅说了Git版本控制的好处,但是它的协作特性也非常有用。如果你在协作中用到了Github,你和你的小伙伴们都会接触到其更高级的特性。 比如,你可以根据同一个仓库(用来放置文件的地方,译者注)创建一个自己的分支(fork)或拷贝(clone)其一份,对同一个或同一批文件进行操作, 然后更新(push,与后面的pull作用都与公共版本库进行交互,负责更新和同步,译者注)或给团队的队长(比如编辑人员)发一封同步(pull)请 求,以便他可以进行查看。队长甚至可以仅仅选择同意加入某些特定同步请求并拒绝加入其它的同步请求。而且他不需要下载同一个含有相同名字文件或文件夹的二 十个版本,并搞乱自己的桌面。

需要记住的事情

Git也有它的局限性。如果你对一个大文件做了很多大的修改,Git可能会做出奇怪的回应并卡住不动,它会报出基本上处处都存在冲突。虽然这很让人头疼,但是Git至少不会提示一大堆的警告并破坏了你的文件。

建议你将文件按照内容和类型进行分类。Git是为了处理代码的变化而生,这些代码其实都是文本。只要你的工作是处理文本内容,使用Git就不会有问题。而且,你的文件类型越单一,Git就会处理的越好。Github的更新请求功能让人赞叹。

不幸的是,你不能预览某个特定类型的文件的更新请求,比如DOCX,XLSX和其他常用的文件类型。不过,这个功能还可能会对其他类型的文件管用——去找找看!或者把你的文件转换成Github能够接受的文件类型。

TL;DR

我是否应该给一堆文件打上时间戳,把它们丢进文件夹中,并给和我一起工作小伙伴们都发上一封邮件?

欢迎大家使用 http://git.oschina.net/

原文链接: Pat Whitrock   翻译: 伯乐在线 - yuliu
译文链接: http://blog.jobbole.com/67393/

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:非程序员如何使用 Git——版本控制你的生活
加载中

最新评论(36

久永
久永

引用来自“蛋蛋为何忧伤”的评论

作为一个程序员,觉得git "专业",我就真的没什么可说的了....

引用来自“久永”的评论

无知者才无畏,只有程序员觉得git专业才对~内行看门道 叫专业,外行看热闹,会觉得叫复杂才对~
觉不觉得专业也要看到你用到什么程度才是~

引用来自“jiechic”的评论

说多了都是累,身边的程序员都不会用git,还是互联网工程师。
开发的大部分还不会用呢~好不好,要都用过才好做比较~
jiechic
jiechic

引用来自“蛋蛋为何忧伤”的评论

作为一个程序员,觉得git "专业",我就真的没什么可说的了....

引用来自“久永”的评论

无知者才无畏,只有程序员觉得git专业才对~内行看门道 叫专业,外行看热闹,会觉得叫复杂才对~
觉不觉得专业也要看到你用到什么程度才是~
说多了都是累,身边的程序员都不会用git,还是互联网工程师。
周星_1980
周星_1980
早就有人在github上一起写小说了,不过都是在开心白日梦的实现之后的事情了
南湖船老大
南湖船老大
git 确实很难用,全平台搭建服务器就是最大的难点,SVN就简单多了。
另外,GIT的概念太多,就像C++一样,想不复杂也不行。有人会说你可以不用那些复杂的指令啊,但别人用到了,你就得知道,学习成本变得越来越大。
谁不服的话,谁写篇博客来反驳。
射落白羊
射落白羊
反正latex写文章配合git非常好
明睿Evan
明睿Evan
对于GIT我是小白,想请教一下,GIT能不能搭建一个类似于SVN和MFS的服务器?我翻看了很多书籍,都没找到有效的方法。
e
everthis

引用来自“Neo_”的评论

有同步云还用 git ?
呵呵!
橙汁儿
橙汁儿

引用来自“久永”的评论

git太专业了~虽然很好,部分程序员都没信心搞,更别论其它行业了~

引用来自“JeffreyWu”的评论

小姐笑了

引用来自“久永”的评论

别做让人鄙视的批评家,说出你的道理来大家讨论讨论~
不是批评人家是建议
canfoderiskii
canfoderiskii
git没用成,服务器搭建有问题,vshell作为SSH服务器,客户端使用git clone ssh://user@ip/path弄死不行...
原因是vshell默认调用cmd作为非交互shell而且git使用单引号将路径括起来传输,而cmd不将单引号识别为参数识别符,反而作为参数的一部分,这样得到的路径就是错的,导致git使用有问题。
stackoverflow也有人问类似的问题。
要么等git自己将传参数的单引号改成双引号,要么要在服务器添加额外的脚本,并且客户端使用git clone -u "xxx.sh"指令才行。
好麻烦的说。。。

用COPSSH或者OpenSSH假设SSH服务器不会遇到这个问题,但是用户能有一个的样子,而且管理操作,远不如Vshell方便的样子
返回顶部
顶部