我正與一些其他開發人員合作開發一個相對較小，但快速變化的項目（一個Web應用程序）。我們使用Git進行源代碼控制。Git開發→生產工作流程 - 如何設置回購？
我們開始創建一個穩定的分支，它被部署到現場製作網絡服務器。 master分支是爲部署測試目的而部署到輔助「不穩定」服務器的部分。每當我們覺得大師分支準備上線時，我們將它合併爲穩定。
但是，我們來到這裏，我們希望以後主提交的一個，而不是一些提交的前一個點，所以我們用cherry-pick到變革拉進穩定。這會產生一個與主文件中的更改相同的新提交，並且感覺好像我們正在失去Git提供的良好歷史記錄。
有沒有更好的方式來處理這種類型的不穩定/穩定部署模型？
我想到的一個解決方案是使用功能分支，並且只有當我們希望它能夠正常運行時，纔會將功能分支合併到主模塊中。那麼我們將每個部署tag而不是有一個穩定的分支。
你正確地說，這破壞了歷史的git保持由挑肥揀瘦。這裏要思考的是，爲什麼你不希望前面的提交穩定？（如果它的一些下面的提交表明你還沒有準備好移植，你當然可以使用git merge <commit-id>而不是櫻桃選擇來保留歷史記錄 - 未來的合併對於不重複提交/變更集也是聰明的）
如果你不想要它們，因爲它們沒有準備好主線或完全測試，是什麼讓你確信所需的提交（取決於它們和它們的狀態）已準備就緒？
如果因爲他們還沒有做好穩定的準備，而且你想要的提交併不依賴於他們，那麼你的分支就不會像你所期望的那樣有效：那個提交可能在一個單獨的主題上分支（其中只包含你感興趣的特性所需的提交），那麼一旦你確定它能夠穩定運行，只需合併該分支。然後，您可以將需要此功能的其他分支重新綁定到穩定狀態，或者將功能分支合併到它們中（再次強調git在未來的合併中非常聰明）。
在您工作時需要多一點紀律來思考提交的影響（因爲您已經提前並經常提交），但它使分支/合併工作流程變得更簡單 - git checkout -b new-feature是您的朋友在主題分支工作中快速添加與其他無關的更改的提交（如果您的工作特別嚴密並且在工作樹上沒有額外的更改，則爲git checkout -b new-feature master）。
在git中，爲每一種你想要做的改變創建一個新的分支是很容易的。然後，當更改完成後，您可以先將它與不穩定的分支合併（最終到穩定的分支）。
當您只想將某些更改合併到穩定分支中時，可以通過選擇正確的分支來選擇所需的功能。
我們用下面的工作流程：
如果這個圈子運行速度不夠快幾乎沒有衝突。所有分行都比較短暫。每個人都靠近主人。
對於轉向prod，我們在部署驗證後手動在UAT存儲庫中創建分支。
閱讀http://nvie.com/git-model和使用hxxp：//github.com/nvie/gitflow