文字处理的版本控制 接下来该说文字处理了。我们将会按照上面对电子表格一样的处理流程——创建一个新的分支,添加和提交修改,然后切换回主分支在合并两个分支。 效果很好。如果你仔细想想,就会发觉文本文件中的内容与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/ |