在世界廣為流傳的Git與不認識他的另一個世界

筆者以前在電子廠小待過幾年，在到電子廠之前，接觸的都是subverion，當時只要多人開發，就會覺得相互鎖定來鎖定去的很煩人，但畢竟是第一套接觸的版控系統，當時就覺得有一個好用的版控系統才是共同開發的王道。

到了電子廠後，當時的團隊比較大，大概15個左右，那時候初次接觸到Git，一開始覺得非常難理解，因為當時的分支管理沒有做得很好，如果印象沒錯，是用來做Function的管理，同Function的人共同在一個Branch上維護，然後定期merge回master。後面則有Jenkins去承接，每天清晨打包出大家每天合併進去的程式碼，交付給Q單位進行測試。

那因為Git可以做到多人共同開發與簽入，這在以前subversion年代是不太可能做到這麼快的，當時就覺得這真是一個偉大的發明，一定會成為未來主流。

約莫十年前左右來筆者到金融業後，大家都沒有聽過Git的時候我其實非常驚訝，我當時想一定是有場景的不適用，所以並沒有在金融業被廣泛運用。就如同我第一天所說的，其實在金融業最在意的事情是，簽入或是過版流程是否有檢核點。只有Git是沒有辦法做簽核的，一定要去組合一堆open source project的工具來完善這件事情。

以前在電子廠的時候，source code要簽入前，我印象很深會要去Gerrit 共同review 要merge的code 是否有問題。幾年前就有思考過，再加入一些其他的open source project，是不是可以導入到金融業中，讓大家對審核這件事情可以更專注在程式碼與需求之間。

沒兩下我就放棄了。

因為在這裡，一切要安裝的軟體，我們都要一堆證明，例如安全性、合規授權，然後還要負責定期修補。當然這一切都很重要，沒有人否認，但如果我要把整個解決方案進行流程的設計、技術關節的打通、組織內大量溝通，還要去處理那些核心事務外的一堆事情，很快的熱情就會被消磨掉了。

一直到這一兩個年頭，內部因為一些原因，加上一些外部完整解決方案平台的產生，讓我有機會來設計整個解決方案，所以才有這系列文章的出現。一方面是將一些設計思考的方向用文字或圖片留下紀錄，一方面也是一個反過來重新檢視自己想法的好機會。

Repo and Branch Model

Git大家都會用，大家應該都是高手，我反而沒甚麼把握好好的下Git指令，所以這邊沒有我獻醜的地方，因此我還是要從任務導向這邊說起。前面說到了，這裡最注重的就是檢核點。

我在設計檢核的時候，其實思考了非常久，因為過了半年，所以記憶有些模糊是從哪裡做為起點思考的，那時候不斷在尋找別人的最佳實踐，我印象或許是從git branch best practices 這幾個關鍵字中，找了一大堆的git圖進而去延伸設計的，最後應該是找到有人在設計gitflow 的一張圖出發。

圖片來源：https://nvie.com/posts/a-successful-git-branching-model/

他的概念是，所有的程式開發，最終都會回到master(現在都叫main了）。當時的我想，這好像可以映射到我們放入公司內的版本控管系統。因為我們公司最注重的是過版佈署的版本，就是當下的最終版。進而延伸出，那這是不是代表，master就是我們現在營運環境的版本？所以我是可以使用這個master branch作為抽象的映射嘍？

既然master可以做為營運環境的版本映射，那測試環境是不是也可以用branch來做為映射？

這裡要介紹一下，我們公司目前內部將營運環境與測試環境的網路隔離，然後是以VM Ware 或走實體機架伺服器，都是使用作業系統為主。因此，我的佈署任務，就是要面向營運環境以及測試環境，並且是傳統的作業系統(非微服務）。

基礎的版本控管與現實世界的架構出來了以後，我就逐漸從這個方向去探索，那我要怎樣進行審核的動作。因為如果只是git的指令，是沒有辦法進行審核的動作的。

GitHub flow

https://nvie.com/posts/a-successful-git-branching-model/
If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

前面有講到我從網路上找了許多的最佳實踐，參考了上面這一篇文章作為起點然後開始進行設計。該篇文章提到了GitHub flow，所以我就又從這篇文章流竄到另外一個地方 GitHub去看看別人的最佳實踐。

GitHub flow 的幾個最重要的步驟我簡列如下：

• Create a branch：建立一個branch，簡單的名稱來敘述一下，例如叫做increse-test-timeout來表示你這個branch要解決的問題。
• Make changes：開始寫你的程式，去完成你想做的事情。
• Create a pull request：產生PR，把他想成你想改的程式已經改完了，你要把你寫好的程式申請合併回去專案中。
• Address review comments：針對PR申請的時候，審查員對於你程式碼的意見提出說明。
• Merge your pull request：將你寫好的程式碼在審核過後，合併進去。
• Delete your branch：將你功能性建立的Branch刪除，預防別人誤用，而且也可以簡化整個Repo。

上述整個流程看完後，看起來就是一個可行的審核方式。所以後續的設計就秉持著GitHub flow的方式進行設計。

版本控管與審核，終於要跟真實世界做一個連結了。