[筆記] 關於 Git Submodule 建立主從儲庫的關聯

問題:

我有一個利用 Sphinx 建置的文檔專案,並已上傳至 GitHub。該文檔專案的 theme 是自行設計,並準備給多個文檔專案引用 (也就是共用),所以 theme 也是視為另一個專案,並也上傳至 GitHub。

這樣的作法可以確保爾後所有的文檔專案,都可以引用到最新版本的 theme,而不用個別採複製、覆蓋的方式來個別維護 theme 的檔案結構。

所以該如何讓文檔專案可以引用 theme 專案,建立關聯?

解決方案

利用 Git submodule 指令,讓該文檔專案將 theme 專案視為主專案內的子模組。

簡單作法:

閱讀全文 »

初識 Git∣GitHub-Git 簡史

Git[1]是由 Linux 之父-托瓦茲 (Linus Torvalds)為了維護 Linux 核心 (kernel)所開發出的版本控管工具。

早於 1991-2002 年間,當時 Linux 系統的核心維護,僅以補丁與備份性檔案 (patches and archived files)的方式實現。而後當 Linux 核心的維護規模日益龐大後,核心團隊決定與當時一家提供商業性版本控制系統-BitKeeper 合作,由其免費提供核心源碼的儲庫 (repository)。

這段蜜月期至 2005 年時,Linux 核心開源社群與 BitKeeper 結束長達三年的合作關係,而這也使得核心團隊必須著手開發屬於他們自己的版本控制工具。從 BitKeeper 的使用經驗中,他們制定了新的版本控制系統需要能達成下列幾個目標:

  • 速度。
  • 簡單設計。
  • 可以給予數以千計並行分支 (parallel branches)的非線性開發模式強力支援。
  • 完全分散式。
  • 能有效處理如 Linux 核心大型專案的規模 (速度與資料量的考量)。
  • Git 自 2005 年誕生以來,日益成熟且易於使用,而且還能維持原來的初衷-確實履行上述的目標設定;而最為人樂道的分散式架構,已證明更能有效應用在大型的協同式專案開發。有別於 CVS/Subversion 的中央集權控管方式,Git 可以不需要伺服器就可以在單機上運作版本控制,這也使得原始碼更容易發佈與分享。

    閱讀全文 »

淺論中小型專案版控系統的基本分支(branch)規劃

關於版控的分支與標籤的基本觀念,可參考原來寫的一篇:關於版本控管系統的分支(branch)與標籤(tag)的區別

關於中小型專案規模的版控分支 (branch)規劃,個人以為應該至少有三條 (以 Git 為例):master, develop , issue。

master (主幹):作為對外版本的釋出 (release)。

develop (開發用分支):作為內部開發的主要分支。其內的開發版本並不會對外釋出。

issue (支援性分支):Bug/Hot-fix (臭蟲/重大更新), 新功能 (new feature) ...。一般紀錄於「Issue Tracking」系統內的 問題/功能 等待解決的 Issue,即會轉入該分支。

看圖說故事

中小型專案規模的版控分支規劃
(點擊圖片鏈接看原圖)圖、中小型專案規模的版控分支規劃

閱讀全文 »

關於版本控管系統的分支(branch)與標籤(tag)的區別

版本控管系統:版本控管係為「建構管理 (configuration management)」的範疇。理論上,關於「分支 (branch)」與「標籤 (tag)」,從觀念上來看在各版控系統應是類似的,只是做法不同罷了。

Suversion vs. Git:雖然兩者常被拿來比較的是,subversion 是集中式的儲庫 (repository),而 Git 則為分散式的。但若從專案管理者的角度來看,要管理的其實只有一個:位於伺服器上的儲庫。即使如 Git 可以有一堆分散式的儲庫,但管理者真正只有管理到例如儲存在 GitHub (or private Git server)上的儲庫。至於開發者在私人的儲庫內,要如何分支與標籤是自己的事,只要最終能提交給專案管理者做合併 (merge)即可。

關於版本控管的分支與標籤說明範例
(點擊圖片鏈接看原圖)圖、關於版本控管的分支與標籤說明範例

    關於分支 (branch):

  • 原則上,任一版本管控系統只有一條主幹,例如 suversion 稱為 trunk,Git 稱為 master。
  • 每一次對開發文件的提交 (commit),可視為是一個節點 (node)。節點會持續隨開發時間推進,並期能達成所設定的里程碑 (milestone)。
  • 如果把主幹的任一節點當成是可能對外發布的釋出 (release),而這些釋出不希望與開發/維護期間的文件相互干擾,則可以另闢其它分支 (branch),可與主幹並行開發並個別維護。主幹與分支(可能多個)盡量將耦合性 (coupling)降低,讓版本釋出與開發維護得以順暢並行。
  • 分支後的開發/維護的節點,最終仍需將修改的文件回到主幹上,此時就必須做「合併 (merge)」的動作。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal