何時在git中分支？

我剛開始使用git，雖然它比較容易找出如何使用git做些事，但在與git做些事情時，我很難找出。何時在git中分支？

例如，一個人通常在什麼時候分支一個項目？

我在考慮分支當前項目的每個版本，以及何時完成將它與主人合併 - 這是常見的做法嗎？

來源

2009-07-28 LDK

我相信有人會做與我做的事情不同的事情。然而，這是我遵循：

始終爲每個功能創建一個分支（他們後來合併回）
爲每個錯誤分支修復
讓主分支是乾淨的通過不使它工作進展（WIP）

來源

2009-07-28 01:49:45

「讓主分支幹淨，不要讓它成爲工作進行中（WIP）」我喜歡這個想法。 – LDK 2009-07-28 01:53:20

我不確定分支當前項目的每個版本是什麼意思。

無論如何，你創建'主題分支'的git建議。通過「主題分支」，這意味着您在開發功能/錯誤時創建分支。假設我正在使用jQueryUI，並且我被要求爲jQuery Calendar添加一個功能，該功能允許用戶指定不可選擇的日期。

如果我在名爲master的分支中，我將創建一個名爲'SpecifyDateExclusion'的分支並開始進行更改。任何和所有與此功能相關的代碼都將進入這個分支。

master 
    | 
    | 
    |___ SpecifyDateExclusion

雖然我正在使用此功能，但是出現了一個錯誤報告，Opera 10中的日曆已損壞，此錯誤現在需要修復。我回到我的主分支並創建另一個名爲Opera10BugFix的分支，並開始修復它中的錯誤。

master 
    | 
    | 
    |___ SpecifyDateExclusion 
    | 
    | 
    |___ Opera10BugFix

很快，你可以有一個像

master 
    | 
    | 
    |___ SpecifyDateExclusion 
    | 
    |___ Feature1 
    | 
    |___ Feature2 
    | 
    |___ Feature3 
    | 
    |___ Opera10BugFix 
    | 
    |___ BugFix1 
    | 
    |___ BugFix2

什麼是你可能會問的優勢分支機構？

好處是它在準備我的發佈時給予我的靈活性。假設我的下一個版本主要是關於錯誤修復。

我將從master創建一個名爲'InterimBugFix'的新分支，併合並我所有的bug修復分支。

如果我想創建一個bug/feature版本的混合體，我將從master創建一個名爲「NextVersion」的分支，併合並我的功能/ bug修復分支。

Git對於如何管理這些分支非常強大，如果你能想象得到，Git會讓你做到這一點。

來源

2009-07-28 01:56:56 SolutionYogi

這取決於你的「分支策略」有很多答案。最簡單的兩個（以我的經驗）是任務/功能分支和發佈分支。你使用的將取決於你的發佈週期如何工作等等。

如果你正在整合並不斷釋放，然後任務/功能分支意義，因爲他們離開了「大師」（在其他VCS主幹）在一個相對穩定的狀態，使其釋放容易。但是如果你有一個更加結構化的發佈週期，也許發佈分支會更有意義，因爲它們可以用來更仔細地定義添加到每個發行版的內容。當然，混合策略也是可行的。

我通常使用任務/功能分支，因此每個錯誤或功能請求都是分支的。然後工作，完成後，合併回主。

來源

2009-07-28 01:57:27

Git最棒的地方在於它不會強迫你做任何決定。 Git的糟糕之處在於它不會對你做出任何決定。

您的工作流程完全取決於您。您是打算合作還是獨立開發？發佈之間的交付時間短嗎？這些限制可能有助於定義合適的工作流程。

我在4名開發人員的小團隊中工作，進行爲期兩週的迭代週期。在週期開始時，我們就範圍達成一致並針對主人開發。我們預計超過兩週的任何事情都會在分支中移動（或開始生命）（這種情況不會經常發生，我們的範圍很緊張）。

在兩週週期結束時，我們執行我們的QA，標籤和釋放。開始下一個週期，那些其他分支合併回主。

如果你需要修補的釋放，我們創建了一個分支，提交，QA，標籤和釋放。

對於任何實驗，我們通常會創建一個新的分支，並保持它從主隔絕，直到它適合於合併的，或丟棄。

總之，我們的團隊分支時：

特點超出我們的迭代週期
補丁發佈
體驗功能

我們的工作流程是非常集中的，而且可能不典型許多Git用戶。既不是對錯，也只是選擇最合適的東西。

來源

2009-07-28 01:58:58

「針對主人開發」 - 這是否意味着您使用主分支進行開發？ – LDK 2009-07-28 02:31:16

這是正確的。 – 2009-07-28 06:16:43

這非常重要：Git沒有版本控制工作流程。相反，它是一個版本控制工作流構造工具包。就像使用樂高建築套件一樣，將所有東西放在一起都是很多乏味，困難，乏味的工作，但結果會變得非常棒，因爲它是你自己建造的，手，它是根據您的需求量身定做的。說得好！ – 2009-07-28 15:49:07

Web應用程序開發，我們這樣做：

我們維持一個所謂的「生產」純淨的分支。它包含在現場網站上存在的代碼。

在任務分支中發生的任何更改。所以你可能會看到一個分支Task-13923-add-feature-x。這些分支是從生產分支創建的，並且生產分支在合併到生產之前必須合併到其中（所以它始終是乾淨快進，沒有潛在衝突）。

其他人從合併時的「生產」分支一次進入他們的任務轉移到保持最新。

來源

2009-07-28 02:03:54 gahooa

有疑問時，分支。分支機構便宜，新分支機構的信息很容易轉移到舊分支機構。當一個分支失效時，它很容易被殺死。

來源

2009-07-28 03:04:17

何時在git中分支？

回答

相關問題