用於網站的簡單 Git 分支 model

Question

有人可以建議一個簡單的 git 分支模式用於網站開發。 我見過幾次關於成功的 git 分支模型的討論，不幸的是它們對於我們的案例來說都非常復雜。 大多數分支模型適用於具有版本和發布周期的軟件。

我們公司管理着幾個 web 門戶網站。 我們有 5 個人在這些網站上工作。 大多數時候，2-3 個人可能在同一個網站上工作，但在不同的部分（沖突的可能性幾乎為零）。 我們沒有任何版本或發布周期。 程序員將開發一個特定的部分，然后將其傳遞給另一個人，后者將為該部分編寫內容並執行 SEO。 完成后，該部分將上傳到公共網站。 與此同時，另一位程序員可能正在更新現有部分。 如果報告了錯誤或錯誤，將立即修復並上傳。

通常，每周添加/更新 2-3 個新部分。

目前我們只有一個分支（master），並且只有當這個人正在處理需要超過 2 周才能完成的重大更改時才創建一個新分支。 這里的問題是主分支與當前的生產文件不同步。 我想改變這一點並將開發轉移到另一個分支，以便可以直接在主分支上應用錯誤修復而無需擔心。

更新為每個部分創建一個單獨的分支是不是很糟糕？ 換句話說，有多少分支被認為是太多了？

Answer 1

在我看來，您真正需要的是完善您的工作 model 和流程。 Git 不是工藝問題的解決方案，它只是一個應該支持您選擇的工藝的工具。

即使您聲稱您沒有發布周期，您仍然有發布：至少生產中的運行副本應該被視為發布/版本。 如果從 QA/測試的角度來看是可以接受的，沒有什么能阻止你每周發布 10 個版本。

思考的幾點：

• 生產站點必須始終在分支中具有 1:1 克隆（無論是主站點、發布站點還是其他站點）
• 在生產站點中運行的“發布”應始終在版本控制中具有標記以進行跟蹤。

對於它的價值，我認為您描述了這樣的 model： http://nvie.com/posts/a-successful-git-branching-model/ 。

Answer 2

你有一個相當連續的開發周期，所以你是對的：那里不需要大量的功能分支。

一個簡單的 model：

*--*--*--*---*   (master, for prod)
    \       /
     *--*--*--* (dev, for current development)

問題是：

當產品（' master '，實時網站）中存在錯誤時，您可以在dev分支上修復它並包含正在進行的任何開發嗎？

因為如果你不能，那意味着你對master所做的更改必須立即合並回dev 。 如果該修復很快完成，您甚至不需要“ fix ”分支。

換句話說，您不需要“一個成功的 Git 分支 model ”的所有復雜的 model。

Answer 3

您說您只為超過兩周的更改創建分支，但從技術上講，每個開發人員的本地副本都是一個單獨的分支，尤其是對於像 git 這樣的 DVCS。 我猜您的官方主分支與生產中的不匹配，因為您正在使用該分支在程序員和內容創建者之間共享更改。 在您遇到如此短的發布周期的情況下，我會做的是讓這兩個合作者彼此共享他們的本地存儲庫，完全跳過中央存儲庫，直到它經過測試並准備好投入生產。 這樣你就可以自動擁有盡可能多的開發分支，並且你的官方中央存儲庫保持干凈。

如果這對您的團隊來說太過分了，您始終可以創建一個僅直接接收錯誤修復的production分支，並在主分支處於穩定點時合並到主分支以推入生產。 這樣，您的開發人員仍然按照他們習慣的方式在中央主分支之外工作。

Answer 4

如果復雜性對您來說是個問題，那么看看 Mercurial 作為 GIT 的替代品。

GIT and Mercurial use an equivalent distributed VCS model, however Mercurial tends to be easier to use and does not expose as much of the underlying complexity to the user.

看看這個問題的答案Mercurial 和 Git 有什么區別？