我看到一些人在master旁邊使用名爲dev的分支作爲開發環境。即使他們使用功能分支，他們說有dev分支更好。我其實沒有聽到爲什麼的合適答案。即使有開發分支，在推動它之前仍然必須完成工作。 （http://nvie.com/posts/a-successful-git-branching-model/）爲什麼我們需要開發分支？
我真的不明白。爲什麼我需要開發分支。
就是這樣。這個流程爲我解決了一切。我沒有看到任何理由有dev分支。
我錯過了什麼情況？使用master作爲開發環境有什麼問題？如果你使用dev分支，你會使用哪些情況？
主分支，它是你生產你的工作分支，它必須是沒有缺陷，以及測試，包含穩定的代碼。然而，開發分支可能包含問題和其他複雜性。
比方說，您已經從主分支上的開發服務器提交了開發內容，您將進行分段操作，不幸的是它會創建問題w.r.t.登臺服務器設置，你回到開發並修復它。在這之間，客戶端要求緊急修復程序，您要在活動服務器上緊急地進行一些更改。這種恢復和更改文件在這種情況下可能是一項非常艱鉅的工作。
相反，如果您僅爲活動的主分支，開發環境的開發分支，用於測試和分級環境的分支分支。
你在dev分支上開發，推送到分段，如果工作與分段分支合併，如果沒有，返回dev，修復它，然後再次推送。如果舞臺全部設置好了，你就可以把它活下來。檢查一段時間。如果有問題，立即檢查掌握，修復它，再次推送階段，一旦所有設置，在主站作爲當前分支合併主站和結帳。
在這種情況下，如果客戶端要求緊急更改，請在開發服務器上檢查master分支，從中創建一個新分支（不要直接更改爲master），修復它，推入舞臺，然後繼續生活。在這一匆忙中，如果修復出錯，您可以隨時結賬以掌握主人，並將其與主人合併。
在這種情況下，您的開發服務器上的開發分支是未觸及的，這更容易再次開始您的開發。
Git並不關心你的主分支是無bug的，還是測試的，或者是穩定的。你的意見沒有錯，但我希望你意識到問題的問題是有問題的，因爲總體上沒有正確的答案......它是純粹的意見（無論是個人還是團隊集體）......無論什麼作品最好任何給定的團隊都是該團隊的正確答案。 – mah
是的，即使我同意，我只是假定主人是無錯的，因爲它與我的示例中的生產環境相對應。 –
緊急錯誤修復或修補程序版本是答案，爲什麼我們需要一個像主設備旁邊的設備一樣的分支。 –
我會建議你使用開發分支。
我通常遵循拇指以下規則：
在代碼中的微小變化的「發展」的分支去。
幾個人將要開展工作的主要特點是在他們自己的「功能」分支上。
master分支上的小錯誤修復程序會在他們自己的分支上進行，稱爲「hot fix」，並立即合併回主分支。
最後的一切都被合併到主文件中。主人應該被視爲你的發佈部門，向公衆發佈。它應該是已經過測試並被認爲是穩定的代碼。
詳細解釋請見：https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
大師的作品對我和我的團隊來說還不錯！ –
這很好。我認爲這是遵循慣例，或者如果他們在主分支中搞亂某些東西，他們會很謹慎。 – rajuGT
當同一個項目中有多個團隊時，dev分支可能會很有用，但它不是強制性的，它必須符合您的需求。 – axelduch