回顧一下上一節課...

git flow vs github flow

1. git flow 有兩個長期分支，github flow 只有一個

2. git flow 較為複雜，但是相對嚴謹，適合定期發佈       的專案

3. github flow 較為簡單，適用於需要持續發佈的軟       體專案

回顧一下上一節課...

1. fork 是 github 的功能，是指把專案複製到你自己的 github 帳號

2. git clone 則是把遠端的 git 專案複製到本機端

git pull origin 遠端 repo 分支名稱

3. git pull 則是指把遠端 repo 的 commit '拉' 下來到本機端

git clone github repo 連結

回顧一下上一節課...

會出現 "衝突" 通常都是在分支合併時發生，也就是執行以下幾種指令時:

git pull 遠端分支時

git merge 其他分支時

git rebase 其他分支時

高效小套路

git add .
git commit -m "你的備註"

可以用以下指令替代:

git commit -a -m "你的備註"

每一個檔案都需要 add 再 commit，很麻煩啊...

注意此指令對狀態為 untracked，也就是新增的檔案無效 

高效小套路

git branch new_branch
git checkout branch

可以用這個指令替代:

git checkout -b new_branch

需要先創出 branch 再切換，很容易搞混啊...

高效小套路

今天若要在指令列上看分支圖:
 
git log --graph --oneline --all

需要先創出 branch 再切換，很容易搞混啊...

高效小套路

切換到根目錄下:

touch ~/.bashrc

接下來用 code 開啟該檔案:

code .bashrc

接下來就可以在 .bashrc 裡寫入:

alias 你自訂的指定='實際 git 的指令'

範例:

alias gst='git status'

改完後執行

source ~/.bashrc 

重新載入指令列設定即可
接下來要在 git bash 裡輸入 gst 就可得到 git status 的效果 

可以利用 .bashrc 設定自己的快捷指令...

修改分支內容

當一個專案的分支越開越多，勢必會發生 commit 在錯誤分支上的窘境，或是因為需求而將一個分支的 commit 移動到另一個分支

移動 commit 至另一個分支

當一個專案的分支越開越多，勢必會發生 commit 在錯誤分支上的窘境，或是因為需求而將一個分支的 commit 移動到另一個分支

git stash

當你功能開發到一半，被緊急 “插件” 一定手忙腳亂，手邊若有寫到一半的程式碼該如何處理？

git stash

這樣你目前的進度就會被當成是一個暫存版本保留起來，接下來當你完成了處理緊急插件後，就回到原本的分支，執行

git stash pop

所以今天若要移動一個 commit 至另外一個分支，利用我們剛才學會的 git stash，你可以:

移動 commit 至另一個分支

git reset --soft HEAD^

git stash

git checkout 目的分支

git stash pop

git commit

git cherry-pick

當你在一個分支中開發了一段時間，但後來決定整個分支需要砍掉，但是分支裡有幾個版本還想留下的狀況

如同名字 "摘櫻桃" - 手動挑出需要的 commit

git cherry-pick

https://github.com/yuyueugene84/ntu_git_lesson3/tree/master

請 fork 並且 clone 今天練習用的 repo:

git cherry-pick

執行：

git pull origin master
git checkout feature4
git pull origin feature4

git cherry-pick

若我們今天是要把 added lesson3_6.md 這個 commit 從 feature4 移至 master：

git cherry-pick

執行：

git log --oneline feature4

應該會呈現：

先用 git log 查看該 commit 的編號：

git cherry-pick

現在我們知道 該 commit 是 3208f0a

git cherry-pick

接下來我們就在 master 分之上執行：

git cherry-pick 3208f0a

 用 git status 查看:

gitlab flow

除了 git 與 github flow 之外，還有一種流程叫做 gitlab flow

gitlab flow

1. Upstrem first (上游優先)

2. Master 為 pre-production 和 production 的上游

3. 所有的變化需要先 merge 到 master，才能被下游採用

在持續發佈的專案裡，production 和 pre-production 分別是指 production 和 staging 環境

gitlab flow

gitlab flow

Hotfix 處理方式：

1. 開 feature branch

2. merge master

3. cherry-pick 到下游分支

好處是這樣你不會忘記要把 hot fix commits 放入 master，避免未來其他下游分支出現同樣 bug

gitlab flow

kanban (看板)管理法

影片

kanban (看板)管理法

• 源自日本 Toyota 汽車的管理模式
• 用視覺化的方式顯示生產線的的資訊
• 降低庫存，客戶提出需求才開始製造

kanban (看板)管理法

• 根據團隊的開發流程，在看板上畫出相對應的工作階段
• 一個功能直到被開發出來之前，都不具備任何意義
• 限制不同階段進行中的任務數量(一個階段四個)，若一個工作階段已經額滿，就需要幫目前仍卡在該工作階段的人將手上的工作進入到下一個階段

kanban (看板)管理法

一些實用的工具:

trello

asana

gira