Q3. [團隊技能題組][Git] Git 團隊作業流程。

[wildwindjen]

實務上常常會利用 branch 的機制，來配合個人或團隊的程式開發與部署流程。請設計自己或團隊的開發、部署流程，並查出會使用到的 git 指令。
a. 仿 Q2 那張圖，請提供你個人或團隊設計出來的 git 流程圖。並依據 git 流程圖，解釋每個 branch 的用途，以及列出每個環節所對應的指令。
b. branch 這個機制適合用在什麼狀況？merge 要注意什麼？rebase 又是幹嘛的？
c. diff, show, log, reflog 分別用在哪些情境？
d. 描述你這次是如何完成任務的。運用了哪些資源？

提示:
關鍵字 「git flow」

答題時間: 16 hr

[dustfantasy]

「於 2017/03/26 開始答題」
a.

master
為存放完整功能代碼的支線。

debug
為發現develop支線中bug便移至此支線做修正，在develop完成後移至master前也必須先移至此做檢查修復動作，只用來修正bug。

develop
用於研發的主支線，有代碼主體，對於主體修改與最後整合功能的支線。

feature
額外功能研發支線。

a從master創建develop支線，
b、c為研發的功能創建支線，
d發現bug創建移到debug支線修正，
e為c的工作結束合併至develop，
f為bug修正後合併，
g是為了之前的功能進行完善或重複利用支線研發其他功能而轉移到c所創建的支線，h再次合併，
i為b的功能研發完畢進行合併，
j為在develop上已完成的版本會先轉移到debug做檢查修正，
kl為debug檢查完畢所做的合併。

b.
branch
能夠設立支線在為自己的工作建立一個額外副本，對副本做編改，如此在能夠保留原先沒做更動的版本，在有需要時可以拋棄支線仍有原版可以使用，完成時可以合併直接增添完整功能。
適用在要做修改新增前不希望將未完成的部份先加入時，可建立branch，完成時可合併，需要時可丟棄。

rebase和merge
都是用於在branch上資料修改完後讓branch合併，但執行過程不同。
merge會將不同branch中的資料整合在一起。
rebase則是將一個branch上的變化在另一branch上重做一遍。

但merge使用不慎會造成版本歷史的混亂，不易判讀。
<-B<-
A<-C<-Dㄡ
歷史紀錄會是包含B。

而rebase會合併branch並在歷史紀錄上消除他，可以使歷史更簡潔。
<-B
A<-C<-B'
會在C上重作B的操作將B支線合併，在歷史紀錄B會消失。

c.
diff
用於比較差異，以參數選擇working folder、index/stage、repository其中兩者之間的修改比較。

show
直接測試，似乎與diff功能相同，不過diff預設是當前working folder與index/stage的比較，而show是commit間的比較，預設是印出最近一次commit跟上次commit的差異。
另外可以用來看指定標籤的資料與相應的commit。

log
查看提交的歷史紀錄。

reflog
只要你透過指令修改了任何參照(ref)的內容，或是變更任何分支的 HEAD 參照內容，就會建立歷史紀錄。
與log紀錄commit版本不同，除去commit的歷史紀錄，reflog也將一些checkout，reset...的動作紀錄下來。
如此一來可以藉由這個指令查看除去版本資訊以外的動作紀錄，以此做復原的動作。

d.
google各項關鍵字。

git flow
（查找git flow會找到一個branch的最佳實踐模型的介紹）
rebase的介紹
diff
relog

會使用到的 git 指令：
git branch建立分支
git checkout切換分支
git merge合併分支
git rebase衍合分支
「於 2017/03/26 答題結束」

[PenguinRun]

「於 2017/03/29 開始答題」

b. branch 這個機制適合用在什麼狀況？merge 要注意什麼？rebase 又是幹嘛的？

https://medium.com/@justinlee_78563/%E9%97%9C%E6%96%BCgit-%E4%BA%8C-69eb5b7065f3

a. 仿 Q2 那張圖，請提供你個人或團隊設計出來的 git 流程圖。並依據 git 流程圖，解釋每個 branch 的用途，以及列出每個環節所對應的指令。
這部分是仿照
http://nvie.com/posts/a-successful-git-branching-model/
所提到的原圖去進行說明，畢竟還沒有真正的實務經驗，所以就嘗試揣摩它來實現這部分。

你預計用來 deploy 的是哪一條 branch？
master

有哪些 branch 是長期一直存在的？
master及develop
因為要是要去追尋過去的某個開發歷程會先去develop中尋找。

哪些 branch 是合併完就刪除的？
release, hotfixes, feature

https://medium.com/@justinlee_78563/%E9%97%9C%E6%96%BCgit-%E4%B8%89-85bf02347a73

c. diff, show, log, reflog 分別用在哪些情境？

https://medium.com/@justinlee_78563/%E9%97%9C%E6%96%BCgit-%E5%9B%9B-a15d93eb23bd

Q: 描述你這次是如何完成任務的。運用了哪些資源？
A: 先了解專有名詞，嘗試用自己的方式解釋之後，在進行實際操作。
運用資源在blog有提及。

「於 2017/03/31 答題結束」

[wildwindjen]

@dustfantasy

1. 養成習慣，站在閱讀/聆聽者的立場，所以，排好版。

2. 延伸討論：你預計用來 deploy 的是哪一條 branch？有哪些 branch 是長期一直存在的？哪些 branch 是合併完就刪除的？另外，列出你的 A-L 的對應指令或動作。(不在原題目，所以直接回覆另外一篇就好)

[dustfantasy]

develop跟master是會長期存在的branch，最後會deploy到網站上的是master的部份。
debug跟feature基本上都是合併完就會刪除。
A-L的動作
*要轉移到該支線使用git checkout [branch name]
A
從master創建develop支線。
git branch develop

BC
為研發的功能創建支線。
git branch [feature B,C]

D
在發現bug時創建debug支線在此branch上修正。
git branch debug

E
為C的工作結束合併至develop。
git checkout develop轉移到develop支線
git merge [feature C]
git branch -d [feature C]

F
為bug修正後合併
git checkout develop轉移到develop支線
git merge debug
git branch -d debug

GH
是為了之前的功能進行完善或單純同名支線研發其他功能而創建的支線最後再次合併。
git branch [feature C]
git checkout develop轉移到develop支線
git merge [feature C]
git branch -d [feature C]

I
為B的功能研發完畢進行合併。
git checkout develop轉移到develop支線
git merge [feature B]
git branch -d [feature B]

J
為在develop上已完成的版本會先轉移到debug做檢查修正，因此再創建debug支線。
git branch debug

KL
為debug檢查完畢所做的合併。
git checkout develop轉移到develop支線
git merge [debug]
git branch -d [debug]
git checkout master轉移到master支線
git merge [debug]
git branch -d [debug]

rebase必須對未公開的物件使用或是要確認當前沒有人正基於目前提交的物件進行工作才能使用。
develop為公開的支線因此這裡舉例都不使用rebase。

[wildwindjen]

@dustfantasy

看起來你的 debug 都是從 development 來

思考一個狀況：
今天發現線上環境有個緊急的 bug，需要進快修復。
可是目前的 development ，已經併入了預計兩天後才要上線的 featureA。

在你設計的流程中，你會怎麼解決？

====
另外，關於

A
從master創建develop支線。
git branch develop

我蠻常用
git checkout -b my_new_branch

等於
git branch my_new_branch
git checkout my_new_branch

[dustfantasy]

依照最佳實踐模型是應該會多一個用來緊急維修的branch沒錯，不過考量到自身目前都只是小型作業的話，個人認為專門劃設一個支線其實並不是必要，發生這種情況大部份用debug支線就能用來處理，如果真的發生在debug支線正在使用時，那再額外建立一個支線即可。

[wildwindjen]

@PenguinRun
很好，本來還想多問當 commit push 出去後，有哪些操作要特別注意的。你的 blog 卻提到了。
不過你還少了點東西，我要你設計出屬於你自己的流程，你目前只有完成上半部，再針對你個人開發的流程，補過來吧。

@dustfantasy
其實也不一定要多一個條 branch，有考慮過 debug 也可從 master 切過來，然後把修改部分同時併到 master 跟 development 即可。我對你 debug 這條分支的理解，比較像是 hotfixes。
可以參考這邊的圖 http://nvie.com/posts/a-successful-git-branching-model/

==
關於 reflog ，我個人是在 merge /rebase 出了意外狀況時，很常用它來還原 merge/rebase 前到的狀態，然後就可以重複試，試到我知道哪邊有問題。

[PenguinRun]

@wildwindjen
若是以ShoppingCart為情境，我還是會有master, develop, feature, release及hotfix。

流程

• 先從開master中開develop的分支，之後要設計功能時（如：會員、商品、訂購等）。
  依序開出這些功能的feature分支。

• 但完成的流程會由會員及商品先完成，之後在插入訂購的功能分支進去。

• 當某一feature完成後就將其merge到develop中，待確定該功能開發完成後將其delete掉。

• 接續由develop的分支開release的分支，來進行整個系統功能的最終確認（不管是bug還是其它問題）。

• 之後再將確定能上線的版本merge回develop及master中。就開出第一版本的系統。

• 當然這邊又可以牽扯到什麼程度的系統才能正式對外開放，這邊我的評估是假設會員先完成好了，就先對
  他進行測試並將其master的版本給予tag（如：0.5）來表示整體完成進度。並給予commit為member
  complete的標記。

• 等到整體系統能運作後再給予tag為1.0的標示，好以對外開放。

上述過程之所以沒有什麼變化還是因為對於git的實際運用經驗，還沒有那麼充足。其次是在揣摩及考量到各種情況後，也是覺得作者所提出的模組是我能想像中的一個比較好的參照。所以還是會選擇在blog上所畫的那張圖，用來作為我目前的開發流程。

當然也不是任何情況都適合使用這種模式來進行，假設有跟合作夥伴一起做一個專案，還是需要跟夥伴進行構通並訂立好要如何來做這個專案的分支方式為主。又或是專案並不是那麼的大型或不需要較為嚴謹的設計過程，就可能也不適用。

整體來說，我還是會選擇仿照該流程來進行個人開發的流程。

[dwatow]

主要就兩支branch: develop、master
task:
新的任務派下來，先在develop開分支，當作進行該任務的專屬分支feature branchs
在任務完成，自己測試通過，合併到develop

test:
新的測試版本確定，就從develop分支切出新分支為release brandhs，當作是一個「準產品版本」
新開發可以繼續在develop進行，不影響目前的「準產品版本」，若測試出bug也可以在這個版本進行修改之後再merge回develop。
測試結束之後，合併到master

客訴:
發現客訴要從master切出hotfixs分支進行debug修改
修改完成合併回master與develop分支即可

若不這麼做，客人取得的版本，就不一定是充份測試的穩定版本，而是充滿開發後的未充份測試內容。
客訴的機會，就大幅提昇。

b. branch 這個機制適合用在什麼狀況？merge 要注意什麼？rebase 又是幹嘛的？
branch適合用在進行，暫時的單獨版本，每個不穩定版本的儲存不會影響別人的工作進行

c. diff, show, log, reflog 分別用在哪些情境？
git diff 可指定任意版本，逐行比較差別
git show 目前stage中的版本做什麼變更(git log+git diff)
git log 看commit的歷史紀錄
git reflog 對commit下指令的歷程

d. 描述你這次是如何完成任務的。運用了哪些資源？
參考資料
https://ihower.tw/blog/archives/5140
https://medium.com/@justinlee_78563/%E9%97%9C%E6%96%BCgit-%E5%9B%9B-a15d93eb23bd

[wildwindjen]

@PenguinRun

嗯，那你就先試用看看，期待又有一篇心得 blog。

[HoHow]

「於 2017/04/13 開始答題」

實務上常常會利用 branch 的機制，來配合個人或團隊的程式開發與部署流程。請設計自己或團隊的開發、部署流程，並查出會使用到的 git 指令。
a. 仿 Q2 那張圖，請提供你個人或團隊設計出來的 git 流程圖。並依據 git 流程圖，解釋每個 branch 的用途，以及列出每個環節所對應的指令。
master：為主要分支
hotfixx：處理緊急bug的分支
release branches：確定發佈的版本
develop：開發的分支
feature branches：把功能拉到這裡來做開發，完成後在合併回develop分支
b. branch 這個機制適合用在什麼狀況？merge 要注意什麼？rebase 又是幹嘛的？
branch：要開發新功能就會開一個新的branch來開發
merge：需要注意是否有衝突，修復衝突須做好註解
rebase：整理全部分支的commit，讓他們變得更乾淨
c. diff, show, log, reflog 分別用在哪些情境？
diff：比對兩個版本內容之間的差異
show：查此版本修改的內容
log：顯示所有log
d. 描述你這次是如何完成任務的。運用了哪些資源？
https://ihower.tw/blog/archives/5140
https://blog.longwin.com.tw/2009/05/git-learn-initial-command-2009/
https://datasift.github.io/gitflow/IntroducingGitFlow.html
「於 2017/04/13 結束答題」

[YenChunchen]

「於 2017/04/14 開始答題」
a. 仿 Q2 那張圖，請提供你個人或團隊設計出來的 git 流程圖。並依據 git 流程圖，解釋每個 branch 的用途，以及列出每個環節所對應的指令。

master：已發佈出去最新版本的主要分支
hotfixes：只用來處理較緊急bug的分支,bug修完後會在merge回master,develop
release branches：準備發佈版本的分支,只用來修(檢查)bug,bug修完後會在merge回master,develop
develop：處於開發階段最新版本的主要分支,開發完的版本發布前會先送至release branches檢查
feature branches：用來開發新功能的分支,功能完成後在merge回develop分支

a:從master創建develop分支,移至該分支(git checkout -b develop)
b:要開發新功能時從develop創建future分支,移至該分支(git checkout -b future名稱)
c:發佈出去的V0.1發現緊急的bug,從master創建hotfixs分支,移至該分支作處理(git checkout -b hotfixes)
d:處理完緊急bug後從hotfixes merge回master(V0.2),develop(git checkout 要切換的branch)>(git merge --no-ff 要合併的branch) * --no-ff commit log才不會混亂
e:future開發完某個新功能後,再merge回develop,確保develop為最新版本(git checkout 要切換的branch)>(git merge --no-ff develop)
f:將目前開發完的版本,移至release branches作檢查(git checkout -b release branches)
g:將確定發佈的版本merge回master,develop(git checkout 要切換的branch)>(git merge --no-ff 要合併的branch)
h:處理bug(git add filename)>(git commit -m 'describe')

b. branch 這個機制適合用在什麼狀況？merge 要注意什麼？rebase 又是幹嘛的？
處理bug或新增功能時不會影響到原來的程式;需注意有沒有衝突,如果有衝突需解決要再多個commit;可以把另一個分支上作的變更在下指令的那個分支作相同的變更,同時增加一個節點
c. diff, show, log, reflog 分別用在哪些情境？
diff:查看兩個版本間的差異
show:查看該版本修改的內容
log:將所有 log 秀出
reflog:查看下過的git指令
d. 描述你這次是如何完成任務的。運用了哪些資源？
先了解git flow的流程再對各別階段作資料收集
https://ihower.tw/blog/archives/5140
https://blog.longwin.com.tw/2009/05/git-learn-initial-command-2009/
https://git-scm.com/book/zh-tw/v1

[godlike0108]

[於2018/1/18 開始答題]

a.

Git Flow 建議的開發流程如下圖：

master 主支用來發佈實際上線的版本，因此一般會在 commit 訊息加上版本號。沒有穩定的新版開發完成前，不會去更動。

develop 分支是開發進行的主要分支，一般更新頻率最高。當有嘗試性的新功能想開發時，也會從 develop 分支分出 feature 分支，等開發成功確定使用再合併回 develop 。

從 develop 到正式上線前，還會經過一個上線前測試的分支 release ，在 release 測試完後會同時推到 develop 和 master 。

最後， hotfix 分支是用來處理緊急的重大臭蟲，因此直接從上線版 master 分出來，處理完後與 master 合併，並與 develop 也合併，避免下次更新時把原臭蟲帶進 master 。

b.

branch 機制

branch 讓我們可以保留原版，並獨立出一條分支做開發與嘗試，不管 branch 發生了什麼慘案，都不會影響到原版的內容，簡單來說就是可拋棄式的試驗場。使用 git branch 可以查看當前所有分支。

git branch <新的分支>

從目前的版本開出一條新的分支。例如上面的開發流程圖，從 master 分支 v0.5 版本要切換到 develop 分支進行開發，必須要先把該分支開出來。

此時可使用 git branch develop 開啟 develop 分支。但這只是開啟該分支而已， <HEAD> 並未跳過去。

git checkout <分支名稱>

可以跳到某個現有的 branch 。 若打 git checkout -b <分支名稱> 可以直接開一個新分支並跳過去。

git merge <分支>

git merge 就是把指定分支合併到 <HEAD> ，也就是我們所在的分支。在 merge 之前，我們要先移動到之後要繼續前進的分支上，再做 merge 的動作。舉例，當 feature 上的東西開發完，要合併回 develop 分支時，要先 git checkout develop ，然後再做 git merge feature 。

merge 要注意「合併衝突」。舉例，從 develop 分支到 feature2 ，並往前進了一個版本。然後 develop 分支同時也前進了一個版本。兩個版本的 index.html 的第五行可能因為修正的關係變得不同，在合併前就要先把衝突的部分手動處理完，再進行合併。

合併過的分支若不需要了，可以用 git branch -d <分支名稱> 砍掉。

git rebase <分支名稱>

git rebase 的功能和 merge 類似，都是把分支合併的動作。差別在於 merge 會產生一個新的 commit 做為合併後的結果。而 rebase 會把目前的整段分支搬到指定的 <分支名稱> 上面。

要如何取消 git rebase 呢？可以用 git reflog 找到紀錄的分歧點，然後用 git reset --hard <節點SHA-1編號> 回去。

c.

git diff

git diff 會比對 working docs 和 staged 的檔案差異。可以用來確認什麼東西改了卻還沒加到暫存區。
git diff --staged 會比對上一個 commit 和目前暫存區的差異。
git diff <commit1> <commit2> 會比較兩個記錄點間檔案的差別。

git show

查看某個 <commit> 的修改內容。

git log

查看所有的 <commit>

git reflog

每次改動 <HEAD> 時，例如 commit ，會在 reflog 之中新增一筆改動的紀錄，若有丟失 commit 或做了一些怪改回不了家，可以把 git reflog 叫出來，用 git reset --hard <commit> 來拯救世界。

透過 為你自己學 Git - Git Flow ，成功完成了這次的任務。

[完成日期: 2018/1/18]

[qscgyujm]

git flow

git flow 是一種多人程式開發的git規則，依照特定規則避免開發錯誤。

1. master分支

主要是用來放穩定、隨時可上線的版本。

2. develop分支

這個分支主要是所有開發的基礎分支，當要新增功能的時候，所有的 Feature 分支都是從這個分支切出去的。

3. hotfix分支

當線上產品發生緊急問題的時候，會從 Master 分支開一個 Hotfix 分支出來進行修復，Hotfix 分支修復完成之後，會合併回 Master 分支，也同時會合併一份到 Develop 分支。

為什麼要合併回 Develop 分支？如果不這麼做，等到時候 Develop 分支完成並且合併回 Master 分支的時候，那個問題就又再次出現了。

那為什麼一開始不從 Develop 分支切出來修？因為 Develop 分支的功能可能尚在開發中，這時候硬是要從這裡切出去修再合併回 Master 分支，只會造成更大的災難。

4. release分支

當認為 Develop 分支夠成熟了，就可以把 Develop 分支合併到 Release 分支，在這邊進行算是上線前的最後測試。

5. feature分支

當要開始新增功能的時候，就是使用 Feature 分支的時候了。Feature 分支都是從 Develop 分支來的，完成之後會再併回 Develop 分支。

B

1. branch這個機制適合用在什麼狀況？

git branch 是建立一個新的分支，分支為原本分支的複製。branch機制用於在不想影響原分支的的情況下使用。

2. merge 要注意什麼？

git merge 分支name 是在目前分支底下合併其他分支，而merge要注意合併，雙方分支不能修改到同一個檔案，會造成錯誤。

merge的方式有可能會建立新的commit物件或不會。

3. rebase 又是幹嘛的？

git rebase是另外一種類似於merge合併的方式，rebase的方式是被合併的分支整段接到合併分支之後，建立新的commit物件。

C

1. diff:

git diff 比對兩個版本(commit物件)之間的差異

2. show:

git show可看到指定標籤的資料與對應的commit。

3. log:

git log 檢視提交的歷史記錄commit物件。

4. reflog:

git reflog 只顯示全部紀錄的commit物件。