前面幾天都還在處理：
怎麼看懂 MVC
怎麼追 Controller / Service
怎麼下中斷點
怎麼看變數
怎麼處理 Error
程式總算開始比較看得懂了。
但進公司之後，我又遇到另一組很熟又很陌生的東西：
Git
GitHub
Azure DevOps
其實以前學 React 的時候，我就有用過 Git。
那時候大概知道：
寫完程式
↓
Commit
↓
Push
↓
GitHub
作品也會放到 GitHub Repository。
所以那時很容易把：
Git
和：
GitHub
混在一起。
甚至會有一種：
Git 就是把程式推到 GitHub 的東西吧？
的感覺。
結果進公司後：
Git 還是在用
但是原本熟悉的 GitHub 不見了。
換成：
Azure DevOps
蛤？
所以 Git 可以不用 GitHub？
那 GitHub 跟 Azure DevOps 到底是在做什麼？
這篇就先把這幾個東西分清楚。
以前寫 React 練習專案時，可能會有一個專案：
my-react-app
在 VS Code 裡開發：
src
public
package.json
...
接著透過 Git 留下版本紀錄。
最後再把程式 Push 到 GitHub。
整個概念大概是：
VS Code
↓
React 專案
↓
Git
↓
GitHub
因為 GitHub 一直跟 Git 一起出現，所以我以前會下意識覺得：
Git ＝ GitHub
但其實兩個完全不是同一個東西!!
Git 是：
Version Control System
版本控制系統
白話一點就是：
幫我們記錄程式碼每一次修改的版本。
假設今天寫了一個登入功能：
第一版
建立登入畫面
↓
第二版
串接登入 API
↓
第三版
加入錯誤提示
↓
第四版
修正登入 Bug
Git 可以把這些修改一筆一筆記錄下來。
所以不是：
login-final
login-final2
login-final-new
login-final-真的好了
login-final-拜託不要再改
而是有正式的：
版本紀錄
可以知道：
誰修改的
什麼時候修改的
修改了哪些內容
這次修改的目的
最基本可以先記幾件。
例如：
建立會員查詢功能
之後又：
修正會員查詢條件
再之後：
新增部門名稱欄位
每一次都可以留下不同版本。
Git 可以看到：
原本
和：
現在
到底差在哪。
例如原本：
Name = user.Name
後來改成：
Name = user.Name,
DepartmentName = user.DepartmentName
Git 可以知道：
這裡新增了一行
這就是之後會一直看到的：
Diff
公司裡當然不可能只有一個人改程式。
可能同時：
A 工程師
改登入
B 工程師
改報表
C 工程師
改會員資料
所以 Git 還有：
Branch
讓大家可以在不同分支工作，再把修改整合回去。
Branch 後面會再慢慢講。
如果今天突然發現：
咦？
這個功能以前明明正常，
到底是哪一次開始壞掉的？
也可以透過 Git History 去找以前的版本。
所以 Git 本質上是在管理：
程式版本
不是在管理某一個網站。
GitHub 則是一個：
Git Repository 託管與團隊協作平台
這句第一次看很硬。
可以先理解成：
Git 負責版本控制，GitHub 則可以把 Git Repository 放到網路上，讓自己或團隊一起使用。
所以以前 React 的情況可以畫成：
我的電腦
React 專案
↓
Git
↓
網路
↓
GitHub
GitHub 是：
程式放在遠端的地方之一
而不是：
Git 本身
這時候會一直看到一個字：
Repository
簡稱：
Repo
可以先理解成：
一個被 Git 管理的專案，以及這個專案的版本歷史。
例如：
my-react-app
使用 Git 管理後，就可以是一個 Git Repository。
Repository 裡不只有：
現在的程式碼
還包含 Git 所管理的：
Commit
Branch
版本歷史
Repository 又可以先分成兩個位置。
Local Repository
本機 Repository
就是：
在我的電腦
另外還有：
Remote Repository
遠端 Repository
就是：
放在遠端、讓團隊可以共同存取
例如：
我的電腦
Local Repository
↓
Push
↓
GitHub
Remote Repository
所以以前 React 專案 Push 到 GitHub，其實是在做：
把本機 Git Repository 的版本
送到遠端 Git Repository
這樣一想就清楚很多~~
不是耶!
這也是我進公司之後才真的意識到的地方
Git 的 Remote Repository 可以放在很多地方!
常見例如：
GitHub
GitLab
Bitbucket
Azure DevOps
所以：
Git
不綁定某一個平台。
可以變成：
Git
↓
GitHub
也可以：
Git
↓
GitLab
也可以：
Git
↓
Bitbucket
也可以：
Git
↓
Azure DevOps
核心的 Git 還是 Git。
只是：
Remote Repository 放的位置不同
自己學 React、做作品集或練習專案時，GitHub 很常見。
例如我以前的流程比較接近：
VS Code
↓
React
↓
Git
↓
GitHub
GitHub 上可以看到：
Repository
Files
Commits
Branches
Pull Requests
也很適合拿來：
放練習作品
分享程式碼
做作品集
參與開源專案
所以剛開始學 Git 時，很容易第一次接觸的遠端平台就是 GitHub。
但這不代表：
公司也一定使用 GitHub
進到公司後，我發現同樣還是在用：
Git
但 Remote Repository 不再放 GitHub。
而是：
Azure DevOps
所以我現在實際工作的結構比較像：
Visual Studio
↓
C# MVC 專案
↓
Git
↓
Azure DevOps
最重要的一件事就是：
以前工具鏈：
VS Code
↓
React
↓
Git
↓
GitHub
現在：
Visual Studio
↓
C# MVC
↓
Git
↓
Azure DevOps
前端框架換了、開發工具也從 VS Code 換成 Visual Studio
遠端平台也換了
但：
Git 沒有消失
Azure DevOps 不只是放 Git Repository 的地方。
它是一套給軟體開發團隊使用的協作平台。
裡面會看到很多功能，例如：
Boards
Repos
Pipelines
Test Plans
Artifacts
目前先不用全部弄懂。
這篇只要先知道：
Azure DevOps
是一整套團隊開發平台
其中跟 Git 最直接相關的是：
Azure Repos
可以先理解成：
Azure DevOps
│
├─ Boards
├─ Repos ← Git Repository 在這裡
├─ Pipelines
├─ Test Plans
└─ Artifacts
Day 27、Day 28 再慢慢進去看
如果只看：
存 Git Repository
這個功能，確實有相似的地方。
例如兩邊都可以看到：
程式碼
Commit
Branch
Pull Request
修改紀錄
所以以前已經用過 GitHub 的話，進 Azure Repos 後不至於完全陌生。
例如：
GitHub Repository
裡面會有：
Code
Commits
Branches
Pull Requests
Azure Repos 也有類似概念：
Files
Commits
Branches
Pull Requests
名稱可能稍微不一樣，但底層很多東西還是在操作：
Git
這裡不用把兩個平台比成：
誰比較好
因為公司選工具有很多原因。
我現在比較會把它們理解成：
都是可以支援 Git 團隊協作的平台
但產品定位和整合方式不完全一樣
可以先這樣看：
| 比較 | GitHub | Azure DevOps |
|---|---|---|
| Git Repository | 有 | 有，主要在 Azure Repos |
| Branch | 有 | 有 |
| Commit History | 有 | 有 |
| Pull Request | 有 | 有 |
| Code Review | 有 | 有 |
| 工作追蹤 | Issues / Projects 等 | Azure Boards |
| CI/CD | GitHub Actions | Azure Pipelines |
| 套件管理 | GitHub Packages | Azure Artifacts |
| 常見使用情境 | 個人作品、開源、團隊開發都很多 | 企業團隊、Microsoft 生態系統中也很常看到 |
所以不能理解成：
GitHub
只能個人用
Azure DevOps
才是公司用
這樣不準確。
GitHub 也有很多企業使用。
Azure DevOps 也不是只有大型公司才能用。
真正的差別比較在：
團隊選擇哪一套平台
以及公司原本的開發流程怎麼設計
這個我覺得很重要。
以前 React：
GitHub
現在公司：
Azure DevOps
一開始會以為：
我要重新學一套版本控制？
其實不是。
因為底層還是在用：
Git
所以：
Commit
Branch
Push
Pull
Merge
這些核心概念還是存在。
真正不同的是：
平台介面
團隊規則
權限
PR 流程
工作項目
Pipeline
Branch Policy
這些才是進公司後要重新適應的地方。
所以以前 React 專案推 GitHub，其實已經有學到一些可以帶進公司的東西。
例如：
Repository 是什麼
Commit 是什麼
Push 是什麼
Branch 是什麼
Remote 是什麼
只是以前可能只是：
照教學操作
到了公司之後，開始真的需要理解：
為什麼要這樣做？
例如：
為什麼不能直接改 main？
為什麼要開自己的 Branch？
為什麼 Commit 完 Azure DevOps 還看不到？
為什麼 Push 之後還不能直接合併？
為什麼還要 Pull Request？
Reviewer 又是在看什麼？
這些後面才慢慢接起來。
以前用 VS Code 時，可能會直接打：
git add .
git commit -m "update"
git push
進公司改用 Visual Studio 後，很多 Git 操作可以直接從介面完成。
例如：
Git Changes
Branches
Commit
Push
Pull
Fetch
但這不是說：
Visual Studio 有自己的版本控制系統
底層操作的還是：
Git
只是 Visual Studio 幫我們做了一層操作介面。
所以：
Command Line Git
和：
Visual Studio Git
不是兩套不同 Git。
本質還是同一套 Git。
以前 React：
VS Code
↓
React 專案
↓
Git
↓
Local Repository
↓
Push
↓
GitHub
Remote Repository
現在公司：
Visual Studio
↓
C# MVC 專案
↓
Git
↓
Local Repository
↓
Push
↓
Azure DevOps
Azure Repos
Remote Repository
所以最核心的一句就是：
平台換了
Git 沒有換
這兩個平台都不是單純的：
雲端硬碟
不是把：
整個專案資料夾拖上去
這麼簡單。
它們是建立在：
Git Repository
的概念上。
所以會知道：
哪些是 Commit
哪一支 Branch
這次改了哪些行
誰做了修改
兩個 Branch 差在哪
怎麼 Review
怎麼 Merge
這才是 Git 平台真正有價值的地方。
公司選擇開發平台可能跟很多事情有關：
既有系統
團隊流程
權限管理
Microsoft 技術環境
需求管理方式
CI/CD
公司既有工具
維運方式
所以不是：
因為 C# 就一定要 Azure DevOps
也不是：
React 就只能 GitHub
技術上沒有這種綁定!
React 一樣可以放 Azure DevOps
C# 一樣可以放 GitHub
只是我們以前練習 React 時使用 GitHub
現在公司的團隊流程使用 Azure DevOps而已~~
最簡單就是：
Git
↓
版本控制系統
GitHub
↓
可以託管 Git Repository
也提供團隊協作功能的平台
Azure DevOps
↓
也可以管理 Git Repository
而且還整合工作管理、Pipeline 等企業開發功能
所以：
Git
≠
GitHub
Git
≠
Azure DevOps
GitHub
≠
Azure DevOps
但：
GitHub 和 Azure DevOps
都可以跟 Git 一起使用
以前寫 React 時：
VS Code
↓
Git
↓
GitHub
進公司之後：
Visual Studio
↓
Git
↓
Azure DevOps
最重要的不是：
GitHub 被 Azure DevOps 取代了
而是：
Git 本來就可以搭配不同 Remote Repository 平台。
常見例如：
GitHub
GitLab
Bitbucket
Azure DevOps
而我們公司目前使用：
Azure DevOps
所以接下來要開始學的，就不是另一套版本控制。
而是：
同樣使用 Git
但是要開始理解公司的 Azure DevOps 工作流程。
現在整條線可以先畫成：
寫程式
↓
Git 管版本
↓
Local Repository
↓
Push
↓
Remote Repository
Remote Repository 以前是：
GitHub
現在則是：
Azure DevOps
而下一篇，就要真的打開 Azure DevOps。
看看公司裡一直講的：
Boards
Work Items
Sprint
Feature
Product Backlog Item
Task
到底是在管什麼。
以及為什麼還沒開始寫程式之前，我得先找到：
自己這次到底要做哪一張工作單？
下一篇：
第一次進 Azure DevOps：Boards、Work Items、Sprint 和工作項目到底怎麼看？
iThome鐵人賽
看影片追技術