回顧一下上一節課...

git branch feature
git checkout feature

做一些 commmit...

git checkout master
git merge feature

開再多分支，總有合併的一天...

回顧一下上一節課...

# hello world!
<<<<<<< HEAD
# this is my second line of code on master branch
=======
# this is my second line of code
>>>>>>> feature2


從 <<<<<<< HEAD 到 ======= 的內容，HEAD 代表當前 master 分支的最新版 lesson3_2.md 內容

從 ======= 到 >>>>>>> feature2 的內容，代表 feature2 分支裡的 lesson3_2.md 內容

今天兩個要合併的分支都有同一份文件，該文件裡的同一行有兩個不同的版本，就會產生衝突 (Conflict)，需要手動處理衝突

回顧一下上一節課...

另外就是在開出 feture branch 後，我繼續在原本的 master branch 做 commit，導致 master branch 上存在 feature branch 沒有的 commit，在 merge feature branch 時便會產生 merge commit

回顧一下上一節課...

為了避免產生 merge commit，需要確保 feature branch 擁有 master branch 上的所有 commit，就要對 feature branch 做

rebase

git checkout feature

git rebase master

git checkout master

git merge feature

回顧一下上一節課...

圖解 rebase...

git 與多人協作

若今天 git 只有一個人用，只能算是備份程式碼的工具，版本控管機制都是設計給在多人時，能夠有效率並流暢的一起共同開發一個軟體專案，因此，了解如何把 git 導入到團隊的軟體開發流程是重要的。

  git 與多人協作

FDD - Feature Driven Development

功能驅動開發，指的是需求為開發的起點，先有需求、針對需求開出分支 (feature branch)、或是針對需要緊急的修改開出分支(hotfix branch) 。再開發完後，原分支就會被併回到主分支，接著被刪除。

git flow

最早誕生，並且被廣泛使用以 git 為核心的開發流程，核心理念是基於 “版本發佈”，也就是一段時間開發出一個新的版本，該版本包含多個開發出來的 Feature

git flow 教學連結

git flow

因為多個 feature 共同發佈，因此 git flow 就會維持兩個長期的分支：master 與 develop

git flow

master 為主要分支，裡面程式碼是穩定的版本

develop 則用於日常開發，存放最新的開發版本

git flow

另外還有三種短期版本：

feature branch - 從 develop 開出，用於開發，開發                                           完後合併回 develop

hotfix branch    - 補丁分支，代表正式環境需要馬上                                             處理的版本，從 master 開出，合                                             併回develop 和 master

release branch - 發行分支，用於 develop 與 master 在合                                併前(也就是釋出新版本前) 最後一刻的修                                  改從 develop 開出，合併回 develop 和                                  master 分支

git flow

git flow 評價

好處：

  清晰嚴謹

壞處：

  1. 複雜，需要維護兩個長期分支、需要經常切換分            支，大多數的開發者都需要靠工具才能跑的順暢

  2. 在互聯網時代，多數網頁與線上服務都是 "持續發         佈"，定期發佈的步調對這些專案來說都太慢

github flow

為 git flow 的簡化版，是以持續發佈為核心理念，只會維持一個長期分支：master

github flow (流程)

1. 根據需求，從 master 發出新分支，不區分功能與補丁
2. 新分支上的功能開發完成後，向 master 發起 pull request (簡稱 PR)
3. PR 是請團隊的其他成員對你的程式碼做討論和評價(code review)，你可以在code review過程中不斷 push 更多 commit
4. 最後大家都同意並接受了你的程式碼，就會被 merge 回 master 並部署至正式環境

github flow (流程)

github flow (流程)

優點：

1. 簡單

2. 適合用於需要持續發佈的專案

缺點：

有些程式碼併入 master，不代表就能馬上發佈，此時單獨一個長期分支就不夠了

來跑一次 github flow

請大家先找到一個組員 (問一下你的左鄰右舍）

來跑一次 github flow

https://github.com/yuyueugene84/ntu-git-275-lesson4

組員一請到這個 github 專案

來跑一次 github flow

組員一請 fork 該專案到自己的帳號 (fork 是指複製一份 repo 到自己的 github 帳號)

來跑一次 github flow

請所有組員都 clone 組員一的 repo 到自己的本機端

git clone 組員一的 github repo 連結

來跑一次 github flow

組員一記得要把所有的組員都加入 repo 的 collaborators (協作者)，加入後，github 會寄出確認的 email，請確認其他組員都有收到該 email 並且接受

來跑一次 github flow

接下來請組員一建立一個 commit，並 push 上 github

git branch feature

git checkout feature

echo '# my name is 你的名字!' >> 你的名字_exercise4.md

git add 你的名字_exercise4.md

git commit -m "added 你的名字_exercise4.md"

git push origin HEAD

git push origin HEAD 是指要把目前的分支內容同步至 github 專案裡名字一模一樣的分支，若該分支不存在，github 則會自動建立一個

來跑一次 github flow

接下來請到 github 上建立一個 pull request，把 base 設定為 master，compare 設定成 feature

來跑一次 github flow

建立完 Pull Request 之後，要讓你的其他組員幫你做 code review (審核+討論)，確保沒有問題後，由幫你做 code review 的組員按下 merge pull request 按鈕

來跑一次 github flow

此時，組員二也請建立一個 branch: feature2，並加入自己的檔案

git branch feature2

git checkout feature2

echo '# my name is 你的名字!' >> 你的名字_exercise4.md

git add 你的名字_exercise4.md

git commit -m "added 你的名字_exercise4.md"

git push origin HEAD

來跑一次 github flow

現在請組員二建立自己的 pull request，若 github 顯示不能直接 merge，代表 master 上存在 feature2 branch 沒有的 commit，此時我們必須 "更新" feature2 ，確保該分支包含了 github master 分支上最新的 commit：

git checkout master

git pull origin master

git checkout feature2

git rebase master

git push origin HEAD

git pull origin master 是指將遠端 github 上面的 commit 同步至目前本機端的分支