Version control0221

版本控制說明文件

作者：邱建宏

大綱

• 版本控制介紹
• 分支管理介紹
• 環境安裝說明
• 開發者專案維護流程說明
• Gerrit Patch Set 說明

何謂版本控制
　　簡單來說，版本控制是為了讓專案在
進行開發時能夠被有效的追蹤、紀錄、與
同步管理的一種機制，舉例來說它可以做
到以下：
• 保留歷史修改記錄，以供查詢
• 可以隨時復原修改，回到先前的版本
• 多人協作時，有效的進行合併、整合
• 軟體發行時，可以方便管理不同版本

版本控制的好處
• 你是否在開發專案時有過以下經驗呢？
– 慘了！檔案不小心被覆蓋甚至遺失怎麼辦？
– 埋頭苦幹卻忘記改了哪些檔案哪些片段？
– 想復原到先前的版本卻不知如何下手？
– 程式碼被更改了？是誰？又為什麼改？
– 需要釋出一個穩定版本，但是我還在開發？
– 被問到前幾次改了什麼，卻說不出口？

• 使用版本控制一次解決！！

版本控制工具介紹
• 專案版本控制工具－ Git
– Git 是一套簡單快速的分散式版本控制系統，提供大部
分版本控制的主要功能。
– 想知道更多關於 Git
• 多專案管理工具－ Repo
– Repo 是一套專門為 AOSP 設計的多專案管理工具。
– 想知道更多關於 Repo
• 原始碼審核工具－ Gerrit
– Gerrit 是一套 Web 介面的原始碼審核系統，它負責將
專案的變更進行審核、驗證，最後決定提交或捨棄整
合到專案內。
– 想知道更多關於 Gerrit

版本控制下專案的角色與權力
• 開發者（ Author ）
– 負責撰寫與修改原始碼
– 權力：交付變更、取得最新版本專案

• 審核者（ Approver ）
– 負責審核程式碼變更、功能需求判定
– 權力：審核變更、回饋意見

• 驗證者（ Verifier ）
– 負責專案實際建置、實行，確保專案穩定開發
– 權力：審核變更、驗證變更（否決／提交）、回饋意見

• 在同一專案中一個人有可能同時扮演多種角色；在不同專
案中也可能扮演不同角色，請確定您在團隊中的角色為何
喔角色參考來源

版本控制
開發者建立開發者從遠
本地的版本端同步最新
開發者
控制環境版本專案
開發者本地端環境
審核者

工作流程
驗證者
開發者進行開發者交付
開發或修改變更到 Gerrit 驗證者本地端環境
檔案後交付等待審核 Gerrit 自動程序

提醒審核者提醒驗證者
進行審核進行驗證

審核者對於驗證者將變驗證者設正
變更內容做更建置於本測試無誤 ? 面評價並提
出判斷評價地端後測試交變更

審核者填寫
變更合適 ? 意見並設置
正面評價

驗證者填寫系統將變
意見並設負更合併至
面評價回饋遠端倉庫
審核者填寫
意見讓開發
者重新交付

回復到未同個檔案沒有衝
審核、驗沒有衝突產生突產生 ?
證的狀態 ?

回復到尚變更加入到
系統提醒驗證
未驗證的遠端倉庫供
人手動合併
狀態下次同步

驗證人或開
發者手動合
併後重交付
流程參考來源

何謂分支管理
• 使用分支管理的好處，提供專案更有效率
更有策略的專案開發佈局，其中最主要的
目的有以下兩個：

• 建立分支管理模型
– 分支的命名、分配分支的專案維護目的。
• 版本取得與管理
– 將穩定的版本存放於某一分支，容易取得特定
版本，且不輕易修改該分支內容。

feature release master
develop hotfix

分支管理模型 Tag
0.1

針對下一個發起一個
版本開發的 hotfix 0.2
針對未來

• 主要分支
主要 feature 來修正 bug
版本開發
的 feature
將 hotfix 0.2
合併至
develop

– Master Tag
0.2

– Develop
發起釋出

• 支援性分支在這個時間
點決定要釋
一個版本
release 1.0

出一個版本

– Feature release 1.0

僅修正
bug

– Release
– Hotfixes
release 1.0 Tag
所有修正過 1.0
的 bug 合併至
develop

模型參考來源

主要分支－ Master
• Master 分支是 Git 使用者相當熟悉的分支
，當一個 Git 專案被建立時，預設的分支
就是 master ，作為主要的分支，在分支管
理模型之下， master 並不會是最新的開發
內容，而是與目前最新釋出的版本相同，
且 master 分支是永遠存在的。

主要分支－ Develop
• Develop 在專案分支管理中是最重要的分
支，它會是所有開發過程的紀錄，而專案
管理者在決定也會參考 develop 來評估團
隊下一個版本將釋出的內容。
• Develop 與 master 這兩個主要分支將會
是專案的骨幹，在專案的生命週期之中，
develop 也是永遠存在的。

支援性分支 Feature
• 當一個開發者準備開始在一個專案之中展
開一個新功能的開發，開發者會以目
前 develop 的進度點分出一條分支進行新
功能開發或測試，也就是 feature 分支。
• 當一個 feature 的開發完成後，開發者將
feature 合併回 develop 並且交付審核，
至此一個 feature 的流程才算結束。

支援性分支 Release （ 1/2 ）
• 隨著 Develop 的開發功能越來越多，專案
管理者決定釋出一個新的版本，此時將會
發起一個新的 Release 分支，接著開始專
案的回歸測試階段，此時最重要的原則便
是展開 release 分支之後，只有
在 release 分支修正問題後所產生的變更
可以合併回 develop ，而 develop 中任何
的新改變（功能），都不可合併
回 release ，因為一旦這樣做 release 分
支便失去了它的意義。

支援性分支－ Release （ 2/2 ）
• 在完成了回歸測試之後，接著便可以發佈
一個新的正式版本，此時會把 release 分
支中所作的改動合併
回 master 與 develop 並關閉這一個
release 分支，並且在 master 之中加上新
的 tag ，這一次新版本的釋出就宣告完成
。

使用版本控制前的準備工作
• 建立本機端 Git & Repo 版本控制環境
– 決定要架設環境的作業系統
• （ Windows － Cygwin ）
• （ Linux － Ubuntu 直接前往）
• 註冊與設定 Gerrit Web
– 請向 Gerrit 管理者申請開通帳號
– 取得交付審核與專案同步的權限
• 取得專案分支佈局檔
– 包含 develop 、 release 、 hotfix 等 manifest
檔

建立本機工作環境－ Cygwin
• 開啟 Setup.exe 安裝程式，點選下一步

• 點選 Install form Internet ，點選下一步

• 決定安裝 Cygwin 的目錄位置，點選下一
步

• 選擇存放下載套件的位置，點選下一步

• 點選 Direct Connection ，點選下一步

• 選擇一個鄰近的下載點，點選下一步

• Search 以下套件並選擇安裝，點選下一步
– Net -> curl, openssh, ca-certificates
– Devel -> git* (git, git-completion, git-gui, gitk)
– Libs -> libreadline6, libiconv2
– Editors -> vim
– Python -> python # 搜尋列在下面

– X11 ->xorg-server, xinit
– Utils ->gnupg # keep 為已經安裝

# ver. 為選擇安裝

# skip 為尚未安裝

• 設定 Cygwin 環境變數
– [ 開始 ]->[ 我的電腦 ]-> 右鍵 ->[ 內容 ]->[ 進階
系統設定 ]->[ 環境變數 ]
– 對 [ 系統變數 ] 下的變數 [Path] 進行編輯，在
原有 [ 變數值 ] 後面加入以下路徑，請依照自己
Cygwin 安裝路徑來填寫並使用分號 ” ;” 隔
開 ) ，按下確定
X:Cygwinbin;X:cygwinhomeuserbin

• 開啟 Cygwin Terminal ，安裝 repo 工具
$ mkdir ~/bin
$ curl https://dl-
ssl.google.com/dl/googlesource/git-repo/repo >
~/bin/repo
$ chmod a+x ~/bin/repo

# 創建給 repo 存放用的目錄

# 下載 repo 工具

# 更改 repo 的權限

• 產生與 Gerrit 溝通需要的 SSH 金鑰
$ ssh-keygen –C your_ITRI_email

# 產生 SSH key
# Enter
# Enter 再 Enter

# SSH key 產生完成

• 設定 SSH 自動用戶設置
– 在 ~/.ssh 目錄下新增一個 config 檔，填入設定
$ vim 值
~/.ssh/config

host gerrit
hostname 192.168.4.112
user your_ITRI_email_title
port 29418

# 新增 config 檔案

# config 設定值如左

• 設定 repo 工作目錄 ( 放置專案的目錄 )
– 創建當作工作目錄的資料夾
$ mkdir your_working_directory

# 創建工作目錄

建立本機工作環境－ Ubuntu
• 安裝 git 工具 & repo 相關相依套件
$ sudo apt-get install git-core curl python

# 安裝相關套件

# 同意下載

# 安裝中…

• 下載 repo 工具
$ mkdir ~/bin
$ PATH=~/bin:$PATH
$ curl https://dl-ssl.google.com/dl/googlesource/git-
repo/repo > ~/bin/repo
# 創建給 repo 存放用的目錄
# 將 repo 工具加入環境變數

# 下載 repo 工具

# 更改 repo 的權限

• 產生與 Gerrit 溝通需要的 SSH 金鑰
$ ssh-keygen –C your_ITRI_email

# 產生 SSH key
# Enter
# Enter 再 Enter f

# SSH key 產生完成

• 設定 SSH 自動用戶設置
– 在 ~/.ssh 目錄下新增一個 config 檔，填入設定
值
$ vim ~/.ssh/config

host gerrit
hostname 192.168.4.112
user your_ITRI_email_title
port 29418

# 新增 config 檔案

# config 設定值如左

• 設定 repo 工作目錄 ( 放置專案的目錄 )
– 創建當作工作目錄的資料夾
$ mkdir your_working_directory

註冊與設定 Gerrit Web
• 請先向 Gerrit Web 管理員詢問協助開通帳
號
– 帳號規定為您的工研院 email 開頭
– 密碼為您自行設定

• 舉例來說，我的 email 為 V300@itri.org.tw
– 帳號則為 V300

• 登入 192.168.4.112:8888
– 輸入您的 Gerrit Web 帳號密碼


• 註冊使用者名稱與 email

– Email 務必設為工研院 email

(2) 填入名稱與註冊 Email

(3) 按下 Save Changes (4) 到信箱接收驗證信並點取連結進行驗證

(1) 點選 Contact Information

• 註冊 SSH key
$ cat ~/.ssh/id_rsa.pub

(1) 查看並複製 SSH key (ssh-rsa 至 .tw)

(2) 點選 Settings

(3) 點選 SSH Public Keys (4) 貼上 SSH key 到這邊

(5) 按下 Add

• 驗證 Gerrit 註冊是否成功
– Welcome 出現就代表註冊成功
$ ssh gerrit

# 試著對 Gerrit Server 建立 ssh 連線

• 設定追蹤的專案
– 加入追蹤的專案會透過 email 通知

(1) 點選 Settings
(2) 點選 Watched Projects

(4) 輸入要追蹤的專案
(5) 輸入要追蹤的分支
(3) 點選 Browse 查看專案列表 (6) 點選 Watch 加入追蹤

(7) 選擇要追蹤的事件

# 如果覺得 Email 通知會造成騷擾也可以自行定期登入 Web 查看紀錄

取得專案分支佈局檔
• 切換到工作目錄底下，接著取得分支佈局
設定檔 manifest.git
$ cd yourWorkingDirectory
$ repo init –u ssh://gerrit/manifest.git

# 切換至工作目錄

# 取得分支佈局設定檔

# 這個錯誤不需緊張
只是尚未選擇要維護的分支
( 下面會介紹到 )

開發者專案維護流程說明

分支維護時機
• 首先，必須知道的是每種分支的維護時機
，操作流程於後面進行說明：
– Develop 分支 ( 永久存在 )
• 專案平時的開發、修改、測試新功能等等
– Feature 分支 ( 開發者自行增加刪減 )
• Feature 分支被 repo 的 topic 分支取代，但功能不
變
– Release 分支 ( 專案管理者發起 )
• 當專案管理者想要釋出一個版本
– Hotfix 分支 ( 專案管理者發起 )
• 專案開發途中發現舊有版本存在重大 bug

Develop 分支維護流程
# 紅色字體為自行設定的名稱

repo start new feature . .
repo start new feature
repo init –m develop.xml
repo init –m develop.xml repo checkout old feature
repo checkout old feature git commit -s
git commit -s

創建新 topic 分支或
創建新 topic 分支或建立本地存檔
建立本地存檔
切換至 develop 維護環境
切換至 develop 維護環境撰寫交付訊息
維護舊 topic 分支
維護舊 topic 分支撰寫交付訊息

Time

將變更過的檔案
將變更過的檔案交付變更
交付變更
同步專案
同步專案加入存檔佇列
加入存檔佇列等待審核
等待審核

repo sync
repo sync git add -A
git add -A repo upload
repo upload

Release 分支維護流程

repo start new bug-fix . .
repo start new bug-fix
repo init –m release.xml
repo init –m release.xml repo checkout old bug-fix
repo checkout old bug-fix git commit -s
git commit -s
建立本地存檔
切換至 release 維護環境
切換至 release 維護環境撰寫交付訊息

Time

交付變更
同步專案
等待審核

repo sync
repo upload

Hotfix 分支維護流程

repo start new hotfix . .
repo start new hotfix
repo init –m hotfix.xml
repo init –m hotfix.xml repo checkout old hotfix
repo checkout old hotfix git commit -s
git commit -s

建立本地存檔
切換至 hotfix 維護環境
切換至 hotfix 維護環境撰寫交付訊息

Time

交付變更
同步專案
等待審核

repo sync
repo upload

• 下頁投影片提供您一個操作範例

Develop 分支維護範例 (1/3)
• 切換到 develop 分支進行維護與資料同步
$ repo init –m develop.xml
$ repo sync

(1) 切換至 develop 分支

(2) 同步 develop 分支下的專案

# 被同步下來的專案

• 進入專案後新建一個分支並新增一個檔案
$ repo start newfeature .
$ touch test.c
$ git add –A
$ git commit –s –m “add test.c”

(1) 進入專案

(2) 建立一個 topic branch 開始工作囉

(3) 新增一個檔案 test.c

(4) 將專案內所有修改、新增、刪除過的一次加到存檔佇列

(5) 本機存檔並加入說明

• 上傳變更至 Gerrit Server 等待審核
$ repo upload

(1) 上傳變更

# 上傳成功

Gerrit Patch Set 說明
• 下圖可以發現此變更有兩個 patch set

# patch set 1
# patch set 2

• Patch set 產生機制
– 如果新上傳的變更 B 與目前等待審核中的某一
個變更 A 有相同的 change-id ，那麼變更 B 會
成為變更 A 的 patch set 2
• Commit-msg hook 工具
– 交付時會自動在交付訊息後面加上 change-id

# 下方的 change-id 就是透過 hook 自動產生的

• Patch set 的好處
– 減少審核者工作的數量
– 建立重新交付變更的關聯性

• Patch set 使用的時機
– 修補上次交付變更遺漏的部分
• ( 前次變更尚未審核完成之前 )
– 重新交付審核尚未通過的變更
• ( 依照審核意見修改 )

• 指令
$ git commit --amend

• 說明
– 這個指令會讓使用者修改上一次的交付訊息並
且覆蓋過去，所以原先的 change-id 會保留，
當開發者再次上傳變更時，就會與上一次的變
更擁有相同的 change-id ，進而形成新的
patch set

• 修補上次交付變更遺漏的部分
– 情境：開發者一分鐘前交付了一個變更，突然
(A) 想到程式內有一段程式碼忘記加註
(B) 想要修改交付訊息
– 流程：
git add -A
git add -A git commit --amend
git commit --amend repo upload
repo upload

將變更過的檔案修改交付訊息
修改交付訊息交付變更
交付變更
進入專案再次修改原始碼
進入專案再次修改原始碼加入存檔佇列
加入存檔佇列覆蓋上次存檔
覆蓋上次存檔等待審核
等待審核

Time

(A) 的進入點 (B) 的進入點

• 重新交付審核尚未通過的變更
– 情境：開發者上次交付的變更尚未被提交並且
收到審核者的修改意見，依照意見修改後重新
交付
– 流程：
git add -A
git add -A git commit --amend
git commit --amend repo upload
repo upload

將變更過的檔案修改交付訊息
修改交付訊息交付變更
交付變更
進入專案再次修改原始碼
進入專案再次修改原始碼加入存檔佇列
加入存檔佇列覆蓋上次存檔
覆蓋上次存檔等待審核
等待審核

Time

• 操作範例
– 開發者在 9:41 上傳了一個變更，交付訊息主題
為 patch set 1

• 開發者收到意見進行原始碼修改，並修改
交付訊息主題為 patch set 2 ，再次重新交
付

• 在 Gerrit Web 上可以發現原先的 patch set
1 在 9:46 分被更新成 patch set 2

# patch set 1 與 patch set 2 的 change-id 是相同的 (I8659e587…..)

• 在審核介面下就有兩個 patch set 產生

有任何操作上的疑問請不要吝嗇一同討論

使用過後就會發現版本控制簡單又實用

現在開始版本控制吧！！

版本控制工作流程

(2013/02/21) 更新

版本控制工作流程－流程圖

版本控制工作流程說明
• 本機：切換到 develop 分支維護環境
• 本機： repo sync 後開新 topic branch
• 206 ：修改 code ，並測試運作 OK
• 本機：再次 repo sync ，接著透過 merge
工具將 repo sync 後的專案與您在 206 修
改的專案合併，並將合併後的結果取代原
本在版本控制工作目錄下的專案內容
• 本機： git add –a, git commit –s
• 本機： repo upload

版本控制工作流程－操作範例
• 本機設定分支維護環境

# 切換至 develop 分支維護註 (1)

# 同步遠端最新的專案

# 進到專案底下

# 建立新 topic branch 並切換過去註 (2)

# 確認位於要工作的分支底下 ( ＊代表目前位置 )

• 在 206 Server 修改原始碼，並且測試完成
• 回到本機上再一次同步專案

# 再次同步遠端最新的專案

• 接著透過 merge 工具將您在 206 修改過的
專案內容合併到本機版本控制工作目錄下
的專案內容

• 將合併完成後所有修改過的內容加入存檔
佇列，並撰寫 commit message 後存檔

# 把變更過的檔案加入存檔佇列

# 存檔並撰寫 commit message

• Commit message 撰寫介面
# 第一行請寫下這次修改的大方向 ( 必填 )
# 第二行開始可以寫修改的細部內容 ( 非必填 )

# 存檔並退出

• 撰寫 commit message 完成

# commit 建立完成訊息

• 可以透過指令查看這次新增的 commit 內容

# 剛剛建立完成的 commit 內容，可以看一下有沒問題

• 將此次的變更上傳到 Gerrit Server 審核
# 上傳審核

# 上傳完成

備註
• 註 (1) 如果你已經在要維護的分支環境下
了，就可以不用再下一次切換指令。
• 註 (2) 如果你先前已經有創建了一個 topic
branch ，那麼先前創立的 topic branch 就
會存在於專案中，不需要每次新增一次
topic branch ，但要確定有沒有切換到該分
支下
# 透過指令查看有哪些分支，但是發現沒有切換過去

# 透過指令切換過去

# 透過指令再次查看，如果分支名稱前面有”＊” 就代表在該分支之下了

Version control0221

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (18)

Semelhante a Version control0221

Semelhante a Version control0221 (20)

Version control0221