Tag: git

Posted on
by

使用 git 改完一段程式碼後，你總想回傳給上游開發者。一般是利用 git-format-patch 來產生 patchset，然後搭配郵件軟體軟體寄出。可以配合 git-format-patch 使用的寄信軟體有 git-send-email, git-imap-send 等等，或你也可用 formail 將郵件轉為你的郵件軟體認得的格式。

個人喜歡 git-imap-send，它會將 patch 透過 IMAP 協定存在郵件伺服器上的草稿目錄，如此你可以稍候再透過郵件軟體編修或決定是否寄出。

GMail 設定方式

git-imap-send 使用時，需要先設定 IMAP 伺服器位置與帳號密碼。你可以直接編輯 .gitconfig ，寫入如下設定

[imap]
# Folder = "[Gmail]/Drafts"
Folder = "[Gmail]/&g0l6Pw-"
Host = "imaps://imap.gmail.com"
User = "[email protected]"
port = 993
sslverify = false

你如果看網路上的大部份說明文件，會告訴你 Folder 應該填 [Gmail]/Drafts。很神秘的是，大約我是中文使用者，我的草稿目錄就叫做「草稿」。若用 [Gmail]/Drafts 會出現 “(NO) – [TRYCREATE] Folder doesn’t exist. (Failure)” 錯誤訊息。但是 git-imap-send 不會自行編碼，因此你必須先自行依照 RFC2060 轉碼後，寫入設定，”[Gmail]/草稿” 即為”[Gmail]/&g0l6Pw-“。

附帶一提，Debian 的 git 由於 openssl 的授權問題，並沒有編譯入 SSL 支援。因此你得自行編譯一次，如想使用 Gmail 的 IMAP 寄信的話。

相關 Patch 格式、回覆地址設定

若你想透過 Gmail 送 patch，另外一個需要注意的是 Gmail 會弄爛內文的換行，因此請將 patch 以 attachment 的方式寄送，夾檔 Disposition 是 inline 或 attach 都可以。做法如下

git format-patch –stdout –inline –keep-subject origin | git-imap-send

為了方便別人閱讀，你也可以將夾檔副檔名改為 .txt，以便大部分郵件軟體可以直接閱讀辨識。

[format]
suffix = .txt
inline

另外你也可以在郵件表頭中指定回覆的地址。例如你可以指定請大家回信到 mailing list，以便可以在公開場合進行 patch review。你可以在 git config 中加入如下設定，由於你可能參與很多計劃，最好是加在 project/.git/config 中，而非 ${HOME}/.gitconfig.

[format]
        headers = "To: patches <[email protected]>\nReply-To: devel <[email protected]>\n"

其他方便開發者閱讀的參數如 –signoff, –thread, –numbered 等, 相關細節請見 git-format-patch (1) man page.

Posted on
by

時常，你得將手上的軟體原始碼壓起來釋出給第三方使用、測試。特別是你希望提供 daily basics/ revision basics 讓使用者取得最新版軟體的時候。

由於最近都已經只用 git，依據我自己的習慣，希望能夠在檔名中使用簡碼版次，以便未來能夠追蹤出該版次的問題。稍微問了一下友人與查了一下文件，取得 abbreviated commit hash 的作法如下

git log --pretty=format:"%h" -1

若你想將整份程式碼壓縮起來，可以使用

git archive --format zip -o filename.zip HEAD

倘若想加上日期作為檔名，請使用

git archive --format zip -o $(git log --date=short --pretty=format:"%ad" -1).zip HEAD

若常常使用這個指令，有兩種作法，一是設定為 git alias. 另一則是利用 git 的 commands (verbs) 命名機制，在你的執行路徑 下，寫入一檔案名稱如 git-zip。並將上述指令加入檔案中，未來就可以使用 git zip 來產生最新版壓縮檔。

作法如
$ cat > ~/bin/git-zip
#!/bin/sh
git archive --format zip -o $(git log --pretty=format:"%h" -1).zip HEAD
$ chmod u+x ~/bin/git-zip
$ cd git-repository
$ git zip

另外，為了容易辨識版次，你也可以利用 gitattributes 在程式碼中加入 ident ($Id$) 作為標示。操作可參考 Lloyd Huang 所寫之 Howto.

這是一篇 Tip.

Posted on
by

我已經在 Learning git 中提到 Scott Chacon 的 GitCasts 網站，網站中包含相當多的操作示範影片。但是其中有一則在原本的文章沒提到的是 Scoot 在 RailsConf 2008 對 Git 做了一個相當精彩的演講，若你原本有使用其他版本控制系統的經驗，花一個小時聽完 Scott 的介紹應該是最有效率的方法。

這場演講中，Scott 廣泛的介紹 Git 的設計理念與使用方法，解釋了 Git 所使用的 DAG Storage 與 SVN 所用的 Delta Stroage 的內涵差異，深入說明 Git 所使用的 Object Model，並解釋那些特別容易令人困惑的 index, remote/local branches 的概念，甚至幫你說明了最重要的幾個 Git 指令的使用方式。專心聽完，真的可以馬上學會喔。

(請按播放視窗的圖示將影像全螢幕較適合閱讀。)

“Getting Git” by Scott Chacon from Kevin Moore on Vimeo.

簡報可於 SlideShare 取得。聽完還意猶未盡的話，請深入閱讀 Git Community Book 吧。

對了，Perl 社群最近也開始使用 Git 來作為版本控制系統了。

Posted on
by

這段錄影已經躺在硬碟中很久，這兩日才利用通勤的時間消化了一番。這是 Linus Torvalds 在 Google 所進行的一段演講，身為一個性格強硬的硬底子駭客，他時常發出驚人的評論，有些有趣的言論甚至被整理成格言集，像是 The 10 Best Linus Torvalds Quotes 或 Linus Torvalds Quotes。

在這段演講中，身為 Git 計畫的發起人，Linus 說明了為什麼需要設計這樣的一套工具，基本的設計哲學與其他類似的工具的比較。

在技術的觀點上，他直接且尖銳的同時批判了 CVS 與 Subversion，演講一開始 Linus 就給了 CVS 贊頌 – 負面的贊頌，雖然 Linus 從來不用 CVS 管理 Kernel source tree，但是還是在商業公司有過一段不短時間的使用經驗，而且 Linus 打從心裡強烈的厭惡這個工具。同時他也批判 Subversion 這個計畫是他看過最沒有意義的，因為 Subversion 從各方面試著去改善 CVS 的一些技術上的缺點，卻無法根本的解決一些基本使用限制。具體來說 Subversion 改善的創建分支的成本 (意思是相對 CVS 所利用的硬碟、計算資源比較少)，但是卻沒辦法解決合併分支的需求，任何使用過 Subversion 合併分支的人都知道那是如何痛苦的折磨。而許多高度開發中的專案，都時常需要為不同的新功能開分支、合併，Subversion 解決了開分支的成本，卻沒有考慮到合併的人工成本。如此讓 Subversion 變成一個沒有未來的軟體計畫。

因此，基於過去在 BitKeeper 上得使用經驗，Linus 設計了新的 Git, 並將效能視為主要的需求。當然分散式的設計也是最重要的概念之一，Linus 提到幾個觀點，討論如下。

第一個是分散式的概念，解決了政治紛爭。所謂政治紛爭指 commit/checkout/create branch 的權利，傳統中央集權式開發模式，你若想要創建一個新的分支，或者進行一些實驗性的開發，通常必須獲得主開發者授予 提交者 (commitor) 的權限，意指你是受到信任的一份子，有權限可以自行修改軟體程式碼，被授權進行一些嘗試。(唐鳳的人人皆為提交者開發模式為例外)

這種模式，很自然的排擠了在所謂信任圈 (core developers) 外的人。對，你依然可以在中央控管的機制下嘗試，你依然可以透過 patch 提交你想要做的更動。但是工具本身的限制，直接的限縮了自由發展的可能性。舉例來說，你相對不容易組成一個工作小組 (Task Group)，因為分享程式碼的變動並不容易，你可能必須建立另外一個獨立的程式碼管理系統給這個工作小組使用。而不像分散式的管理工具如 Git/Mercurial 開發者間可以透過數種管道接取/同步雙方的進度。

或者中央集權工具的另外一個根本上的問題是 – 它阻礙了開發者的實驗精神。

簡單講，就是開發者礙於每次提交 (commit)，都可能因為程式碼的不相容性，造成其他人必須停下來彙整變更，影響到其他人的工作進度的後果，因此每次提交/儲存都會有所疑慮。因此很容易就演變成開發者埋頭苦幹，直到最後一刻才一口氣提交上線，結果造成的不相容與衝擊更大，反而造成最後的工作成果難以融合。

在分散式開發工具的輔助下，你可以隨意的開立新分支，自行修改、測試、同步、實驗，這些在本地的提交除了完全不會影響到其他人外，同時你也可以輕易的匯出成特定格式 (patches)，讓他人更容易的整合。這大幅改善了協同開發模式的磨合問題。

Git 是以分散式開發模式為根本，自然可以融合於相對單純的中央集權  (cvs/svn) 的權利結構。Linus 在演講中也提出了一個我認為很值得討論的觀點，即是應用於 Linux kernel 開發的多層次分散權利結構。Linus 提了一個重點，基本上開發社群中有一種信任關係 (Web of trust)，像 Linux Kernel 這樣的龐大計畫，每個版本參與的開發者大約千人。實際上主要開發者如 Linus 不可能認識這麼多人，很自然的，他只能信任最熟識的幾個人，他指知道幾個人的智商與能力都是足以信賴的，於是他只需要仰賴這些人的成果。而其他人在於自己的信賴圈內，找到其他可以仰賴的人，於是利用這樣的信賴機制來擴展成網狀的開發社群。

在實務上，社群中也會演化出幾個角色，像是司令官 (dictator)、副官 (lieutenants)、開發者。幾位副官只要專注在他們熟悉的領域，整合開發者的成果，並提交給司令官做最後的整合決策。這麼一來，各種不同的專業領域都可以交給最熟悉的開發人員管理，而開發不會被限制、停頓在某個角色身上，相對而言是一個比較具有效率的開發社群結構。且分散式開發，也讓不同的開發者得以有權利與自由自行發展，不受限於官僚機制的限制。

上述為演講內容的一些提要。

Web of trust 是我相當認同的一個概念，任何所謂社群中，都會自然的因為信賴關係存在更小的團體，有人誤解這是一種分裂，但是我認為這是一種演化，不該消弭小圈圈的存在，反而應該鼓勵小團體的成立，自行交流、合作，才有機會產生或再演化出更大、更有力量、更健康的社群。(應該有什麼什麼政治學、社會學的理論在講這件事情吧 ?)

另外也推薦一個網站，是即將被國家綁架去服役的 kanru 翻譯的「為什麼 Git 比 X 棒」(Why Git is Better than X)。這個網站簡約的說明了 git 與其他程式碼控制軟體的比較，可以讓你比較容易了解各種軟體間的差異細節。

另外 為什麼 Git 比 X 棒 這個網站中介紹的 github 服務，我個人相當欣賞，它基本上提供了 Git 的 hosting 服務，但同時也包含了更多 Web 2.0 的概念，是所謂 “Social coding hosting”，基本的功能除了提供 Git 外，像一般的社交網站一樣，你可以追蹤別人的狀態，別的網站你追蹤的是朋友發出來的訊息，這裡你追蹤的是朋友寫出來的程式碼，而且你可以直接在線上「複製」(branching) 別人的工作成果，也提供了相當美觀的介面，讓你看到程式碼更動的網路關聯圖，相當有趣。剛開始使用 Git 時，可以試試這個網站。

若想學習 Git, 請參考 Learning git 一文的連結。

Posted on
by

若你曾經或正想學過 git，你肯定已經讀過不少文件。不過學習最快的方式，除了學習基本的術語外，你可能順著 Git tutorial (part 2), Git QuickStart 或 Everyday GIT With 20 Commands Or So 甚至印了 Cheat Sheet (extended edition) 當作案邊參考，

若你遲遲未能上手，而想試過所有指令，最好的方法就是跟著前人作一遍。Scott Chacon 因此做了一個 GitCasts 網站，網站裡面循序漸進的以影片方式教授你如何使用 git。(Scott 最近的新網站是 git-scm.com。) 若你還不了解如何使用 git，不妨試著觀看這些教學影片吧。