對於小開發團隊

Question

的Git分支策略我們有我們幾乎每天更新和發佈一個Web應用程序。我們使用git作爲我們的VCS，而我們目前的分支策略非常簡單和破壞：我們有一個主分支，並且檢查我們對它感覺良好的更改。這個工作，但只有在我們檢查一個突破性的變化。

沒有人有小團隊符合以下要求的最喜歡的Git分支策略：

1. 非常適用的2隊3開發商
2. 重量輕，並沒有過多的工藝
3. 允許開發者隔離的bug修復和更大功能的工作輕鬆
4. 使我們能夠保持一個穩定的分支（對於那些「哦，廢話」的時刻，當我們必須讓我們的生產服務器的工作）

理想情況下，我很樂意看到你一步一步的過程，一個開發一個新的bug

Answer 1

你可能會受益於工作流程斯科特·查孔介紹Pro Git。在這個工作流程，你有兩個分支始終存在，主和發展。

主人代表您的項目的最穩定的版本，你只能從這個分支部署到生產。

develop包含正在進行的更改，可能不一定準備好生產。

從開發分支，您可以創建主題分支以處理單個功能和修復。一旦你的功能/修復已經準備就緒，你將它併入發展，此時您可以測試它如何與你的同事在已經合併其他特性分支進行交互。一旦發展處於穩定狀態，將其合併進入主人。從master部署到生產應始終安全。

斯科特介紹了這些長期分支爲代碼「孤島」，其中，在不太穩定的分支代碼最終將「畢業」，以一個考慮了你的團隊測試和一般的批准後更加穩定。

一步一步來，在這個模式下你的工作流程可能是這樣的：

1. 你需要修復的bug。
2. 創建一個名爲的分支myfix即基於開發分支。
3. 在這個話題分支的bug工作，直到它被固定。
4. 合併myfix進入開發。運行測試。
5. 你發現你的修復與另一個主題分支衝突hisfix你的同事合併到開發當你正在處理你的修復。
6. 在myfix分支中進行更多更改以處理這些衝突。
7. 合併myfix進入開發並再次運行測試。
8. 一切工作正常。合併發展到主。
9. 任何時候從掌握部署到生產，因爲您知道它是穩定的。

有關此工作流程的更多詳細信息，請參閱Pro Git中的Branching Workflows一章。

Answer 2

工作在VCS，只具有「主」分支快速地顯示它的極限，因爲你無法在一個分支上同時追求所有的開發工作。
這意味着你需要知道when to branch。

但在DVCS（如「分散式」 VCS），你也有一個publication issue，用樹枝您保持您的本地存儲庫，和樹枝你是推或拉離。

在這種情況下，通過識別您的並行開發工作啓動，並決定發佈（推/拉）過程。例如（這不是唯一的方式）：

• prod是一個只讀的公共分支與生產中的代碼。每個人都可以從中拉以：
  • 重訂其目前的發展在它的上面（用於本地測試，或在本地開發整合回購在督促回購做了督促分行修補程序）
  • 分支做新的功能（從一個已知的穩定代碼）
  • 分支開始下一釋放分公司（其中一個是要在生產）
    沒有人應直接推到督促（因此只讀）
• 釋放是一個讀寫整合分支，其中relev螞蟻承諾被挑選出來，成爲下一個版本的一部分。
  每個人都可以推送發佈來更新下一個版本。
  爲了更新他/她的本地合併過程，每個人都可以從發佈版本中獲取。
• featureX是一個私人讀寫分支（因爲它不需要推到中央prod回購），並且可以在dev回購之間推/拉。它代表中間的長期努力，從日常開發
• 主代表當前開發不同，推/ dev的回購之間拉出。

存在其他版本管理流程，如SO question attests。

Answer 3

通過ReinH的Git的工作流程閱讀敏捷團隊在這裏：http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

這非常適用於小型團隊。這裏的目標是確保所有可能不穩定的東西進入某種分支。當您準備好在功能部門之外工作的每個人使用它時，只需合併回主設備。

注意：這個策略幾乎沒有git特定，但git使得實現這個策略非常簡單。

Answer 4

在作爲新手嘗試找到一個直接的策略來教給其他從未使用過源代碼管理的開發者之後，這是適合http://nvie.com/posts/a-successful-git-branching-model/我嘗試使用標準的GIT工作流程，這在手冊頁，但它完全混淆了我和我的觀衆。

在過去6個月中，我只需要修復衝突兩次。 我已經添加了一些步驟，以便在開發功能的同時經常在合併之後進行測試，並且在很多時間（早上和下午一次）進行「獲取和合並」或「拉 - 重新啓動」。我們還使用github.com作爲拉取最新代碼的中心位置。

Answer 5

使用master分支作爲您的開發分支，並創建用於執行錯誤修復的發佈分支。

在開發窗口期間（直接提交或作爲具有拉取請求的主題分支，由您決定 - 圖中未顯示），任何新功能都將繼續使用master。完成所有計劃功能後，輸入功能凍結並執行測試。當你快樂時，將master上的發佈標記爲v1.0。

隨着時間的推移你的用戶會發現，在v1.0錯誤，所以你需要創建從標籤的分支（如發佈1.0它命名的），並固定在分支的錯誤。當您修復了足夠多的錯誤並認爲它需要新版本時，請將其標記爲v1.0.1並將其合併回master。

同時在master分支上可能會發生新的開發窗口，該分支最終會被標記爲v1.1。

沖洗&重複。

這遵循Semantic Versioning編號邏輯。

---------(v1.0)--------------------------------(v1.1)-----------------------------> master 
      \          \ 
       ---(v1.0.1)---(v1.0.2)---> 1.0  ---(v1.1.1)---(v1.1.2)---> 1.1 

Answer 6

（使我comment上面它自己的答案，因爲我應該開始。）

從GitHub的斯科特·查孔：

我們如何做那麼，什麼是GitHub的流量？

• 凡是在主分支部署
• 上進行一些新的工作，創建一個描述性命名的分支關閉主（即： 新的oauth2-範圍）
• 提交該分支機構本地，並定期把你的工作，以同樣的命名分支的服務器上
• 當你需要反饋意見或幫助，或者您認爲分支準備合併，打開一個 拉動請求
• 人後其他已審查並在 特徵簽了字，你可以把它合併到主
• 一旦合併，並推到「主人」，你可以而且應該立即部署

看到整個文章更多詳細信息：http://scottchacon.com/2011/08/31/github-flow.html

需要注意的是「拉請求」是Github的發明，它的東西是烤到自己的網站，而不是Git的本身：https://help.github.com/articles/using-pull-requests/