Git 版本控制系統
講者： 黃致維
人生不能重來但是 Git 可以
你可以從中獲得
- 為什麼我們需要版本控制？
- 熟悉 git 的基本操作
- 開發模式 git flow 與 commit 規範
- 為什麼我們會選擇 git
為什麼需要版本控制？
程式不只一個人在開發
狀況一
程式改壞了怎麼辦？
狀況二
為什麼需要版本控制
- 開發不只你一個人
- 時間不能重來
- 程式碼差異
抓戰犯
熟悉 Git 的基本操作
- windows: 影片教學
- Linux: apt-get install git
- Mac: Homebrew
安裝 git
或是可以看一下 官網 上的說明
要先在 Git 設定你的帳號
$ git config --global user.name "你的名字"
$ git config --global user.email "你的 email"Git 的基本流程
讓 git 認識你的專案
$ git init專案根目錄
開始 Codding
專案根目錄
開始寫 code
將檔案加入追蹤
專案根目錄
$ git add file1
$ git add file2git 暫存檔案的空間 stage
stage
- file1
- file2
$ git status建立存檔點
專案根目錄
$ git commit -m "加入了兩隻檔案"commit: 加入了兩隻檔案
總結一下
- 編輯
- 加入追蹤
- commit
Git 的基本流程
- 工作區
- 暫存區
- 存儲庫 （Repository）
Git 的工作區
狀況題
我要如何查看現在或是之前的 commit ?
$ git log
我要如何回到過去的 commit ?
$ git reset --hard HEAD^
$ git reset --hard HEAD~1$ git reset --hard e2a9357a862b4bbb37257dc3e36bc60932bbfcdd我要如何知道目前的修改了什麼內容？
$ git diff
在 檔案 加入 stage 前，我要如何取消這次的檔案變更
$ git checkout .
我可不可以一次將所有的檔案
加入 stage ?
$ git add .將所有的檔案加入 暫存區 (stage)
如果有檔案不想加入 Git 追蹤
.gitignore
新增 .gitignore 的檔案，並將不想加入追蹤的檔案路徑加入就可以了
如果有檔案不想加入 Git 追蹤
要怎麼做？
.gitignore
新增 .gitignore 的檔案，並將不想加入追蹤的檔案路徑加入就可以了
分支 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>(project):#ticketnumber subject- 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
容易誤解的觀念
不等於
應用程式
網站
建立新的專案
加入已經存在的專案
完成
關鍵指令
$ git remote add origin [URL]設定要連結雲端上的版本庫的 URL
$ git push -u origin master本地 master 的 branch
推上
雲端 master branch
更新雲端上的 master branch
$ git push推其他的 branch 上去雲端空間
$ git push origin [branch 名稱]狀況題
我要如何從 Git Hub
上取得專案？
$ git clone {URL}
為什麼
git push 推不上去 GitHub ?
push 前一定要記得
$ git pullpull = fetch + merge
將最新的 commit 拉到本地端
解決衝突後，在做 push 的動作
$ git push -f
本來不想用這招的
為什麼使用 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 嗎？
$ git reset --hard HEAD^重新設定
GO TO
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
發生了什麼事？
$ git branch branch1新增 branch
Blob
A.txt
C.txt
first commit
Tree
Blob
Blob
B.txt
Commit
HEAD
master
branch1
切換分支時
發生了什麼事？
$ git checkout 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
很潮
參考資料
