在git中，dev和production分支之間的區別在哪裏？

我有一個項目，我管理一個git倉庫。我們使用progit分支策略（如接受的答案中所述，這裏是Git branch strategy for small dev team），其中一個分支是生產分支，另一個分支是開發/測試分支。我們使用結構部署代碼。在git中，dev和production分支之間的區別在哪裏？

當我們準備用git製作新的產品發佈版時，我們將開發/測試分支合併到生產分支中，然後使用結構部署生產分支。問題在於開發和生產之間存在代碼差異 - 一些徽標發生變化，一些不同的數據庫主機/憑證等等。我一直在保存一個包含差異的.patch文件，並在構建生產環境時使用這個補丁來構建補丁程序，但這種方式並不能很好地工作。特別是，如果修補程序周圍的一些代碼發生了變化，則完全失敗 - 修補程序無法應用，並且我的部署中止。

我一直在想，如果我不應該直接將所有更改應用到生產分支？這有什麼缺點？

我關心的一個特殊用例是，如果我們需要做一個修補程序。我們目前通過從生產環境中分支，進行更改，然後將該分支合併到開發和生產中來實現這一點。如果生產分支與開發分支不同，那麼當修補程序合併到開發中時，這些更改是否會被拉入開發分支？

來源

2012-01-25 Igor Serebryany

你的問題基本上歸結爲「如何在一個分支中進行更改，然後當我合併到另一個分支時不會傳播該更改？」。這相當簡單。在這一點上，我假設你的生產分支基本上只是一系列合併，無論是從開發分支，或從一個修補程序分支。所以大概從你的開發分支做git merge production不會做任何改變。鑑於此，請繼續並對生產分支進行更改。現在提交它們。現在結帳開發分支並運行git merge -s ours production。這基本上意味着「從生產合併，但拒絕所有他們的變化」。這將創建合併提交，但實際上並不會觸及您的開發分支。

一旦合併後，您現在可以合併的分公司生產納入發展（或者更確切地說，合併修補程序分支）不用擔心，因爲你的生產只承諾現在已經「合併」成發展（儘管事實代碼更改本身被拒絕）。所以合併你的修補程序分支將不會拉入生產專用代碼。

一旦你完成了這個任務，唯一一次你需要返回並重新應用這個技巧就是如果你進行更多生產性更改。如果您在開發分支上進行與僅生產更改相沖突的更改，那麼在將開發合併到生產中時，您可以繼續並毫無問題地接受衝突的生產方。

來源

2012-01-25 01:08:53

沒問題，所以，這是行不通的：當我從生產環節開始'git merge development'的時候，開發分支的差異會覆蓋生產分支中的僅生產更改。我需要保留不會離開生產分支的變更 - 他們既不進入任何其他分支，也不被其他分支覆蓋。 –

@IgorSerebryany：如果您將開發中的變更改爲與您在生產中保留的完全相同的行，那麼是的，您將遇到問題。每當你做出這樣的改變時，你都必須進行虛擬合併，以基本上「堅如磐石」製作部門應該如何看待這些線條。 –

我做了以下精緻的芭蕾舞：（1）確保兩個分支同步; （2）我將我的更改應用到生產分支（3）'git merge -s our production' from development branch; （4）git合併 - 來自生產分支的我們的開發。因此，我認爲我已經達到了我想要的狀態，在那裏我的變化沒有被破壞，也沒有被轉移出生產。 –

我也有這個請求在開發分支和生產分支。我不認爲git合併 - 我們的**是一個很好的解決方案，因爲它可以確保後面的一個合併不會被覆蓋，並且在那之後它將導致dev和生產之間的父親關係。你必須每次都使用git merge -s我們的**，這會使日誌圖變得非常醜陋和毫無意義。

因此，我建議使用

git的櫻桃採摘

。這可以確保你想要的內容。

來源

2015-01-20 06:20:28 peacepassion

在git中，dev和production分支之間的區別在哪裏？

回答

相關問題