版本控制 - 使用Git

(What)什麼是Git?
(Why)為何要使用Git?
(How)Git能夠幫助我們如何完成任務?

碼農的工作日誌 - 程式版本控制

  1. 一個辛勤工作的碼農,每天辛勤地耕耘程式碼,萬一受到突如其來的侵襲,容易造成作物損失.
  2. 工作日誌可以在程式碼在開發過程當中,回溯到當時的情況,讓碼農可以避免辛苦耕耘的成果一夕之間化為烏有.
  3. 這本工作日誌在碼農世界的術語稱為版本控制.
  4. 版本控制可以留下特定時間點的程式碼狀態,然而碼農可以繼續耕耘更新的程式碼,未來有需要時可以 回溯到過去留下紀錄的時間點,來進行查詢程式碼,或者是直接回復程式碼狀態重新開發.
Initial_Release

版本控制軟體

  1. 版本控制軟體非常多,筆者僅使用過部分版本控制軟體,例如: CVS、SVN、TFS、Git等.
  2. 版本控制軟體功能主要就是能夠讓撰寫程式的工程師透過版本控制軟體來管理特定時間點的程式碼內容.
  3. 進一步透過版本控制可以回溯程式碼,或是分享程式碼給其他開發者,甚至共同維護程式碼.
  4. 版本控制軟體種類概略上可分為兩種類,分別為單一資料庫形式或是分散式資料庫形式.
  5. 單一資料庫形式主要是將版本控制軟體所建置的維護倉庫放置於一個固定的伺服器中,使用者必須通過 資料庫的權限管制後,進行資料庫存取,才能夠取得版本控制內容.
repository_on_server
  1. 分散式資料庫形式主要是將版本控制軟體所建置的維護倉庫放置於一個固定的主要伺服器中,當使用者通過 資料庫的權限管制後,必須先將此資料庫取回到本地端,之後該使用這便使用本地端的資料庫進行版本控制存取.
repository_on_local
  1. 因此,分散式資料庫會在各使用者的本地端都放置了一份資料庫,因此稱之為分散式資料庫形式.
  2. 單一資料庫形式雖然維護倉庫屬於單一伺服器管理,但也因此保留的較單純的管理機制,適用於規模不大的 但一設計團隊使用.
  3. 分散式資料庫主要是活躍於開放原始碼團隊的領域,因為分散式維護倉庫可利於散佈維護倉庫,對於開發者 散落在世界各地的開發原始碼專案而言,相對上有較佳的應用方式.

CVS、SVN

  1. CVS是較為古老的版本控制軟體,屬於開放原始碼專案的版本控制軟體,近來已經不再繼續開發新版本.
  2. SVN是Apache軟體基金會所開發的開放原始碼版本控制軟體,全名為Subversion, 相較於CVS其採用了分支(Branch)的架構,它的設計目標就是用於取代CVS.
  3. 也因為是開發來取代CVS的版本控制軟體,開發者希望使用者能夠無痛轉換至SVN,因此大部分使用概念都承襲 了CVS,目前SVN仍有許多大型專案使用其來進行版本控制.
  4. CVS與SVN皆屬於單一資料庫形式維護版本控制.
  5. 目前有整合性GUI套件TortoiseSVN可讓使用者更便於使用.

TFS

  1. Team Foundation Server簡稱為TFS,這是一個由微軟開發的版本控制軟體,與其他開放原始碼不同是 此軟體由微軟授權,僅有特定方式可以免費使用.
  2. TFS一般架構於Visual Studio Team Services,可透過MSDN訂閱或是直接購買授權.
  3. TFS屬於單一資料庫形式維護,但似乎有條件可以使用分散式資料庫功能,但筆者本身未使用過.
  4. 補充: 近期TFS服務已有嶄新的整合新型態面孔 - Azure DevOps, 因為尚不熟悉,就不加說明了.

Git

  1. Git是目前最活躍於開放式原始碼專案領域上的版本控制軟體,其最早的開發者為Linus Benedict Torvalds.
  2. Git最初就是由Linus開發用於管理同為開發原始碼專案的Linux核心,目前主要維護者為濱野純.
  3. Git原本不太受到歡迎,主要是其有點艱澀難懂,但由於其操作指令友善,讓Git變得好用, 後來許多著名的開放原始碼專案採用.
  4. 本來Git僅能使用於Linux/Unix平台,後來受惠於Cygwin、msysgit環境日漸成熟,在Windows環境也能夠使用.
  5. 目前TortoiseGit提供簡單易用的GUI工具,讓使用者更便於使用.

為什麼要使用Git

  1. 實際上,我們是因為有了版本控制的需求,才選擇了Git這個版本控制軟體
  2. 以目前所屬的開發團隊來說,硬體、韌體、軟體都有程式碼需要採用版本控制管理手法的需求.
  3. 硬體有FPGA的RTL設計以及硬體測試程式的程式碼需要版本控制來進行管理.
  4. 韌體有底層API程式碼需要管理,甚至往上延伸至系統整合程式需要管理.
  5. 軟體有系統OS程式碼及各種應用工具程式碼需要管理.
  6. 硬體、韌體、軟體之間也可能存在需要程式碼或資料交換的管理.
  7. 導入版本控制管理,可以讓團隊成員彼此交換程式碼更便利,且利於分支管理及回溯管理等.
  8. 既然我們有版本控制的需求,接下來就是選擇一套適合的版本控制軟體.
  9. 其實在上一章節中所介紹的幾套版本控制軟體都可以符合我們的需求.
  10. 選擇Git這套軟體的主要理由應為其分散式架構利於目前團隊開發的架構現況.
  11. 如下圖所示,分散式架構可以讓各設計者將管理倉庫取回至本地端,並在本地端各自發展分支, 最後再進行整合.
COMMON_RESP
  1. 以筆者過去使用SVN的經驗,要做到這個架構且操作便利不太容易,所以都採用本地端與伺服器端 倉庫各自獨立建立的方式來進行管理,如下圖所示.
  2. 再者,目前Git在開放原始碼領域上逐漸成為主要版本管理倉庫的管理工具.
  3. 當我們在職場上工作的同時,如果能夠與世界趨勢接軌,我想對團隊成員的職業生涯都有相當的助益.

Github

  1. Github本身不是整合性套件軟體,他是一個Git倉庫代管的平台,2018年該微軟以75億美元收購Github.
  2. Github目前應為最大的Git倉庫代管平台,且不只有提供倉庫代管,附加功能也不少,包含文件自動生成、 問題追蹤、任務列表、甘特圖等.

TortoiseGit

  1. TortoiseGit是一個整合性GUI套件,讓使用者可以透過GUI便利操作.
  2. 目前我們採用TortoiseGit軟體並且在團隊成員可以存取的伺服器中建立版本控制倉庫,團隊成員只要有對 伺服器有存取權限即可存取版本控制倉庫.
  3. 這樣的方式與一般進階的版本倉庫控管不同,主要是權限控管需仰賴伺服器本身的存取權限, 而非版本控制倉庫本身的權限設定.
  4. 現行實驗室環境中,及團隊成員對於伺服器的存取權限,使用TortoiseGit仍可以達成目的.

安裝軟體

  1. 前面章節我們已經介紹了版本控制軟體的功能,並且說明未來團隊將使用Git來做為版本控制的軟體.

  2. 本章節將說明Git軟體的安裝及相關搭配使用的TortoiseGit套件.

  3. Git的主要安裝程式可至官網下載

  4. 當Git安裝完成後,在開始功能列中可以看到Git的程式集,但其實程式主要是採用git bash來運行.

  5. git bash是指令列操作模式並有顏色顯示功能輔助,與一般傳統黑白指令列模式稍有不同.

  6. 但無論如何,使用者皆須透過指令列並透過輸入指令方式來操作.

  7. 為了方便操作,我們使用TortoiseGit來輔助,TortoiseGit可至其 官方網站下載.

  8. 軟體的安裝步驟都相當直覺,在此就不再多做贅述.

  9. 安裝好軟體之後,Git本身有一些基本設定在指令git config中,因為設定繁多,這裡僅說明會需要使用到的設定.

  10. 第一個設定是使用者名稱及其Email Address,指令如下:

    git config --global user.name "foolman"
git config --global user.email foolman@mail.com

  11. 這個設定會讓未來在進行git commit時留下身分紀錄.

  12. 相同的設定使用TortoiseGit也可以進行,在檔案管理員中,按下滑鼠右鍵可以看到TortoiseGit選項, 選項中setting項目中可以進入設定畫面.

TortoiseGit_setting

建立倉庫

  1. 安裝好軟體之後,就可以開始學習如何使用Git來進行版本控制.
  2. 在開始進行版本控之前,必須要有一個對象倉庫.
  3. 前面章節曾經提到在網路上參與開放程式碼的軟體活動時,可以在Github網站上取得程式碼, 其實Github就是一個倉庫中心,使用者可以免費在網站上申請一個特定專案使用的倉庫.
  4. 然而,如果是私人或是封閉網域下使用,則可以透過git init --bare project_name來創立倉庫.
  5. 例如,我們建立一個名稱為ex_repos的倉庫,可使用指令git init --bare ex_repos,或是 先建立一個ex_repos的資料夾,點選資料夾後按右鍵選擇Git Create Repository Here,並且 勾選Make it Bare選項.
git_create_repos make_it_bare
  1. 建立完成後,資料夾內容如下圖,是由Git本身所建立的一些資料內容.
repos_content

工作資料夾與倉庫關係

  1. 之前我們提到,Git屬於分散式倉庫管理的形式,所以使用者所使用的工作資料夾必須先將倉庫的內容取回, 然後在自己的工作資料夾中進行程式碼發展.
  2. 開始程式碼的發展前,必須先將對應的倉庫內容取回,這個動作稱為git clone.
git_clone_relationship
  1. 利用指令git clone --local ../ex_repos可將前面所建立的ex_repos倉庫內容取回.
  2. 或是先在工作資料夾中建立一個專案資料夾名稱為ex_repos,點選資料夾後按右鍵,選擇Git Clone 選項,在URL欄位中填入對應的網址或是本機路徑.
git_clone_button git_clone
  1. 取回倉庫內容至本地工作資料夾後,即可以開始進行新增或是修改程式碼,後續的開發工作與一般 開發工作相同.

版本管理 - 主線與分支

  1. 當進入到程式碼開發時,因為與團隊成員共同維護程式碼,或許有些成員所維護的程式碼部分並不相同, 所以有許多情況會有專案整體管理及個人程式碼維護管理的需求.

  2. 在版本管理中, 主線(master,main)與分支(branch) 成為許多大型專案維護時的方法, 因此主線與分支在版本管理上是相當重要的觀念.

  3. 許多教學通常把 分支(Branch) 放在比較後面才提,但筆者認為這樣會讓使用者一開始著手維護版本管理時, 沒有完整的管理架構,失去了管理的精神,所以筆者把此部分拿到較前方來說明.

  4. 分支管理上, 主線(master,main) 可視為整體專案版本管理的主軸進程, 也就是完整專案在進行最主要版本控制時的節點控制軸線,過去Git將此主線稱之為master,但2020年開始有了一些變化, Github網站會將主線名稱修改為main,但我想無論是master或是main都是主線名稱,使用者只要確認這是主線名稱即可.

  5. 分支管理上, 分支(branch) 則是在管理程式碼開發過程時一個相當重要的腳色,當團隊成員將程式碼從伺服器上的倉庫 取回後,每一位成員所負責要開發的模組可能並不相同,且在日常開發過程中有自我版本控管的需求,但這些個人的版本 管理並不需要分佈給其他成員,因此可以使用 建立分支手法 來處理.

  6. 主線與分支的關係如下圖所示:

master_branch
  1. 版本管理倉庫主要是將主線master作為專案發展的主軸,本地端的成員可以從master主軸中,另外建立一個 分支來進行分項開發,待分項開發到一定程度時候,再將結果merge回本地端的master.
  2. 建立分支指令為 git branch branch_name,即可建立一個名稱為branch_name的分支.
  3. 接著使用指令git checkout branch_name即可以將工作目錄切換至分支線上開始進行開發工作.
git_branch_cmd

工作流程示範

  1. 前方已經介紹版本控制的基本概念,本篇是實際流程操作的示範.
  2. 首先,在本地端先建立專案資料夾,並從Server上將團隊的專案版本管理取回本地端,也就是初次取回的流程, 稱為Clone.
git_clone_button git_clone
  1. Clone完成後,在本地端建立分支.
git_branch_button git_branch_ex1
  1. 建立好分支之後,將本地端的開發流程切換至分支上.

git_checkout_branch
git_branch_cmd

git_branch_selection
  1. 當完成修改或新增各項設計文件之後,可將此次的修改進行版本確認,這個動作稱為commit,因此在分支上 開發過程中,開發者可以隨時進行commit來保存各項修改或新增設計的節點.
git_commit_ui
  1. commit視窗中會列出與上一次commit不同的檔案,包含修改與新增,如下圖所示,Not Version Files即是新增的檔案.
git_commit_list
  1. 在commit時,利用mssage視窗中流下註解可以方便回溯時參考每個版本的內容.
  2. 當分支開發告一段落,希望將此版本交換給其他設計者時,必須先將分支路線先切換至master.
git_checkout_branch git_branch_selection
  1. 這裡就讓大家看一下切換分支時的差異,剛剛開發這是在branch中開發,所以修改了readme.txt檔案,與新增了 add_module.txt檔案.
git_branch_folder

當切換至master時,資料夾內容如下:

git_master_folder
  1. 切換至master主線時,因為沒有branch分支所新增或修改的內容,所以切換後資料夾內容會回到一開始 取得的版本內容.
  2. 這時需要將分支的修改內容取得至master中,使用的方法是merge.
git_merge git_merge_branch
  1. 在master主線上merge得到branch分支修改的內容之後,如需要發布給其他使用者這時要做的工作是 push.
git_push git_push_ui

  1. 如此就完成了專案設計版本控制的流程,只要重複這樣的步驟,就可以將專案帶入版本控制的管理中.

  2. 如果要檢查伺服器倉庫是否有其他開發者Push更新版本,則是使用Pull方式來取的最新版程式碼.

git_pull git_pull_selection

補充

  1. 專案生命週期管理工具: Product Lifecycle Mangement;PLM ,用來管理專案開發過程中所產生的各種 設計資料,包含電路圖,程式碼及機構繪圖等等.
  2. PLM主要適用於專案開發過程中的大節點(Check Point)的資料管理,可兼具有版本控制的作用,但PLM本身 不適合用於開發過程中的頻繁版本控制,且PLM本身不具備程式碼比較或是預覽的功能.
  3. 程式碼管理利用版本控制軟體更有效率,可切換時間軸,直接比較程式碼等功能.
  4. 如何寫好commit messgae是進階的議題,提供一個不錯的範例給大家參考. 如何寫一個 Git Commit Message
  5. 關於分支的概念與管理,從這份文件中可以了解到分支應用的方式與手法. A successful Git branching model

Reference

版本紀錄

  1. 001: 20210620 憨人建立.