上一篇終於先把 Azure DevOps 裡的：
Boards
Work Items
Sprints
Feature
Product Backlog Item
Task
整理清楚了。
也就是說，我現在已經知道：
這次到底要做哪一張 Task
但找到工作單之後，還不能直接：
打開 main
↓
開始改程式
公司裡通常會先為這次工作建立：
自己的 Branch
也就是：
這次需求專屬的開發分支
然後我才會在 Visual Studio 裡切到那支 Branch 開始工作。
整個流程大概會變成：
Task
↓
建立 Branch
↓
Branch 綁定 Work Item
↓
Visual Studio Fetch
↓
找到遠端 Branch
↓
Checkout
↓
確認目前 Branch
↓
開始開發
第一次做這套流程的時候，我最容易卡在：
Azure DevOps 明明已經建立 Branch 了
為什麼 Visual Studio 找不到？
以及：
Clone
Fetch
Pull
Checkout
到底又差在哪？
這篇就把這段完整走一次。
假設目前團隊主要版本是：
main
如果每個工程師都直接在 main 上修改：
A 工程師
改登入
B 工程師
改會員
C 工程師
改報表
全部混在一起，風險會很高。
所以常見做法是：
main
↓
建立自己的工作 Branch
例如：
main
│
├─ feature/login
│
├─ feature/member
│
└─ feature/report
大家先在自己的 Branch 工作。
完成後才透過後面的：
Pull Request
Review
Merge
把修改整合回 main。
所以 Branch 可以先理解成：
從目前某個版本切出一條自己的開發線，讓我可以先完成這次工作，而不是直接修改主要分支。
上一篇已經有：
Feature
↓
PBI
↓
Task
到了真正開發時，我們最關心的是：
這支 Branch 是為了哪一張 Task？
所以公司流程會把：
Task
和：
Branch
綁在一起。
這樣之後就可以從：
Task
看到：
對應的 Branch
也可以從 Branch 追到：
這支分支到底是為了哪張工作單建立的？
整條關係就會變成：
需求
↓
Task
↓
Branch
↓
Commit
↓
Pull Request
在我們目前的流程裡，可以直接從黃色 Task 建立 Branch。
進入自己的 Task 後，在工作項目的選單中選擇：
New Branch
建立新的 Branch。
這種方式的好處是：
Branch
可以直接和這張 Task 建立關聯
不用之後再回頭找 Work Item。
建立時通常會需要確認：
Branch Name
Repository
Base Branch
Work Item
其中最重要的是：
Branch 到底從哪一支分出去？
例如：
main
↓
建立新的工作 Branch
那新 Branch 的起點就是：
main 當下的版本
自己練習 Git 時，可能會取：
test
new
abbie
甚至：
final
但企業專案通常會有 Branch 命名規則。
我們目前使用的格式例如：
組別-員編-年月日-時間
例如：
AP04-E1087-20240126-1200
這不是 Git 規定的格式。
是：
公司的 Branch 命名規範
不同公司可能會使用：
feature/功能名稱
bugfix/問題名稱
員編-日期
工單號-功能名稱
等等。
所以重點不是背：
Branch 一定要叫 AP04-...
而是：
進公司後要遵守團隊的 Branch Naming Convention
建立 Branch 時，還可能看到：
Work items to link
意思就是：
這支 Branch 要跟哪一張 Work Item 建立關聯？
在我們目前的流程裡，通常會綁：
Task
也就是之前說的黃色工作單。
例如：
Task #12345
新增詳細資料頁部門欄位
建立 Branch：
AP04-E1087-20240126-1200
兩邊建立關聯後，就可以知道：
這支 Branch
就是為了 Task #12345
除了從 Task 建立之外，也可以到：
Repos
↓
Branches
建立新的 Branch。
這種方式一樣可以建立分支。
差別是：
如果不是從 Task 建立
就要自己確認 Work Item 有沒有正確綁上去
所以流程可能變成：
Repos
↓
Branches
↓
New Branch
↓
輸入 Branch Name
↓
選擇 Base Branch
↓
選擇 Work Item
兩種方式都能建立 Branch。
只是公司實際希望用哪一種，要跟團隊流程走。
建立完成後，回到 Task。
可以查看：
Development
Links
Branch
之類的關聯資訊。
如果正確綁定，就能看到：
這張 Task
↓
對應哪一支 Branch
這一步很值得確認。
不然到了後面 PR 才發現：
Branch 根本沒綁到正確的 Task
又要回頭整理。
這是我第一次做最容易疑惑的地方。
我明明在 Azure DevOps：
Branches
已經看到：
AP04-E1087-20240126-1200
結果打開 Visual Studio：
找不到。
蛤？
原因是：
Azure DevOps
是在 Remote
而：
Visual Studio
目前看到的是我的 Local Repository 狀態
遠端剛建立一支新的 Branch，不代表我的本機會即時自動知道。
這時候就需要：
Fetch
Fetch 中文可能會看到：
擷取
它可以先理解成：
去 Remote Repository 看看現在有哪些新的 Branch 和 Commit，更新我本機所知道的遠端資訊。
方向大概是：
Azure DevOps
Remote Repository
↓
Fetch
↓
我的電腦
更新遠端資訊
注意：
Fetch
不是直接把遠端程式整個合進我現在的 Branch。
它比較像：
先更新情報
例如 Azure DevOps 剛新增：
AP04-E1087-20240126-1200
我的 Visual Studio 原本不知道。
執行：
Git
↓
Fetch
之後：
Visual Studio
現在知道遠端有這支 Branch 了
這兩個超容易混。
我現在會這樣記：
Fetch
↓
更新「遠端有哪些東西」的資訊
Pull
↓
把遠端的新版本抓回來
並整合到我目前的本機 Branch
所以：
我只是想找剛建立的遠端 Branch
這時通常先：
Fetch
就有機會找到。
不是看到遠端有更新就：
一直 Pull
如果我的電腦：
完全還沒有這個 Repository
那就不是 Fetch 或 Pull。
而是：
Clone Repository
複製存放庫
Clone 可以先理解成：
第一次把整個遠端 Repository 和版本歷史建立到自己的電腦。
例如：
Azure DevOps
Remote Repository
↓
Clone
↓
我的電腦
Local Repository
所以可以簡單分：
第一次完全沒有專案
↓
Clone
本機已經有 Repository
只是要知道遠端最新 Branch / Commit
↓
Fetch
本機已經有 Repository
想把目前 Branch 更新成遠端最新版本
↓
Pull
| 操作 | 什麼時候用 | 白話理解 |
|---|---|---|
| Clone | 第一次取得 Repository | 整個專案第一次抓到本機 |
| Fetch | 想更新遠端資訊 | 看遠端最近多了什麼 |
| Pull | 想更新目前本機 Branch | 把遠端內容抓下來並整合 |
這三個用途真的不一樣。
公司 Azure DevOps 裡可能不只有一個 Repository。
例如依不同專案分類可能有：
DBSchema
eHealth
HIS
HIS-TEST
不同 Repository 管理不同程式內容。
所以開始工作前不能只確認：
Branch 名稱對不對
還要確認：
Repository 對不對
不然可能發生：
Branch 明明建立了
Visual Studio 怎麼永遠找不到？
結果是：
Azure DevOps Branch 建在 Repository A
Visual Studio 卻正在看 Repository B
當然找不到。
所以我現在遇到：
Branch 不見了
第一個不會再只想：
Visual Studio 壞掉了。
而是先檢查：
Repository
假設現在 Azure DevOps 已經建立：
AP04-E1087-20240126-1200
而且是在正確 Repository。
接著進 Visual Studio。
先執行：
Git
↓
Fetch
讓本機更新 Remote Branch 資訊。
接著打開：
View
↓
Git Changes
或 Visual Studio 提供的 Branch 管理介面。
在 Branch 選單中搜尋：
自己的員編
或完整 Branch 名稱。
例如：
E1087
找到：
origin/AP04-E1087-20240126-1200
這類遠端 Branch。
接著就要：
Checkout
Checkout 中文可能會看到：
簽出
第一次看這個翻譯真的很難理解。
我現在會直接把 Checkout 記成：
切換到我要工作的 Branch。
例如我原本在：
main
Checkout：
AP04-E1087-20240126-1200
之後：
Visual Studio
目前工作分支
就變成這一支。
也就是：
main
↓
Checkout
↓
AP04-E1087-20240126-1200
從現在開始修改的程式，就是在：
這支 Branch
上進行。
Azure DevOps 剛建立的是：
Remote Branch
因為它在：
Remote Repository
Fetch 後，我的 Visual Studio 知道：
遠端有這支 Branch
再 Checkout 後，Visual Studio 會在本機建立對應的工作 Branch。
可以先理解成：
Azure DevOps
Remote Branch
AP04-E1087-20240126-1200
↓
Fetch
知道它存在
↓
Checkout
↓
Visual Studio
Local Branch
AP04-E1087-20240126-1200
這支 Local Branch 通常也會追蹤對應的 Remote Branch。
後面：
Push
Pull
才知道要跟哪一支遠端 Branch 同步。
在 Visual Studio 裡可能看到：
origin/main
或者：
origin/AP04-E1087-20240126-1200
這裡的：
origin
通常是 Remote 的名稱。
可以先簡單理解成：
origin/main
↓
遠端 main
而：
main
則是：
我的 Local main
所以：
origin/AP04-E1087-...
可以先理解成：
Azure DevOps 上那支遠端 Branch 的資訊
Checkout 之後，我才會有自己本機真正工作的：
AP04-E1087-...
這個我覺得很實用。
如果 Azure DevOps 明明有 Branch，但 Visual Studio 找不到，我會依序確認：
第一個
Azure DevOps 上真的有建立成功嗎？
↓
第二個
Branch 建在哪個 Repository？
↓
第三個
Visual Studio 現在連的是同一個 Repository 嗎？
↓
第四個
有沒有執行 Fetch？
↓
第五個
搜尋的 Branch 名稱有沒有打錯？
可以直接記成：
1. Branch 存不存在
2. Repository 對不對
3. Visual Studio 連線對不對
4. Fetch 了沒有
5. Branch Name 對不對
通常就比：
一直重開 Visual Studio
有效很多。
Checkout 完成後，我現在不會馬上開始改。
會先確認：
目前所在 Branch
在 Visual Studio 的：
Git Changes
上方，通常可以看到目前 Branch。
例如：
AP04-E1087-20240126-1200
我要確認：
這就是目前這張 Task 對應的 Branch
才開始修改。
因為最怕的是：
以為自己在工作 Branch
結果其實還在 main
然後改了半天。
這種真的會很麻煩。
所以現在我會把：
確認 Branch
當成開始開發前固定的一個動作。
一個 Branch 通常是為了：
一個工作目的
建立的。
例如：
Task #1234
↓
Branch A
這個工作完成、PR 合併後，這支 Branch 的任務基本上就完成了。
下一張新的 Task：
Task #5678
通常應該重新建立：
Branch B
而不是：
Branch A 做完
↓
繼續拿來做 Task #5678
否則：
Work Item
Branch
Commit
PR
之間的關係就會開始混亂。
所以：
一張新的工作
↓
新的 Branch
通常會比較乾淨。
實際還是依公司的 Branch Policy。
我們目前的流程是：
PR 完成
↓
Branch 合併
↓
這支工作 Branch 不再繼續使用
下一個工作重新建立新的 Branch。
這也是為什麼 Branch 名稱裡會放：
員編
日期
時間
因為每次工作都可能建立新的分支。
這是公司的工作規範，不是 Git 強迫所有團隊都這樣使用。
如果 Branch 是從：
main
建立。
那建立 Branch 之前，最好先確認：
這個 main 是不是團隊目前預期的最新版本？
因為如果：
遠端 main
已經到 Commit D
但是本機還停：
Commit B
然後從 B 開一支 Branch。
我的工作一開始就會少：
Commit C
Commit D
不過我們現在主要是：
先從 Azure DevOps 建 Remote Branch
所以要確認建立 Branch 時使用的：
Base Branch
就是團隊目前要求的目標 Branch。
實際更新 main、Merge main 的時間點，後面 PR 前還會再遇到。
上一篇停在：
找到 Task
今天就變成：
Task
↓
New Branch
↓
設定 Branch Name
↓
確認 Base Branch
↓
Link Work Item
↓
建立 Remote Branch
↓
Visual Studio
↓
Fetch
↓
找到 Remote Branch
↓
Checkout
↓
建立 / 切換 Local Branch
↓
確認目前 Branch
↓
開始開發
這樣工作單就真的開始跟程式碼連起來了。
如果今天拿到：
Task #12345
新增詳細資料頁部門欄位
我現在會先：
第一步
確認 Task
↓
第二步
從 Task 建立 Branch
↓
第三步
依公司規則命名 Branch
↓
第四步
確認 Work Item Link
↓
第五步
確認 Repository
↓
第六步
到 Visual Studio
↓
第七步
Fetch
↓
第八步
搜尋自己的 Remote Branch
↓
第九步
Checkout
↓
第十步
確認 Git Changes 上方目前 Branch
↓
第十一步
開始修改程式
到了這一步，才真的正式進入：
開發
這幾個真的很容易混，所以我最後再整理一次。
Clone
↓
我的電腦原本完全沒有 Repository
第一次把專案抓下來
Fetch
↓
本機已經有 Repository
更新遠端 Branch / Commit 的資訊
Pull
↓
把遠端目前 Branch 的更新抓回本機並整合
Checkout
↓
切換到我要工作的 Branch
如果只想記白話版：
Clone
第一次拿專案
Fetch
更新遠端情報
Pull
把更新拉進來
Checkout
換到我要工作的分支
找到工作單之後：
不是直接改 main。
而是先把工作跟 Branch 建立關係。
在我們目前的工作流程裡，大概是：
Task
↓
建立 Branch
↓
Branch 綁 Task
↓
Visual Studio Fetch
↓
取得 Remote Branch 資訊
↓
Checkout
↓
切到自己的 Local Branch
↓
確認 Branch
↓
開始開發
其中最容易搞混的是：
Azure DevOps 已經有 Branch
≠
Visual Studio 立刻知道
所以才需要：
Fetch
另外也要分清楚：
Clone
第一次取得 Repository
Fetch
更新 Remote 資訊
Pull
同步目前 Branch 的內容
Checkout
切換 Branch
而我現在開始改程式以前，會先固定確認兩件事：
Repository 對不對？
Branch 對不對？
這兩個對了，才真的開始寫。
接下來就進入最後一個實際問題：
好。
Branch 也對了。
功能也寫完了。
Build 也過了。
那我要怎麼把這次修改交出去？
Git Changes 要看什麼？
Commit 和 Push 差在哪？
什麼時候要 Fetch / Pull？
最後 Pull Request 又要怎麼開？
下一篇：
程式改完怎麼送出去？Git Changes、Commit、Push 到 Pull Request 一次走完。
iThome鐵人賽
看影片追技術