什麼Git分支模型適合你？

Question

我們公司目前正在使用一個簡單的中繼/發佈/修補程序分支模型，並希望建議哪些分支模型最適合您的公司或開發過程。

1. 工作流/分支模型

   下面是這個我已經看到了三個主要的描述，但它們部分相互矛盾或不遠遠不夠理清後續問題，我們已經遇到（如下所述）。因此，我們的團隊迄今默認不是很好的解決方案。你在做更好的事情嗎？

   • gitworkflows(7) Manual Page
   • (nvie) A successful Git branching model
   • (reinh) A Git Workflow for Agile Teams

2. 合併VS墊底（糾結VS連續歷史）

   如若一個pull --rebase或合併回主線，直到等待你任務完成？我個人傾向於合併，因爲這保留了一個任務開始和結束的基礎的視覺插圖，我甚至更喜歡merge --no-ff這個目的。但是它也有其他的缺點。還有很多沒有意識到合併的有用特性 - 它不是commutative（將主題分支合併到主並不意味着將主合併到主題分支中）。

3. 我要尋找一個自然的工作流程

   有時錯誤發生，因爲我們的程序並不捕獲與簡單的規則具體情況。例如，早期版本所需的修補程序當然應該基於下游，以便可以將上游合併到所有必需的分支中（這些術語的用法是否足夠清楚？）。然而，在開發人員意識到它應該放在更下游之前，修正會讓它進入主服務器，並且如果這已經被推動（甚至更糟糕，合併或基於它的東西），那麼剩下的選項是櫻桃採摘，其相關的風險。你使用了哪些簡單的規則？ 此外，在這包括一個主題分支的尷尬必然排除其他主題分支（假設它們從共同基線分支）。開發商不希望完成一個功能啓動另一個感覺像他們剛剛寫的代碼是不存在了

4. 如何避免創建合併（因摘櫻桃）的衝突？

   什麼似乎是一個確定的方式來創建合併衝突是櫻桃選擇分支之間，他們不能再合併？在任何一個分支中應用相同的提交還原（如何做到這一點？）可能會解決這種情況？這是我不敢推動大部分基於合併的工作流的原因之一。

5. 如何分解成局部分支？

   我們意識到，從主題分支組裝完成的集成將是非常棒的，但是我們的開發人員經常工作並沒有明確定義（有時就像「扯開」一樣簡單），並且如果某些代碼已經進入「misc」這個話題，根據上面的問題，它不能再被帶出去嗎？你如何處理定義/批准/畢業/發佈你的主題分支？

6. 適當的程序，如代碼審查和畢業當然是可愛的。

   但是，我們根本無法將事情解決得足以解決這個問題 - 任何建議？ 集成分支機構，插圖？

下面是相關問題的列表：（！感謝this PDF）

• What are some good strategies to allow deployed applications to be hotfixable?
• Workflow description for Git usage for in-house development
• Git workflow for corporate Linux kernel development
• How do you maintain development code and production code?
• git releases management
• Git Cherry-pick vs Merge Workflow
• How to cherry-pick multiple commits
• How do you merge selective files with git-merge?
• How to cherry pick a range of commits and merge into another branch
• ReinH Git Workflow
• git workflow for making modifications you’ll never push back to origin
• Cherry-pick a merge
• Proper Git workflow for combined OS and Private code?
• Maintaining Project with Git
• Why cant Git merge file changes with a modified parent/master.
• Git branching/rebasing good practices
• When will "git pull --rebase" get me in to trouble?
• How are DVCS used in large teams?

還檢查了什麼塑料SCM上task driven development寫道，如果塑料是不是你的選擇，學習nvie's branching model和他supporting scripts。

Answer 1

最令人不安的特點的新開發者DVCS需要認識到的是關於publication process：

• 你可以導入（讀取/拉）你需要
• 你可以發佈（推送）任何任何遠程回購（裸）回購你想

從這一點，你可以尊重一些原則，讓你更輕鬆的問題：

• 只有變基的一個分支，如果它沒有被按下（自上次rebase未按下）
• 只推到裸露的回購協議（強制性的，因爲Git1.7）
• 遵循Linus's advices on rebase and merges

現在：

工作流/分支型號：

每個工作流程是那裏support a release management process，這是專爲每個項目。
我可以添加到你提到的工作流程中：每個開發人員不應該創建一個功能分支，而只需要一個「當前開發人員」分支，因爲事實是：開發人員通常不知道他/她的分支會產生什麼：一個特徵，幾個特徵（因爲它最終變得太複雜了），沒有（因爲未準備好及時發佈），另一個特徵（因爲原始的特徵「變形」），...

只有一個特徵「集成商」應該在「中央」回購協議上建立官方特色分支，然後由開發人員提取這些官方分支以重新整合他們適合該功能的部分工作。

合併VS墊底（糾結VS連續史）：

我喜歡我的回答你提到（ 「Workflow description for git usage for in-house development」）

我要尋找一個自然的工作流程：

爲修復程序，它可以幫助將每個修補程序與來自錯誤跟蹤的故障單關聯起來，這有助於開發人員記住在哪裏（即在哪個分支上，即專門的「修復」分支）他/她應該進行此類修改。
然後鉤子可以幫助保護中央倉庫免受未經驗證的錯誤修復或從不應該推送的分支推送。 （這裏沒有具體的解決方案，所有這些都需要根據您的環境進行調整）

如何避免創建合併衝突（由於櫻桃選擇）？

如Jakub Narębski在his answer中所述，櫻桃採摘應該保留在需要它的罕見情況下。
如果你的設置涉及很多櫻桃採摘（即「這不是罕見的」），那麼有些東西是關閉的。

會在回覆中應用相同的提交（如何執行此操作？）

git revert應該注意的是，但效果不理想。

如何分解成局部分支？

只要是尚未推隨處可見，開發商應該重組其提交（一旦他/她終於看到了發展需要一個更明確和穩定的形狀）的歷史進入了一個分支：

如果（通過明確識別的特徵之一）需要
• 一套連貫的一個分支中提交的
• 幾個分支（見Trimming Git Checkins）

適當的程序，如代碼審查和畢業？

集成分支（在專用集成）回購可以幫助開發者：

• 變基上遠程集成分支之上他/她的發展（拉--rebase）
• 本地解決
• 推動發展到回購
• 檢查與不導致混亂積分;）

Answer 2

我認爲，我可能錯了，git最容易被誤解的其中一件事是它的分佈式特性。這就說明你可以工作的方式顛覆了你的想法，儘管你可以模仿SVN的行爲。這個問題幾乎是任何工作流程都會做的，這很好，但也有誤導性。

如果我對內核開發有所瞭解（我將專注於此），那麼每個人都有自己的用於開發內核的git存儲庫。有一個版本庫，linux-2.6.git，由Torvalds負責，它充當版本庫。如果他們希望開始針對「發佈」分支開發功能，那麼人們會從這裏克隆。

其他存儲庫做了一些發展。這個想法是從linux-2.6進行克隆，根據需要多次分支出來，直到你有一個可用的「新」特性爲止。然後，當這些準備就緒時，您可以將其提供給被認爲可信的人，他們會將這個分支從您的存儲庫中提取出來併合併到主流中。在linux內核中，這種情況發生在幾個級別（可信中尉），直到達到linux-2.6.git，此時它成爲「內核」。

現在，這裏是令人困惑的地方。分支名稱根本不需要在存儲庫之間保持一致。所以我可以git pull origin master:vanilla-code並從origin的主人處獲得一個分支，位於我的存儲庫中名爲vanilla-code的分支中。提供我知道發生了什麼，它確實無關緊要 - 它的分佈意義在於，所有存儲庫都是對等的，而不僅僅是像SVN這樣的多臺計算機共享。

因此，在考慮這一切：

1. 我認爲它是由每個程序員他們是如何做到的分支。所有你需要的是一個管理版本等的中央資源庫。樹幹可以是head。發佈可能是標籤或分支，修補程序本身可能是分支。事實上，我可能會以分支形式發佈，因此您可以繼續修補它們。
2. 我會合並，而不是rebase。如果你拿一個倉庫，克隆它，分支並做一些設備，然後從你的origin中取出，你應該在你的倉庫中創建另一個分支，並將最新的master合併到yourbranch中，以便其他人可以用你的修改儘可能少的努力。根據我的經驗，很少有必要真正重新設計底板。
3. 我認爲這是理解Git工作方式以及它可以做什麼的一個例子。它需要一段時間和很多良好的溝通 - 當我開始與其他開發人員一起使用git時，我才真正開始理解發生了什麼，甚至現在，我也不知道有些事情。
4. 合併衝突很有用。我知道，我知道，你希望這一切都可以工作，但事實是代碼的變化，你需要將結果合併成有用的東西。事實上，合併衝突只是更多的編程。我從來沒有找到一個簡單的解釋來處理它們，所以這裏是：注意合併衝突的文件，去改變他們應該是的，git add .，然後git commit。
5. 但是很適合。正如我所說過的，每個用戶的git存儲庫都是他們自己可以使用的，分支名稱不需要是相同的。例如，如果您有臨時存儲庫，則可以強制實施命名架構，但不需要爲每個開發人員提供，只能在發行版本庫中使用。
6. 這是合併階段。當你考慮代碼審查/通過質量測試時，你只能合併到發佈分支等。

我希望有所幫助。我意識到VonC剛發佈了一個非常類似的解釋......我輸入的速度不夠快！

編輯如何在商業環境中使用git，因爲這似乎是有關從評論OP一些進一步的想法：

• 的發行庫，我們把它叫做product.git，是訪問由一些負責實際照顧產品本身的高級程序員/技術人員負責。它們類似於維護者在OSS中的角色。
• 這些程序員可能也部分領導新版本的開發，因此他們也可能自己編寫代碼並維護varios存儲庫。他們可能會管理登臺存儲庫以獲取真正的新功能，他們也可能擁有自己的存儲庫。
• 下面是負責開發個別位的程序員。例如，有人可能會負責UI工作。因此他們管理UI.git存儲庫。
• 下面是實際開發功能的日常工作的程序員。

那麼會發生什麼？那麼，每個人從「上游」來源即釋放庫（它也可能包含前一天開發的最新材料）開始每天都會拉。每個人都直接這樣做。這將在他們的存儲庫中的一個分支上，可能被稱爲「主」，或者如果你叫我「最新」。程序員然後會做一些工作。這項工作可能是他們不確定的事情，所以他們做一個分支，做這項工作。如果不起作用，他們可以刪除分支並返回。如果是這樣，他們將不得不合併到他們目前正在從事的主要分支中。我們會說這是一個在latest-ui上工作的UI程序員，所以他做了git checkout latest-ui，然後是git merge abc-ui-mywhizzynewfeature。然後他告訴他的技術主管（UI領導），嘿，我已經完成了這樣的任務，從我身上拉下來。所以用戶界面的領導確實是git pull user-repo lastest-ui:lastest-ui-suchafeature-abc。 UI領導然後在該分支上查看它，並且說，實際上，這非常好，我將它合併到ui-latest。然後，他可能會告訴他下面的所有人，從他的ui-latest分支或他們提供給他們的任何名字中解脫出來，所以這個功能會被開發者探索。如果團隊很高興，UI主管可能會要求測試主管從他身上撤下併合並更改。這會傳播給每個測試它的人（變化的下游），並提交錯誤報告等。最後，如果該功能通過測試等，最重要的技術線索之一可能會將其合併到當前的程序工作副本中，此時所有的改變然後傳播回去。等等。

它不是一種「傳統」的工作方式，它被設計爲「同行驅動」而不是像SVN/CVS那樣的「分層」。實質上，每個人都有提交權限，但只能在本地訪問。它可以訪問存儲庫以及將您指定爲允許使用層次結構的發行版回放的存儲庫。

Answer 3

，我已經用，效果很好的模型如下：

A「福地」回購大家推拉/從，基本上是一個客戶端 - 服務器拓撲。

沒有主分支，因此沒有開發人員可以將任何代碼推送到「主線」。

所有的進展都發生在主題分支上。我們使用命名空間名稱來輕鬆檢測是誰負責它：jn/newFeature或jn/issue-1234

白板上的分支和看板/ Scrum卡之間也存在近似1對1的映射。

要釋放分支，它將被推送到祝福的回購庫，並將看板卡移動到準備好審查狀態。

然後，如果該分支被審查接受，則它是發佈的候選者。

當一組接受的分支合併在一起並使用版本號進行標記時，會發佈一個版本。

通過將新標籤推向祝福回購，新功能有了新的基礎。

爲避免合併衝突，請懇請開發者更新（合併）未發佈的分支到最新的發行標籤。

Answer 4

就我個人而言，我試着只在master分支中保留髮布就緒代碼。

當我在一個新功能或錯誤修復工作時，我在一個分支中執行此操作。我也在分支進行單元測試。如果一切正常，只有這樣我才能合併/重新融入主人。

我嘗試使用通用分支的命名規則爲好，如：

• bug修正/ recursive_loop
• bug修正/ sql_timeout
• 功能/ new_layout
• 功能/ enhanced_search