教學 GIT開發應用原理

[ihstar]

HI! 各位好

今天來談談GIT的主要應用及分支的分工觀念原理。
其實我前前後後接觸過許多公司的GIT理念。從沒理念就用的，到自已理念用的及正規理念用的都碰過了。
而大多數來說，都是因為工程師沒啥使用的觀念。隨便合并。
小專案就比較無所謂，但大專案來說。如果又是跟人分工合作的情況。則GIT FLOW的理念更是重要。

這邊就開始來談談站長我自已重中研究的分支處理。其中當然也有參考過早期就有的一些理念，然後再加以改良處理

先來談談主要的分支有 master、develop、hotfix、release 以及 feature。其各自有不同的對應項目。依其情況而各自對應
其中長期分支為 master、develop。這兩支分支不會被消失。再來二種中期性分支為 release 。為何我會說中期性分支?
因為如果是多個功能同時再開發的情況下。這個分支是不該被消失的。這等等下面的項目會說明其原因

• master：主要分支之一，其實也是主要發布的版本。板本號一般只會存在這個分支上。
  • 這個分支不會有任何 Commit 一律從 release 合并過來。
  • 這個分支也是主要發布主機的分支之一。一般來說算是穩定的版本。
• develop：主要分支之一，也是開發團隊主要測試用的分支。基本上它合并來源都是來自 hotfix 及 feature。
  • 這個分支也不該有任何 Commit 。
  • 這個分支有機會，會是 hotfix 或 feature 新分支的來源。
  • 該分支可以合并到 release 這個分支上。
• release：算是次要分支，認真來說，它是要上線前的最後一個關卡。視專案情況可有可無。
  • 這個分支也是不該有任何的 Commit
  • 主要依據來自 develop 。但也可合并 hotfix (視情況而定)
  • 它會是正式上版前一個重要的分支。做為最後的測試。如沒問題就可以合并到 master 上。
  • 如發現到問題。則需從這個分支另開一個 hotfix 分支做為修正。修正完再合并回來，但要記得 develop 也需要同步合并。
  • 不會再這個分支開 feature 這個分支
  • 當不存在任何 hotfix 及 feature 分支時，該分支可以在合并到 master 後就將其消失刪除。
• feature：原則上這是新功能開發分支。但有些能也會將「優化」也視為這個分支名。
  • 要開此分支，原則上我會建議從 master 來開新分支。不過坊間的教學則是建議從 develop 開分支。
  • 但因為我曾經的開發過程中。 develop 會有可能開發一半的功能存在。因為客戶有時急著要看。所以我在後期都是請工程師。從 master 開新分支
  • 大多數而言，大項的變動。優化確實要直接開此分支來處理。
  • 這個分支可以共同合作作業。
  • 當完成後，需要合并到 develop 分支上。則該分支刪除消失。
  • 如果開發一半需要先合并 develop 查看。則該分支不需要刪除。
  • 開此分支的應對，最好是依大方向的功能性為主。如「用戶功能」「文章功能」。再使用 Commit 來對應完成的項目。
• hotfix：這個分支理論上是存活期最短的分支。因為它大部份是為了處理BUG或少部份優化為主。
  • 這個分支，一般只會從 master、release。中來開新分支。看是在哪個環節中發現到的。
  • 但該分支完成後，一律也要跟 develop 同步合并。
  • 在優化項目中，在我多年來的開發經驗。有時很難在 hotfix 及 feature 來取捨。
  • 所以我後來是採用如優化修改的東西不多。如可能只是修改一段SQL的語法。就將其視為 hotfix。
  • 但如果是多項修正。如得要調整 SERVICE、ORM等多項調整的情況下。我才會將其視為 feature。
  • 但在關於優化的部份，在GIT的使用歷程上，大多還是建議用 feature 居多。盡量保留 hotfix 來做為處理BUG。
  • 但因為有些優化的原因，就是會產生不必要的BUG問題。所以.........

以上是主要分支的說明。
再來就是命名的方式。
基本上來說 master、develop及release 不會有額外命名的情況。
但 hotfix、feature則是有機會有特定命名的情況

一般來說，基本的命名方式是直接的
例
hotfix/修正XXX的問題
feature/用戶功能開發

但我在目前的團隊中，我還有要求 hotfix 最好再多一下是從哪個分支分離出來的
例
hotfix/master/修正XXX的問題
hotfix/release/修正XXX的問題