15
我有一個關於git的小項目，我是唯一的開發人員。目前，我只用一個主分支來實際工作。在單人git項目中使用分支是明智的嗎？
現在該項目是以某種方式工作，我想實施一些新功能。問題是，我應該爲每個新功能創建新分支並將其合併回來嗎？
事實是，我的工作流程將會改進「功能分支」，並且在大多數時間將它合併回原來的「主分支」，那麼根本不需要創建新分支？
A
回答
19
從gitworkflows手冊頁：
任何平凡的功能將需要 幾個補丁來實現，並可能 獲得額外的錯誤修正或改進 其生命週期內。
犯下直接在 集成分支一切導致許多 問題：壞提交不能 百廢待興，所以他們必須轉換一個，這將創建混亂 歷史，並進一步潛在的錯誤 當你忘記回覆一個 組變更的一部分。並行工作 混淆了更改，進一步造成了混淆。
使用「主題分支」解決了這些問題。
即使您是唯一的開發人員，也應該使用主題分支（即功能分支）。
除了上述原因，我想補充：
- 如果你有一個功能，將需要很長的時間才能完成，在一個特性分支的工作讓您輕鬆對功能暫停工作去做別的事情
- 如果您有機會需要支持多個版本的代碼（即您的當前版本爲v2.0，但客戶/用戶正在使用v1.0，則使用主題分支可讓您輕鬆地將錯誤修復合併到多個版本。
0
經驗法則：如果你在開發過程中破壞產品，分支。 假設你在樹幹中發現一個錯誤，並且想修復它。
0
只要它可以幫助你，它是有道理的。
我用我的個人項目SVN，有時當我想研究一個新功能或扔掉很多代碼我喜歡分支我的主分支。
這樣我可以長時間工作在新功能上（閱讀：多個提交）如果我失敗我總是可以回到主分支，如果我成功，我可以合併整個分支或只是有意義的變化。
2
我會說它可能是個人喜好，但在我工作的一些獨奏項目中，至少爲新作品創建一個分支有時很有用，讓主分支可用於錯誤修復。當發現有人向現有版本報告錯誤時，我發現自己正在處理新事物。在這種情況下，我可以輕鬆地擱置新代碼並修復主分支上的錯誤，然後回到我正在處理的事情上。然後最後將它們合併在一起。
雖然我通常不支持每個新功能。我通常不會同時在多個功能上工作......偶爾會出現一次，在這種情況下，這取決於兩個功能文件重疊的程度，這會導致我再次分支。
3
我會說是的，每次我將代碼推入生產環境時，我都會創建一個版本分支。因此，如果出現問題，我可以簡單地返回到該分支，並將修復推出修復程序，然後將我的代碼更改合併到主幹中。
8
我應該爲每個 新功能創建新分支，並在事後將其合併回 ？
是的，因爲中途通過實施該功能，你會發現在你的產品代碼一個表演停止的錯誤，你會慶幸你可以git checkout master回到那就是在生產代碼，並修復它。我的規則是始終讓我的主分支處於可部署狀態。
2
我是說有特色的分支，即使在沒有客戶一個簡單的1人項目。
的原因是工作流程。如果你使用一個單一的工作流程，你可以在應用所有你參與的項目，每次都會犯錯誤，減少想法的決定，如果你的「微不足道的」項目突然變成了自己的生活，它也會使生活變得更容易:-)。
（單個工作流當然是理想的，但任何幫助...）
2
添加到其他人所說：分支是那麼容易創造&保持在git的，爲什麼不能讓一個分支？即使你永遠不需要在舊分支上進行bug修正/更新，你仍然會得到一些額外的關於你的代碼庫的元數據，通過你一年中很樂意擁有的分支。
我非常喜歡製作各種各樣的功能分支，原因有兩個：首先，您可以構建您的工作流程，以便主分支隨時可以發貨（這非常酷）;第二，一旦您有一些功能分支的歷史，諸如gitk或qgit之類的樹看起來給你一個非常酷的代碼庫歷史的高級別感覺，單行不會。
我也大致遵循這個工作流程，但我最初標籤發佈的版本，而不是創建一個分支。然後，如果需要，我會從該標籤創建一個分支;但大多數情況下我並不需要，所以將它們作爲標記可以阻止我的分支名稱空間變得混亂。 – 2009-11-15 19:59:53
好點，我的發佈很少，所以我沒有真正考慮長遠。標籤聽起來像是一個更清潔的方式向前邁進。謝謝！ – Anthony 2009-11-15 20:34:12