Git分支模型

Question

所以我經常使用的分支模型類似於以下內容：

http://nvie.com/posts/a-successful-git-branching-model/

但是，我目前正在為每個新版本創建一個新分支。 例如，他們正在合並1.0的主人，此時主人員已經死了。 當他們需要開始1.1開發時，他們將合並1.0中的1.1。 當它們在1.0上完成時，它們會將它部署到生產中，並且該分支將基本上已經死亡。 您可以正常執行並合並主要功能的發布分支，並在完成后合並回其中。

我能想到的唯一一件事就是這個非常有用，如果你出於某種原因在前一個版本之外的其他東西上做了一個修補程序。 因為該分支始終存在，您可以返回它並進行更改並提交修補程序。 （或創建一個分支並將其合並回來）。 他們正在標記發布等...

這似乎與git的設計方式非常不直觀，因為你沒有真正的主分支。你的主分支是你從前一個分支合並的最后一個版本。 我認為這對於多行開發可能會更好。如果您正在同時處理3個版本。 以這種方式使用git會有什么問題嗎？

Answer 1

讓你的發行版分支懸空，並將它們合並回主版並標記你的發行版之間在功能上沒有區別。 分支和標記都只是指向單個提交的指針。 將master分支中的各種提交標記為特定版本的好處是，您沒有一堆分支混亂git branch的輸出，而是您可以清楚地請求帶有git tag的分支列表。

我懷疑你的同事們認為分支是真實的東西 ，當它們基本上只是一種特定的標簽時（或者更確切地說，標簽和分支都只是參考）。

我能想到的唯一一件事就是這個非常有用，如果你出於某種原因在前一個版本之外的其他東西上做了一個修補程序。

您可以輕松簽出標簽並執行修復。

以這種方式使用git會有什么問題嗎？

不是真的，當你有一個由git branch顯示的一百個分支時變得非常困惑。 無論你如何管理你的分支機構，Git都可以工作。

Answer 2

我假設你有類似的東西：

master
      `->1.0----(release)
          |       |
           `-----.-->1.1----(release)
                       |      |
                        `---->1.2(release)
                               |
                                `--->2.0

從技術上講，它確實沒問題。 實際上，最新編號的分支是您的主人。 但是，它確實打破了約定，它指定master通常是真實代碼所在的位置。 因此，您可能需要向您打電話的顧問或您外包的任何公司做一些解釋。

只要您的分支以某種方式很好地合並到最新的分支，您就會很好。 如果沒有，如果有人刪除了一個懸掛提交的分支，那么當git進行垃圾收集時，你就失去了這項工作。