Git 版本控制系統

講者： 黃致維

人生不能重來但是 Git 可以

你可以從中獲得

• 為什麼我們需要版本控制？
• 熟悉 git 的基本操作
• 開發模式 git flow 與 commit 規範
• 為什麼我們會選擇 git

為什麼需要版本控制？

程式不只一個人在開發

狀況一

程式改壞了怎麼辦？

狀況二

為什麼需要版本控制

• 開發不只你一個人
• 時間不能重來
• 程式碼差異
• 抓戰犯

熟悉 Git 的基本操作

• windows:  影片教學
• Linux:  apt-get install git
• Mac: Homebrew

安裝 git

或是可以看一下 官網 上的說明

要先在 Git 設定你的帳號

Git 的基本流程

讓 git 認識你的專案

專案根目錄

開始 Codding

專案根目錄

開始寫 code

將檔案加入追蹤

專案根目錄

git 暫存檔案的空間 stage

stage

• file1
• file2

建立存檔點

專案根目錄

commit: 加入了兩隻檔案

總結一下

• 編輯
• 加入追蹤
• commit

Git 的基本流程

• 工作區
• 暫存區
• 存儲庫 （Repository）

Git 的工作區

狀況題

我要如何查看現在或是之前的 commit ?

我要如何回到過去的 commit ?

我要如何知道目前的修改了什麼內容？

在 檔案 加入 stage 前，我要如何取消這次的檔案變更

我可不可以一次將所有的檔案

加入 stage ?

如果有檔案不想加入 Git 追蹤

.gitignore

新增 .gitignore 的檔案，並將不想加入追蹤的檔案路徑加入就可以了

如果有檔案不想加入 Git 追蹤

要怎麼做？

分支 Branch

分身要是被打爆了，並不會影響到本體

規範

規範

當專案的開發人數一多

branch 與 commit 沒有良好的規範

碰到剛剛圖片上的情景，是早晚的

所以事先定義好良好的 規範 是十分重要的

• 代碼模組化
• branch :  git Flow
• commit : 命名規則

檔案規範

代碼模組化

• 盡可能不要在同一個檔案上進行編輯
• 代碼有良好的模組化結構，且良好的分檔

Branch 規範

• Git Flow,
• GitLab Flow
• GitHub Flow
• .......

Branch 的流程與規範

Branch 規範

Git Flow

在 2010 年的時候，就有人提出了一套流程，或說是訂了一套規矩讓大家可以遵守：參考網址

• master (長期分支) 商品主線
• release (長期分支) 上線前最後確認
• develop (長期分支) 開發的主線、
• hotfix （短期分支) 功能緊急修復、
• feature (短期分支) 功能開發

commit 規範

commit 規範

一定要明確的告訴隊友或是自己

這個 commit 是為了什麼

最好要有一個共同的格式

commit 規範

• type （必填）： 說明 commit 的類別
• project (選填) ： 說明專案名稱
• ticketnumber (選填)： Remind 的單號
• subject (必填)： 簡短的說明 commit 的目的

commit 規範

• feat ： 新增新功能
• fix：修補臭蟲
• docs：修改文檔
• style：格式 （不影響代碼運行的變動）
• refactor：重構 （既不是新功能也不是修改 bug）
• test： 增加測試
• chore：建構過程或是補助工具的變動

可用的 type 標籤

commit 規範

• docs: 修正jshint設定檔
• feat(batchUpdate):新增f8 beta環境的.ini
• fix:#20027 調整購物車沒有規格項目沒有庫存時，會顯示為「已售完」
• chore:調整phalcon composer
• style:#20037 調整mall首頁大banner樣式
• test:新增「加入購物車」邏輯的測試碼
• docs:更新購物車API文件
• chore:升級前台jquery版本

實際範例

Git Remote

分享你的 Git 專案吧

通常我們會把一個 Git 的專案稱為： Repository 版本庫

另外我們會將 Git 的 版本庫放置到

擁有 Git 介面的雲端空間

Git Remote

• Git Hub 全球最大同志交友平台
• Git Lab

容易誤解的觀念

不等於

應用程式

網站

建立新的專案

加入已經存在的專案

完成

關鍵指令

設定要連結雲端上的版本庫的 URL

本地 master 的 branch

推上

雲端 master branch

更新雲端上的 master branch

狀況題

我要如何從 Git Hub

上取得專案？

為什麼

git push 推不上去 GitHub ?

push 前一定要記得

pull = fetch + merge

將最新的 commit 拉到本地端

解決衝突後，在做 push 的動作

本來不想用這招的

為什麼使用 Git

他跟其他版本控制系統的差別在哪了

• 很潮
• 分散式管理
• 更輕巧更快速
• Git 開分支很便宜

分散式管理 vs 集中式管理

集中式：

• 只允許 一個版本庫 在伺服器中
• 大部分的操作都無法離開伺服器，例如：提交變更 等等

分散式：

• 允許每個工作者在 Local 端 都可以擁有各自的版本庫
• 可以在自己的本地端完成任何操作

一般版控：

Git  vs 一般版控

Git 的資料結構

Git  vs 一般版控

Git 資料結構

四大物件

• Blob (檔案)
• Tree (目錄)
• Commit
• Tag

Git 資料結構

Blob

Blob

Commit

Tree

Blob

A.txt

B.txt

C.txt

lib 資料夾

first commit

HEAD

Blob

A.txt

C.txt

lib 資料夾

first commit

修改了 B 的檔案

B.txt

Tree

Blob

Blob

Commit

HEAD

Blob

B.txt

Commit

Blob

Commit

Blob

A.txt

B.txt

C.txt

lib 資料夾

first commit

修改了 B 的檔案

B.txt

Tree

Blob

Blob

Commit

HEAD

大家還記得如何回到之前的 commit 嗎？

Commit

Blob

A.txt

B.txt

C.txt

lib 資料夾

first commit

修改了 B 的檔案

B.txt

Tree

Blob

Blob

Commit

HEAD

Blob

Git 開分支很便宜

Blob

A.txt

C.txt

first commit

Tree

Blob

Blob

B.txt

Commit

HEAD

master

新增 branch

發生了什麼事？

Blob

A.txt

C.txt

first commit

Tree

Blob

Blob

B.txt

Commit

HEAD

master

branch1

切換分支時

發生了什麼事？

切換 branch

Blob

A.txt

C.txt

first commit

Tree

Blob

Blob

B.txt

Commit

HEAD

master

branch1

Blob

A.txt

C.txt

lib 資料夾

first commit

修改了 B 的檔案

B.txt

Tree

Blob

Blob

Commit

HEAD

Blob

B.txt

Commit

master

branch1

很潮

參考資料

• 為你自己學 Git

• 從集中版本控制到分散式版本控制

• Git 的實物圖解

Q & A

Thank You