當使用git（流程）并在階段/測試環境中客戶對所開發的內容進行評論時，處理未批準的功能和已批準的功能的最佳方法是什么？考慮以下情形：多個開發人員在sprint或連續工作流中使用不同的功能。客戶需要審查這些功能，并且要使其能夠在舞臺環境中進行審查，必須將這些功能合并到dev分支中并進行部署。假設是否已經開發了兩個功能，并由開發團隊認為已經完成，并已推送給開發人員?？蛻魧ζ溥M行審核并批準其中一個。但是現在客戶希望將批準的功能發布到生產中?，F在，開發部門被未經批準的功能代碼“污染”，該功能代碼無法推送到生產環境。處理這種情況的最佳方法是什么？當然，實際上更復雜。是選擇櫻桃還是解決方案，還是應該重新考慮分支機構的整體流程和處理方式？
2 回答
有只小跳蛙
TA貢獻1824條經驗 獲得超8個贊
這個問題（由“非批準，但已經集成”功能分支污染Dev分支）是究竟什么形容拉曼古普塔在“ 如何Git來完成分支的創建者 ”。
（GitHub庫的工作流程：rocketraman/gitworkflow）
在您的情況下（gitflow），您需要先還原未批準功能的合并提交，然后再將開發人員合并到發行版中。
但是，“ gitworkflow”使用短暫分支，與gitflow相反：
GitFlow倡導擁有兩個永恒的分支-? master和develop
這兩個工作流（gitflow或gitworkflow）都使用“功能”或“主題”分支：
主題分支是當前所有工作的完成地-每個問題，錯誤或功能一個分支，并且可以有多個主題分支同時進行開發。
主題最終合并到nextgitworkflow 的分支“ ”中。
但是，一個關鍵的區別是該next分支永遠不會合并到該分支master（與永久分支“ develop” 相反，后者打算在gitflow中合并到master/ release）
現在，該topic課程已升級為next，可以成為測試版或接受版本的一部分。因此，接下來的每個主題現在都可以進行第二輪穩定化，這正是Beta發布/接受測試環境的目的。
但是，請注意，使用gitworkflow時，我們仍未承諾（沒有雙關語！）將其topic作為下一個正式生產版本的一部分-仍未合并到master。
這在概念上與GitFlow的release分支相似，但是更加靈活和強大，因為master它不依賴于next任何東西，也next永遠不會被大量合并到其中master（不同于相應的GitFlow分支develop和release）。
如果下一個未合并為母版，那么如何將特征畢業到生產中？
一旦判斷出某個主題足以穩定以釋放該主題，該主題就會再次畢業并合并到master（或也許maint），--no-ff以保留該主題分支的完整歷史記錄。
為什么這樣更好：
請注意，在gitworkflow中，不穩定和穩定的開發工作永遠不會在同一分支上混合在一起。
相比之下，使用GitFlow，我有兩種選擇：
我可以在自己的分支上單獨測試主題，或者
我可以將其合并以進行測試。
兩種選擇都沒有吸引力。
當與其他正在進行的工作一起部署時，前者不能提供對主題穩定性的真實測試，并且
后者認為這個話題可能要在穩定之前發展。
含義：
簡而言之，在GitFlow中，在保持開發工作清潔和隔離在主題分支上的愿望與通過合并主題分支使其與其他工作進行合并以使其可見并可以測試并檢查沖突之間的渴望之間始終存在著無法解決的張力。
Gitworkflow既可以實現兩個目標，又可以不犧牲另一個。
- 2 回答
- 0 關注
- 696 瀏覽
添加回答
舉報
0/150
提交
取消