過去五年做接案模式的工作，我只會使用非常簡單的Git來版本控制，偶爾才會有同事或夥伴協同合作開發。如今我踏入開發自有產品的環境，必須跟另外兩位前輩工程師合作，此時Git操作就變得更加重要！如何在同一個專案上增修，同一時間不會影響到彼此的任務，做得好就是一門藝術！
Git版本控制有非常多好用的功能，端視專案需求來使用，所以沒有一定的規則！若是同時有多人開發，2010年有個可以當作公版的Git Flow可遵循。現在我參與自有產品開發，大致上就是以上圖的模式來操作。
先來看一下獨自開發時的Git Graph，我使用Source Tree來查看每個版本的差異。可以看出來左邊那條線非常筆直，根本不需要有分支 (Branch)，儘管Git高人都說「Branch可以開很大不用錢！」我卻沒有感受到Branch帶來的好處ＸＤ～
這是垃圾管家當時開發的Git紀錄。
如今加入港商新創公司，專案已開發10個多月，我很快就上手如何開Branch，我們三人一起做Feature修Bug，每個Issue都會開個Branch，接著各司其職將問題給解掉！完成後去Create Merge Request，請在香港的資深同事來合併Branch。
現在Source Tree變得好多采多姿！可以見到每一條不一樣顏色的線，就是一個Branch，最後通通都被合併到Develop Branch。
若還不知道要怎麼開Branch，可以參考2010年公版的方式如圖：
基本上會有這幾個Branch：
- master
- develop
- hotfix
- release
- feature
我們會有Master和Develop兩大分支，其他會是小任務如修bug，最後釋出上架的版本，會是在Release上。
我目前是Command Line和Source Tree一起使用，團隊分配工作給彼此，是在GitLab上開Jira，每個任務會有詳細的說明與進度，夥伴各自去領想要解決的Issue，可能是做Feature或是修Bug。
Source Tree好用之處其實就是視覺化！有顏色明顯標示哪些code有異動，甚至同一個檔案在不同時期增修都能往前回溯，於是可以找出埋「技術債」的罪魁禍首ＸＤ～
參考：Git Flow 是什麼？為什麼需要這種東西？、A successful Git branching model。
逍遙文工作室 
Comments on: "[圖解] Git Flow" (1)
[…] 參考：[圖解] Git Flow […]
讚讚