Git怎麼這麼難用？Git Flow + 好習慣 = 不再苦惱
自從Linux發明人Linus Torvalds對於時下版本控制工具感到不滿，決定自己動手做，發明了git以來，git已經慢慢地蠶食鯨吞了版本控制市場。不管你存放的repository是GitHub還是GitLab，不管你使用的工具是SourceTree還是GitKraken，或是你喜歡自己刻git指令，這都無妨，因為你都已經慢慢地離不開git在工作中帶來的便利性與快速性。
然而，慢慢有些朋友會發現，隨著專案越來越大，協作人員越來越多，怎麼git的使用越來越困難，一下子merge過去漏了兩個檔案，一下子merge完原本刪掉的檔案又出現了，不然就是每次merge就要解七八十個衝突，這樣看來git好像沒有想像中好用嘛。你是不是強烈懷疑git的能力，心想著：
『這git根本就撐不起我們這麼大的專案，還是原本的______好用，老闆也真是的，沒事換這幹啥，找麻煩耶。』
有很多人來問過我，為什麼git這麼難用，公司還要強迫我們用？我多半笑而不答，但我的心裡總是想到大聯盟的這一幕。我們看看這個影片先：
聰明如你，這應該有替我回答解決你的問題了吧？贅話就不多說了。
幸好，這個世上只要有新的好工具，就會有一群懶惰的工程師開始想方設法地讓自己的生活好過一點。 Vincent Driessen就是這種人，於是他依照個人經驗，將工作中經常會遇到的場景逐一整理，依照git的特性，發明了一套工作法則，也就是本文的主角：gitflow。
上圖大家應該不陌生吧？你心裡一定想說：『這張圖我看到都會背了，問題每次merge就還是很痛苦啊！』
戲法人人會變，各有巧妙不同。這樣吧，我們省去介紹制式化理論與分類的時間，直接從工作中一個平凡無奇的早晨開始，如何？大家跟著敘述場景，來一起看看gitflow到底怎麼幫助我們梳理工作流程，節省時間。
假設，你們已經有了master與develop兩大常在型branch，其他branch都已經不見了。為什麼要有這麼強的假設？後面會再詳述，而事實上，本文結束後你會發現，這樣的假設一點也不強，以一個健康的git工作流程來說，這樣的情況根本就是習以為常。
那我們就如上所述，從一個平凡無奇的早晨開始吧。
早上你泡好咖啡，從你的座位上坐下，決定好今天要為這個專案加上一個發email的新功能，於是這個時候你要做的事是『加新功能』。既然如此，你就應該創一個新的feature branch，並將其命名為『add_email_feature』。
左圖中的粉紅圈圈所在的支線就是你新創的branch。依照gitflow的規定，他會被加上一個feature的目錄名：feature/add_email_feature，不為什麼，只是為了方便辨識與管理而已。
接下來你就開始開發，開發與自動測試過程花了三天，結束後你就要結束這個branch，於是你merge回develop，一切又如一開始那樣祥和，世上只剩develop和master兩大branch。
當然，世事不可能永遠如我們想的那麼美好，專案越來越大，就會有越來越多功能在同步開發，這時候怎麼辦？就同步啊不然怎麼辦。
左圖這樣同時有好幾個feature同時在開發的場景多了去了。但是gitflow告訴我們不用擔心，儘管開發自己的功能便是，但是你一定要注意一點，開發測試完自己的功能就一定要趕快merge回主線，並且結束這個branch。
記住，無論何時，都要讓流浪在外的feature branch越少越好，branch生命週期越短越好。這件事情對幫助develop的穩定度有莫大的好處。
你可能已經開始覺得我在虎爛了。這麼頻繁地更動主線，怎麼可能保持主線穩定？
首先，我們要問自己一件事，在功能做完馬上就發現問題，進測後才發現問題，還是上線前一天發現問題比較好？這個問題我想稍微有理智的人都會選擇第一個選項。那麼，既然大家都同意功能做完馬上就發現問題比較好，那麼為什麼會想要開一個branch出去，功能明明都做完了，卻遲遲不敢結束，是在怕什麼呢？
你一定也遇過一種情形，功能還沒要上線，你不敢放到主線，於是只好放在feature branch上癡癡的等老闆點頭上線，你才敢merge。這種事很常見，但這不是允許一個長壽branch存在的理由。身為一個好的RD，你應該要有能力設下安全的toggle，並且同時能附上足夠完整的auto test讓你有信心這個toggle不容易被誤啟，更有信心QA有能力驗證這個toggle的開關，同時QA驗過的版本就肯定是拿去上線的版本才對。
如果上面的這些保證與信心都無法在你的工作上建立，那你們的專案危險程度是很顯見的。而且我可以確定你們工作上的困難絕對不是主要來自於git。你應該先想辦法解決那些造成危險的因素才對。
所以，請記住：feature branch的長度不應過長。如果上述的因素你都能夠排除，feature branch還是很長壽，那麼只剩一個原因了：feature內容開過大。請回頭找你的PO商量，試著再多拆分成幾個獨立的小feature。DevOps界盛傳一句話：
避免犯錯的最好方法，就是經常犯錯。
這麼說是有其根據的。人腦不是萬能，一次處理越多事情，犯錯機率就會越高；處理被擱置越久以的事，也會提高犯錯率。把龐大而複雜的需求拆分成數個小而盡量獨立的feature，不容易，這完完全全就是在考驗PO的功力了。
好不容易熬到要上線了，這個時候我們要做的第一件事，就是要來決定版號。怎麼決定版號並不在本文要討論的範圍內，總之他就是被決定了。接著就是要來開release branch了。
左圖中綠色的點，描述的正是release branch極短的一生。開啟release branch之後，就開始進入生產前的總驗測。
也有人只把release branch當成是進入master前的緩衝，讓總驗測針對master進行，一旦發生問題就視同正式環境問題處理，也就是開hotfix。
這兩種方法都有人用，各有優缺點。我覺得都不錯，但是有一件事一定要嚴格遵守：
一旦release開出來，就只能修bug，不能開新功能。
一旦release開出來，就只能修bug，不能開新功能。
一旦release開出來，就只能修bug，不能開新功能。
因為太重要了所以要講三次。在實務上，總是有人喜歡偷渡一些新功能在bugfix裡面，但是要知道，此時大多已經沒有執行從頭驗測到尾的回歸測試了。這說穿了是對公司即將上市的產品，偷偷埋入未經詳實驗證的新功能，雖然很帥，但卻是非常危險的行為。
當然，也許你天生神力，那我就只能羨慕你的神力，並祝福你。
以我們這些凡夫俗子來說，這件事要絕對避免，因為危險性太高了，我們沒有天生神力，就盡量減少危險的流程吧。
俗話說得好，吃燒餅哪有不掉芝麻，寫程式哪有不出bug？一旦產品在正式環境出了問題，唯一一條路就是解掉他了。這個時候hotfix就該出場了。
上圖的紅點就是hotfix，它從master開出來，結束時回到master，順便修復develop，跟release branch很像，對不？
事實上不只流程像，大部分情形下，我們對待hotfix就要像release一樣：
- 開了branch的同時就要決定版號
- 只准修bug，不准偷渡新功能
理由很簡單，因為hotfix和release與進入正式環境運轉的距離是一樣遠的，當然對待他們的謹慎度要一樣高才對。而hotfix因為通常事出緊急，又更難進行全盤的手動回歸驗證了（如果有自動回歸驗證就一定也要通過，但是這也不能完全保證無誤）。因此，為了避免更大損失，一定要謹慎再三才行。
驗測完畢，hotfix結束，產品上線，順便修復develop，世界又回到最原始的單純狀態，只剩下develop和master了。
以上，我們從案例出發，介紹了gitflow中各種不同branch的開啟與結束場景。基本上軟體開發的場景大概都不出這幾種。『誰說的？我跟你說我遇到的場景超複雜的，像這樣這樣這樣…』
先別急著敘述，先聽我一勸：
我經常認為，越是龐大的產品，越是要有簡單的架構；越是複雜的工作，越是要用簡單的方法處理。有了gitflow，你可以有一套簡單的標準去套用工作上的場景。因為這套工作流程比較簡單，所以你並不應該等到事情變得複雜才來解決。請容我換個方式再講一次：
gitflow的目的是要用簡單的流程解決工作上的問題，所以不要把問題放到很複雜了才想要來解決。
最後我為各位整理一些文中提到的原則，實務上，我有很多朋友來問過我的問題，其實早一些時候都可以靠遵守這些原則來解決，而不需要拖到重症了才來傷腦筋：
- feature branch不要太長壽，最多最多，不要超過一個sprint
- 萬一內容太多，就回頭跟PO商量，這個需求太大了，必須修剪
- 品質好的自動測試可以消除你對頻繁回主線的疑慮
- 進版前一定要開release，預產線的測試版本一定要是上線的同一個版本
- 承上，改一行註解也不行！
- hotfix跟release開啟的同時就要決定版號，這能幫你確認版本
- 經常存在的branch只有兩個：develop與master
以上這些要點如果都能掌握了，各位工作上應該就很難創造很複雜的問題了，那麼此時，gitflow對各位工作上便利性的幫助就比較容易看得出來了。祝各位長官工作上一帆風順！
最後附上Youtube裡找到的gitflow教學影片，如有認為本文有所不足者，這裡有完整詳解，敬請安心服用。
