Skip to main content

· 2 min read

傳統的版本控制系統 (Version Control System, VCS) 只有一台單一的版本庫（repository），所有的版本控制都必須經由這台版本庫主機才能管理。新一代的分散式版本控制系統 (Distributed Version Control System, DVCS) 如 git, Mercurial 則每份抓下來的 code 都可起到等同於版本庫的作用，使得在離線時做版本控制，並能容易地合併回主版本庫的工作模式成為可能。

因為分散的特性，也衍生出各種可能的合作模式。 git 有 A successful Git branching model，Mercurial 有 Workflows: Branch As Needed, Stable & Default, Translation Branches 等方式。

實際上該採用哪種方式比較好？先看看其他人怎麼做，從中選擇，或是加點創意，找出適合自己團隊使用的方法吧。

· 5 min read

Mercurial(Hg) 一直是我很愛用的版本控制工具。以前自己最常用的用途是拿來取代 svn，單純享受單機 / 離線使用版本控制系統開發的樂趣。

要單機使用版本控制系統開發，照著水銀分散式版本控制系統的使用概念做就行了。

最近看了Hg init和ProGit兩份分別講 Hg 和 Git 分散式版本控制的書，裡面都相當推崇「分支 (Branch) 開發」的概念。 所謂「分支開發」，就是將主幹 (trunk) 保持在穩定可運作的版本（雖然本來就該這麼做），在開發任何新功能時都另建新分支 (branch)，開發到一段落之後再合併回主幹。能支援這樣的開發模式，是因為 Hg 或 Git 這些分散式版本控制系統做開分支、合併等動作的額外開銷都很低。

那麼要實際使用時該怎麼做呢？

開分支

我有一個名為「ZAKU」（薩克）的目錄，主幹版本代號為 3, 現在要實作一個將綠色變成紅色的功能，這時我們可以建立一個新分支來繼續開發這個新功能。分支命令的格式為：

> $ hg branch [branch name]

因此要建立一個名為「red」的分支，可以使用以下命令：

> $ hg branch red
> marked working directory as branch red

這麼一來，之後 commit 的 code 都會進入「red」這個分支了。

查看狀態

在 commit 進一些 code 之後（版本代號到 13），輸入「hg branchs」命令可以列出所有版本

> $ hg branches
> default                       3:e2287f9031a1 (inactive)
> red                           13:e590de4b0dc9

切換分支

在開發新功能的同時，也可能會碰上整個專案共通的 bug，以前老派的作法是再 check out 一份主幹的程式碼，然後兩邊修正，現在有了 hg, 只要先暫時切換回主幹，把 bug 修正了再合併回分支（或到時一次把分支合併回主幹）。

要切換回主幹，輸入「hg update default」即可。

> $ hg up default
> 4 files 已更新, 0 files 已合併, 3 files 已移除, 0 files unresolved

合併

當我們把「red」分支中的新功能做好後，可以很容易地將這些修改合併回主幹。

首先，用上面的方法切換回主幹，然後輸入「hg merge red」，即可將「red」分支中的修改加進主幹。

> $ hg merge red
> 5 files 已更新, 0 files 已合併, 0 files 已移除, 0 files unresolved
> (branch merge, don't forget to commit)

合併命令的格式為

hg merge [branch name] 合併完後確認沒問題，就將程式碼再 commit 進版本庫吧！

如果只想 push 某 branch 的修改到版本庫，可以使用

hg push --rev [version] 命令，這樣只會將與指定版本相關的修改上傳到版本庫。

One more thing

同樣的方法，我們可以再建立一個分支「horn」來開發長角的功能，然後再將「horn」分支合併回主幹。

別忘了 hg 還有提供一個離線網頁瀏覽功能，輸入「hg serve -p 5000」，在瀏覽器上輸入「http://localhost:5000」就能看到類似 gitweb 的版本控制訊息網頁。點選左側的「graph」標籤，可以用視覺化的方式看到之前所有分支合併的圖形記錄囉！

學會分支與合併後，你的開發效率會不會也變成三倍速哩？

參考資料:

· One min read

在做完「hg clone」（就如同從 Server 端 Check Out 程式碼）後，除了可以對原 Server 做「hg pull」以更新程式碼之外，也可以多加別台 Server 進列表。

如原來從 Alice 處「hg clone」下來原始碼，而現在也想要從 Bob 處直接取得他的更新，可以使用

$ hg pull [bob server]命令。

另一個好方法是可以在 .hg/hgrc 中定義額外的 Server 別名 (alias)。

例如原來的 .hg/hgrc 長這樣:

[paths] default = [Alice Server]/[project] 我們在其後加入 Bob Server 的別名如下: [paths] default = [Alice Server]/[project] bob = [Bob server]/[project] 儲存後，要再從 Bob 處直接取得他的更新，可以使用 $ hg pull bob 命令來直接取得 bob 的原始碼。分散式版本控制是不是很方便呢 :)

· 4 min read

紙本書變電子書是很小的事，書變得不像書，才是嚴重的事。-- 紙本書變電子書是很小的事 —— 詹宏志談數位元出版時代

假如電子書指的是，一個在特殊的閱讀設備上面呈現我們今天在紙本書上所看到的內容和形式的書， 那我會說，電子書正在解決過去的問題而沒有解決未來的問題。 使用互聯網這件事都佔用了你很大一部分的時間，這個形式連電子書都沒有辦法解決。所以電子書是在解決過去的問題。 取得知識的方式如果已經變了，出版還沒變的話，就會慢慢變得不相干。 出版者要解決今天的出版困境，他必須到未來的學習者取得知識的地方去做出版，不能繼續使用現在出版的形式，使自己愈來愈跟這個社會不相干。 舉個例子，現在全世界最好的百科全書極可能還是大英百科全書，可是最好有什麼用？它現在跟我們大部分年輕人是不相干的。 而我也不覺得現在的年輕人用的是維基百科，真正改變他的行為的是搜索引擎。 他是先丟出一個要查的東西，如果維基百科在前三條，就點進去，還沒到維基百科，這個事情就已經決定了。 當資訊量愈大的時候，導語和評論的價值就愈高。 因為你真的沒辦法判斷，問題不在於沒有而在於太多了，多到你不知道誰好。 在我看來未來編輯的工作會很不一樣，會加倍重要。 一個社會創作生產量愈大總的來講是好事，你可能會嫌他有很多不好的東西，但是數量跟好東西是有關聯性的。 披沙揀金的結果，有這麼大量的垃圾，也會有某一個比例的含金量。 容易發表的創作，其實是使得很多可能的創作都會跑出來的重要原因。 去瞭解你的朋友，現在的年輕人，取得資訊的行為是怎麼一回事，你可以從那裏看出，有什麼東西是你可以做。 你怎麼可以忍受看那麼多東西才找到那麼一點點好東西，應該有人幫我做這個事，對不對？ 應該有各種有判斷能力的人來幫我做這個事，而我會選擇每次判斷都深得我心的編輯來追隨，編輯也會有他的訴求、專長、分工。 我們擋掉了很多不要浪費出版資源的東西；可同時，說不定也擋掉了對社會有衝擊的新創作。