我們有一個GitHub項目（主）生產分公司，團隊的每一個成員都有該項目的Fork到自己的資源庫。如何創建一個Git回購
一旦開發人員固定的東西，他創造他的地方分叉回購內一個新的分支，並提交到該遠程倉庫後，他們要求Pull Request，這樣的變化進入主reposiroty。
我們發佈到生產的「手動」，每週一次，但我們不得不在生產中的問題，因爲不期而遇開發商已承諾其分叉庫和其他開發人員具有較高的privilegies接受更改並歸併到主回購，那麼別人發佈生產，他不知道這些新的變化沒有通過質量保證過程。
所以，我要的是要創造這樣一個Production庫，所以當我們在主回購的代碼，我們知道是穩定的，然後努力創建這樣一個分公司生產，所以如果被錯誤的東西將提交併合併到主回購，那麼生產發佈的代碼不受影響。
任何線索或最佳實踐來做到這一點？
使用Git的工作流程是不夠好，對待這個問題的關心。
首先，要解決這個問題：
款待意外碼推爲錯誤並修復它，你會解決任何其他的bug。執行此活動的最佳人員是推送該代碼的開發人員。開發人員可以將它修復到fork中並提交一個pull請求。儘量不要使用此拉取請求添加任何其他不相關的代碼。
關於生產分公司或回購：
我不認爲你需要另一個生產科/回購（你已經有一個）。正如您在當前的PROD回購中發生的那樣，意外的代碼推送也可以使其成爲新的分支/回購。
而是使用標籤/釋放功能在GitHub上。只要master repo中的代碼狀態已準備就緒，就可以對其進行標記並將該標記用於生產發佈。
不知道我在正確理解的問題，但你可以根據需要添加儘可能多的遠程倉庫。有一個在臨Git的本書叫Working with Remotes一節，深入探討這一點。
根據我的經驗，分離開發和生產的代碼通常與分支模型完成，如git的流動。如果你喜歡，你可以創建單獨的存儲庫來解決這個問題，但這樣做是不必要的。這是因爲如果開發人員A提交由開發人員B合併的PR，那麼開發人員C在嘗試提交上游時會得到一個非快速轉發錯誤。這被稱爲顛覆式工作流程。每docs：
的Git不會讓你推，如果自上次有人推你牽強，所以，所有開發商推到同一臺服務器集中模型工作得很好。
如果在推送前未向上遊分支提交併合適地提交，那麼有人可能會自己重寫歷史記錄。