Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Introduction enhancement

  • Loading branch information...
commit 68c21d3b51699d402627da0e3351e5fdc72173ff 1 parent f9bd062
@nanjj authored
Showing with 64 additions and 66 deletions.
  1. +32 −33 zh_cn/intro.txt
  2. +32 −33 zh_tw/intro.txt
View
65 zh_cn/intro.txt
@@ -5,45 +5,45 @@ http://en.wikipedia.org/wiki/Revision_control[维基百科版本修订控制条
=== 工作是玩 ===
-我几乎玩了一辈子电脑游戏。相反,我成人之后才开始使用版本控制系统。也许不止我
-一个人这样,对比两者工作方式可使概念更易解释,也易于理解。
+我从小就玩电脑游戏。相反,我只是在长大后才开始使用版本控制系统。我想我并不特
+殊,并且,对比两者工作方式可使这些概念更易解释,也易于理解。
-把编写代码或编辑文档与玩游戏类比。一旦有很多进展,你会喜欢存盘。去做这你会点
-击你的编辑器的存盘按钮
+编写代码,或编辑文档和玩游戏差不多。在你做出了很多进展之后,你最好保存一下。
+去做这个,会点击你所信任的编辑器保存按钮就好了
但这将覆盖老版本。就像那些学校里玩的老游戏,只有一个存档:你确实可以保存,但
-你不能回到之前的状态了。这真让人扫兴,可能之前状态恰好保存了这个游戏特别有意
-思一关,也许某天你想再玩一下。或者更糟糕的,你当前的存档是个必败的局,这样你
-就不得不从头开始玩了
+你不能回到更老的状态了。这真让人扫兴,因为那个状态可能恰好保存了这个游戏特别
+有意思一关,说不定哪天你想再玩一下呢。或者更糟糕的,你当前的保存是个必败局,
+这样你就不得不从头开始玩了
=== 版本控制 ===
在编辑的时候,如果想保留旧版本,你可以将文件“另存为”一个不同的文件,或在保
-存之前将文件拷贝到别处。你会把压缩这些文件节省空间。这是一个原始的劳动密集型
-的版本控制方式。游戏软件早就提高了这块,很多都提供多个基于时间戳的自动存档
+存之前将文件拷贝到别处。你可能压缩这些文件以节省空间。这是一个初级的靠手工的
+版本控制方式。游戏软件早就提高了这块,很多都提供多个基于时间戳的自动存档槽
-让我们看看稍稍复杂的情况。比如你有很多放在一起的文件,比如项目的源代码,或网
-站的文件。现在如果你想保留旧版本你不得存档整个目录。手工保存多个版本很不方便,
-很快会耗费巨大
+让我们看看稍稍复杂的情况。比如你有很多放在一起的文件,比如项目源码,或网站文
+件。现在如你想保留旧版本,你不得不把整个目录存档。手工保存多个版本很不方便,
+而且很快会耗费巨大
-一些电脑游戏的存档真的包含在一个充满文件的目录里。这些游戏为玩家屏蔽了具体细
-节,展现一个方便易用的界面来管理该目录的不同版本
+在一些电脑游戏里,一个存档真的包含在一个充满文件的目录里。这些游戏为玩家屏蔽
+了这些细节,并提供一个方便易用的界面来管理该目录的不同版本
-版本控制系统也没有两样。两者都有友好的界面来管理目录里的东西。你可以频繁保存,
-也可以之后加载任一保存。不像大多计算机游戏,版本控制系统通常精于节省存储空间。
-一般情况如果两个版本间只有少数文件的变更,每个文件的变更也不大,那就只存储差
-异的部分以节省存储空间,而不是把全部拷贝的都保存下来。
+版本控制系统也没有两样。两者提供友好的界面,来管理目录里的东西。你可以频繁保
+存,也可以之后加载任一保存。不像大多计算机游戏,版本控制系统通常精于节省存储
+空间。一般情况如果两个版本间只有少数文件的变更,每个文件的变更也不大,那就只
+存储差异的部分,而不是把全部拷贝的都保存下来,以节省存储空间
=== 分布控制 ===
-现在设想有一个很难的游戏。太难打了,以至于世界各地很多骨灰级玩家决定组队,
-享他们游戏存档以攻克它。Speedrun们就是实际中的例子:在同一个游戏里,玩家们分别
-攻克不同的等级,协同工作以创造惊人战绩。
+现在设想一个很难的游戏。太难打了,以至于世界各地很多骨灰级玩家决定组队,分享
+他们游戏存档以攻克它。Speedrun们就是实际中的例子:在同一个游戏里玩家们分别
+攻克不同的等级协同工作以创造惊人战绩。
-你如何搭建一个系统,使得他们易于得到彼此的所保存的?并易于上载新的
+你如何搭建一个系统,使得他们易于得到彼此的存档?并易于上载新的存档
在过去,每个项目都使用中心式版本控制。某个服务器上放所有保存的游戏记录。其他
-人都不用了。每个玩家在他们机器上最多保留几个游戏记录。当一个玩家想更新进度时
+人就不用了。每个玩家在他们机器上最多保留几个游戏记录。当一个玩家想更新进度时
候,他们需要把最新进度从主服务器下载下来,玩一会儿,保存并上载到主服务器以供
其他人使用。
@@ -64,33 +64,32 @@ http://en.wikipedia.org/wiki/Revision_control[维基百科版本修订控制条
=== 一个误区 ===
-一个很常见的错误观念是,分布式系统不适合需要官方中心仓库的项目。这与事实并
-不相符。给谁照相也不会偷走他们的灵魂。类似地,克隆主仓库并不降低它的重要性。
+一个很常见的错误观念是,分布式系统不适合需要官方中心仓库的项目。这与事实并不
+相符。给谁照相也不会偷走他们的灵魂。类似地,克隆主仓库并不降低它的重要性。
一般来说,一个中心版本控制系统能做的任何事,一个良好设计的分布式系统都能做得
更好。网络资源总要比本地资源耗费更费。不过我们应该在稍后分析分布式方案的缺点,
这样人们才不会按照习惯做出错误的比较。
-一个小项目或许只需要分布式系统提供的一小部分功能,但是,在你的项目很小的时候,
-说你应该用规划不好的系统,好比说,在计算较小数目的时候应该使用罗马数字吗
+一个小项目或许只需要分布式系统提供的一小部分功能,但是,在项目很小的时候,应
+该用规划不好的系统?就好比说,在计算较小数目的时候应该使用罗马数字
而且,你的项目的增长可能会超出你最初的预期。从一开始就使用Git好似带着一把瑞士
-军刀,尽管你很多时候只是用它来开开瓶盖。到你迫切需要一把改锥的那一天,你就会
-庆幸你有的不单单是一个启瓶器
+军刀,尽管你很多时候只是用它来开开瓶盖。某天你迫切需要一把改锥,你就会庆幸你
+所有的不单单是一个启瓶器
=== 合并冲突 ===
-对于这个话题,电脑游戏的类比显得太单薄了。那么让我们再来看看文档编辑的情况吧
+对于这个话题,电脑游戏的类比显得不够用。那让我们再来看看文档编辑的情况吧
假设Alice在文档开头插入一行,并且Bob在文档末尾添加一行。他们都上传了他们的改
动。大多数系统将自动给出一个合理的处理方式:接受且合并他们的改动,这样Alice和
Bob两人的改动都会生效。
现在假设Alice和Bob对文件的同一行做了不同的改动。如果没有人工参与的话,这个冲
-突是无法解决的。第二个人在上载文件时,会收到 _合并冲突_ 的通知,要么用一个人的
-改动覆盖另一个的,要么完全修订这一行。
+突是无法解决的。第二个人在上载文件时,会收到 _合并冲突_ 的通知,要么用一个人
+的改动覆盖另一个的,要么完全修订这一行。
更复杂的情况也可能出现。版本控制系统自己处理相对简单的情况,把困难的情况留给
人来处理。它们的行为通常是可配置的。
-
View
65 zh_tw/intro.txt
@@ -5,45 +5,45 @@ http://en.wikipedia.org/wiki/Revision_control[維基百科版本修訂控制條
=== 工作是玩 ===
-我几乎玩了一輩子電腦遊戲。相反,我成人之後才開始使用版本控制系統。也許不止我
-一個人這樣,對比兩者工作方式可使概念更易解釋,也易於理解。
+我從小就玩電腦遊戲。相反,我只是在長大後才開始使用版本控制系統。我想我並不特
+殊,並且,對比兩者工作方式可使這些概念更易解釋,也易於理解。
-把編寫代碼或編輯文檔與玩遊戲類比。一旦有很多進展,你會喜歡存檔。去做這你會點
-擊你的編輯器的存檔按鈕
+編寫代碼,或編輯文檔和玩遊戲差不多。在你做出了很多進展之後,你最好保存一下。
+去做這個,會點擊你所信任的編輯器保存按鈕就好了
但這將覆蓋老版本。就像那些學校裡玩的老遊戲,只有一個存檔:你確實可以保存,但
-你不能回到之前的狀態了。這真讓人掃興,可能之前狀態恰好保存了這個遊戲特別有意
-思一關,也許某天你想再玩一下。或者更糟糕的,你當前的存檔是個必敗的局,這樣你
-就不得不從頭開始玩了
+你不能回到更老的狀態了。這真讓人掃興,因為那個狀態可能恰好保存了這個遊戲特別
+有意思一關,說不定哪天你想再玩一下呢。或者更糟糕的,你當前的保存是個必敗局,
+這樣你就不得不從頭開始玩了
=== 版本控制 ===
在編輯的時候,如果想保留舊版本,你可以將檔案“另存為”一個不同的檔案,或在保
-存之前將檔案拷貝到別處。你會把壓縮這些檔案節省空間。這是一個原始的勞動密集型
-的版本控制方式。遊戲軟件早就提高了這塊,很多都提供多個基于時間戳的自動存檔
+存之前將檔案拷貝到別處。你可能壓縮這些檔案以節省空間。這是一個初級的靠手工的
+版本控制方式。遊戲軟件早就提高了這塊,很多都提供多個基于時間戳的自動存檔槽
-讓我們看看稍稍複雜的情況。比如你有很多放在一起的檔案,比如項目的原始碼,或網
-站的檔案。現在如果你想保留舊版本你不得存檔整個目錄。手工保存多個版本很不方便,
-很快會耗費巨大
+讓我們看看稍稍複雜的情況。比如你有很多放在一起的檔案,比如項目源碼,或網站文
+件。現在如你想保留舊版本,你不得不把整個目錄存檔。手工保存多個版本很不方便,
+而且很快會耗費巨大
-一些電腦遊戲的存檔真的包含在一個充滿檔案的目錄裡。這些遊戲為玩家屏蔽了具體細
-節,展現一個方便易用的界面來管理該目錄的不同版本
+在一些電腦遊戲裡,一個存檔真的包含在一個充滿檔案的目錄裡。這些遊戲為玩家屏蔽
+了這些細節,並提供一個方便易用的界面來管理該目錄的不同版本
-版本控制系統也沒有兩樣。兩者都有友好的界面來管理目錄裡的東西。你可以頻繁保存,
-也可以之後加載任一保存。不像大多計算機遊戲,版本控制系統通常精於節省存儲空間。
-一般情況如果兩個版本間只有少數檔案的變更,每個檔案的變更也不大,那就只存儲差
-異的部分以節省存儲空間,而不是把全部拷貝的都保存下來。
+版本控制系統也沒有兩樣。兩者提供友好的界面,來管理目錄裡的東西。你可以頻繁保
+存,也可以之後加載任一保存。不像大多計算機遊戲,版本控制系統通常精於節省存儲
+空間。一般情況如果兩個版本間只有少數檔案的變更,每個檔案的變更也不大,那就只
+存儲差異的部分,而不是把全部拷貝的都保存下來,以節省存儲空間
=== 分佈控制 ===
-現在設想有一個很難的遊戲。太難打了,以至于世界各地很多骨灰級玩家決定組隊,
-享他們遊戲存檔以攻克它。Speedrun們就是實際中的例子:在同一個遊戲裡,玩家們分別
-攻克不同的等級,協同工作以創造驚人戰績。
+現在設想一個很難的遊戲。太難打了,以至于世界各地很多骨灰級玩家決定組隊,分享
+他們遊戲存檔以攻克它。Speedrun們就是實際中的例子:在同一個遊戲裡玩家們分別
+攻克不同的等級協同工作以創造驚人戰績。
-你如何搭建一個系統,使得他們易於得到彼此的所保存的?並易於上載新的
+你如何搭建一個系統,使得他們易於得到彼此的存檔?並易於上載新的存檔
在過去,每個項目都使用中心式版本控制。某個伺服器上放所有保存的遊戲記錄。其他
-人都不用了。每個玩家在他們機器上最多保留幾個遊戲記錄。當一個玩家想更新進度時
+人就不用了。每個玩家在他們機器上最多保留幾個遊戲記錄。當一個玩家想更新進度時
候,他們需要把最新進度從主伺服器下載下來,玩一會兒,保存並上載到主伺服器以供
其他人使用。
@@ -64,33 +64,32 @@ http://en.wikipedia.org/wiki/Revision_control[維基百科版本修訂控制條
=== 一個誤區 ===
-一個很常見的錯誤觀念是,分散式系統不適合需要官方中心倉庫的項目。這與事實並
-不相符。給誰照相也不會偷走他們的靈魂。類似地,克隆主倉庫並不降低它的重要性。
+一個很常見的錯誤觀念是,分散式系統不適合需要官方中心倉庫的項目。這與事實並不
+相符。給誰照相也不會偷走他們的靈魂。類似地,克隆主倉庫並不降低它的重要性。
一般來說,一個中心版本控制系統能做的任何事,一個良好設計的分散式系統都能做得
更好。網絡資源總要比本地資源耗費更費。不過我們應該在稍後分析分散式方案的缺點,
這樣人們才不會按照習慣做出錯誤的比較。
-一個小項目或許只需要分散式系統提供的一小部分功能,但是,在你的項目很小的時候,
-說你應該用規劃不好的系統,好比說,在計算較小數目的時候應該使用羅馬數字嗎
+一個小項目或許只需要分散式系統提供的一小部分功能,但是,在項目很小的時候,應
+該用規劃不好的系統?就好比說,在計算較小數目的時候應該使用羅馬數字
而且,你的項目的增長可能會超出你最初的預期。從一開始就使用Git好似帶著一把瑞士
-軍刀,儘管你很多時候只是用它來開開瓶蓋。到你迫切需要一把改錐的那一天,你就會
-慶幸你有的不單單是一個啟瓶器
+軍刀,儘管你很多時候只是用它來開開瓶蓋。某天你迫切需要一把改錐,你就會慶幸你
+所有的不單單是一個啟瓶器
=== 合併衝突 ===
-對於這個話題,電腦遊戲的類比顯得太單薄了。那麼讓我們再來看看文檔編輯的情況吧
+對於這個話題,電腦遊戲的類比顯得不夠用。那讓我們再來看看文檔編輯的情況吧
假設Alice在文檔開頭插入一行,並且Bob在文檔末尾添加一行。他們都上傳了他們的改
動。大多數系統將自動給出一個合理的處理方式:接受且合併他們的改動,這樣Alice和
Bob兩人的改動都會生效。
現在假設Alice和Bob對檔案的同一行做了不同的改動。如果沒有人工參與的話,這個沖
-突是無法解決的。第二個人在上載檔案時,會收到 _合併衝突_ 的通知,要麼用一個人的
-改動覆蓋另一個的,要麼完全修訂這一行。
+突是無法解決的。第二個人在上載檔案時,會收到 _合併衝突_ 的通知,要麼用一個人
+的改動覆蓋另一個的,要麼完全修訂這一行。
更複雜的情況也可能出現。版本控制系統自己處理相對簡單的情況,把困難的情況留給
人來處理。它們的行為通常是可配置的。
-
Please sign in to comment.
Something went wrong with that request. Please try again.