Chapter 4 GitHub Desktop-group

小情境

讓我們用以下的小情境想像一下利用版本控制進行團隊開發時，最重要的三個概念：

小瑜與小宜被分配到要完成同一個報告，他們也決定要透過版本控制來協作這次的報告，藉此減少必須碰面的時間成本與協商成本。

若他們彼此都修改同一份檔案，小瑜負責人物介紹，小宜負責歷史沿革，突然之間收到通知，老師要求就人物介紹的章節先跟他進行meeting，請問小瑜要怎麼辦？

他可以熬夜完成人物介紹，但是小瑜的歷史沿革可能來不及…..要刪掉嗎？

神啊！能不能讓我們在平行時空下編輯同一份檔案？

所以有了分支Branch!

小瑜以及小宜開設了一個屬於自己的分支，分別在自己的分支上撰寫所分配到的報告內容，截止期限要到了，準備繳交的時候才想起原來彼此都只有一部分的成果，怎麼辦呢？總不能永遠都傳檔案給對方，要對方打開檔案去找我寫的那個章節在哪，這份報告有20000字將近三十頁耶…..真麻煩＠＠

神啊！能不能讓兩個平行時空收斂啊！！？？

於是有了pull request，可以把別人的程式段落拉進來，或者將自己的程式段落送出去給別人。

小瑜是組長，於是小宜送了一個pull request給她，這時才想起彼此都有對一開始的研究動機修正了一些，這時候到底要用誰的內容呢？

…..比文采嗎？比誰先改完嗎？比誰改得多嗎？

好像都不太對……

神啊！能不能讓兩個平行時空收斂的時候可以絕對的穩定？

有時候需要有人resolve conflict

組長小瑜手動解決衝突後，趕在23:59送出信件，一切大功告成！終於可以洗洗睡了~~

是不是很方便呢？

畢竟隔壁組的還在討論要用哪個圖呢XD

截圖

branch名稱建議是Task-orientation較佳，也易於辨認。
- bug-fix (O)
- certain username (O)
- 一群亂碼SDAJFLSDAJLKFJSLDAKF (X)
master具體來說稱作master branch，其實也是一個branch，通常理解為主幹道(有一點點特殊意義XD)，通常會將整個程式專案的穩定版本（已經達成高度共識的版本放在master），團隊開發者再從這個地方開所需的branch出去，並且定期回顧與更新。

截圖

pull request可以在任兩個branch之間執行，包含有無涉及master branch。
- branchX進到master branch或者反過來master branch進到branchX都沒問題。
- branchX到branchY，或反過來，也都沒問題。
設定合併來源與對象
- base: 準備要被塞內容進去的那個branch
- compare: 準備要送內容出去的那個branch
pull request伴隨著就是程式審核(code review)，通常會需要寫說明本次pull request是修正了哪些地方等等細節的描述。