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