Git分支模型：幾個問題

我們已經接近分支模型，我們有一個代表生產代碼的master分支和代表未來版本的release-x.x分支。Git分支模型：幾個問題

然而，也有少數情況下，我們不知道如何有效地解決：

直播bug修復是不相關的當前版本

新feature是支鏈的release-2.0的並完成模塊A的重寫。
新的feature已完成併合並在release-2.0。
當前活動模塊A中的錯誤在master上找到並修復。

在這一點上，我們推測有2種可能：

我們變基上masterrelease-2.0帶來錯誤修復和解決衝突（丟棄錯誤修復代碼也就是現在無關）。最終，我們在master版本準備好後合併release-2.0。
我們摘櫻桃只有bug修正是相關的釋放到release-2.0，當釋放準備就緒，我們覆蓋了整個master歷史與release-2.0歷史。

解決方案＃1迫使我們解決合併與我們知道是不是需要提交衝突，但解決方案＃2迫使我們擦拭全master分支，由release-2.0分支的歷史上每一個版本替換它。這引入了一些丟失錯誤修復的機會，我們忘記了在release-2.0上的選擇，並且還可以打破在發佈之前支持master的錯誤修復。

一個功能不使其進入發行畢竟

我們創建了一個新的feature，重訂上release-2.0，並與--no-ff合併爲release-2.0。
發現了一些錯誤，所以我們在feature上修復它們並重新執行上述合併過程。
客戶再次審查該功能，決定他們想要改變很多事情 - 沒有這些功能，該功能沒有價值，但我們無法對release-2.0進行這些更改，並且必須等到release-3.0。

什麼是處理這種情況的正確方法？我們是否應該恢復與在release-2.0中完成的功能相關的所有提交，並顯示一條消息，如「恢復功能X - 推回到3.0」，然後再合併feature到release-3.0？

來源

2017-08-03 plalx

好像這裏有多個問題，這兩者都是主要處理意見。是否有可能縮小問題的焦點並將其作爲一個技術問題重新說明？ – larsks

@plalx你有答案解決你的問題嗎？如果是，您可以將其標記爲答案。這將有利於其他有類似問題的人。 –

首先，如果你無論是在release-2.0和master分行變更模塊A，並且要在master應用模塊A的更改您的release-2.0分支。

除了列出的解決方案1和解決方案2之外，還有另一種方法可以將模塊A的更改從master更改爲release-2.0。即直接從master結算到release-2.0的相關文件，然後提交更改。如下具體步驟：

git checkout release-2.0 
git checkout master /path/to/moduleA 
# Such as git checkout master moduleA/* 
# Now module A is what you changed in master 
git commit

二，在大多數情況下，如果你使用的版本格式x.y（MAJOR.MINOR），x（主要）表示由客戶所要求的主/顯著的變化， y（次要）意味着我們修復錯誤或客戶在審覈您所做的工作時不需要做任何修改。

因此，如果您的客戶在審覈2.0版本時提出大的更改請求，則可以將該項目開發爲版本3.0。完成作品後，您的客戶將會查看3.0的版本。如果他們報告3.0版本的bug或微小更改，則可以將版本更改爲3.1（在完成更改後，將release-3.0分支重命名爲release-3.1或添加標記3.1）。

此外，有another different branching module你可以參考：適用於develop分支 - >當完成工作 - >合併develop到release分支 - >的release分行獲得批准後/審查 - >合併release爲master分支 - >在標籤中記錄發佈版本。

來源

2017-08-04 02:00:44

我會建議使用標籤而不是分支來表示什麼是生產。這樣，您可以簡單地檢出一個新的修補程序分支並修復錯誤，然後直接部署該提交併將其標記爲當前生產代碼，如果知道所有內容都將更改下一個版本，則無需將其合併。

* 54c82e0 - (HEAD -> master) Commit6 
* bb6db8e - Commit5 
* 5156c9f - Commit4 
| * 630a150 - (tag: v1.1) Hotfix commit 
|/ 
* db5c984 - (tag: v1.0) Commit3 
* 00c6c5c - Commit2 
* 715412a - Commit1

你會用你是有計謀的分支模型，但主反而是你的「主幹」，在那裏所有的工作合併，而目前生產的代碼將始終有一個標籤，你可以檢出您是否需要修補程序。

我會小心的選擇一個像GitFlow這樣的「已被證實」的分支模型，所以我認爲你是在正確的軌道上，試圖找出適合你的需求的東西。欲瞭解更多，可以參閱：

來源

2017-08-04 05:48:54 sp1nakr

嗯，我實際上試圖實現基於主幹的開發，而不是GitFlow;） – plalx

聽起來不錯！儘管如果您試圖實現更流暢的分支模型，釋放分支並不是必需的。基於Trunk的幾乎刪除了所有多餘的分支，例外是用於pull請求和代碼審查等的功能分支。 – sp1nakr

在我的情況下，我們只需要短暫的發佈分支來準備發佈本身（例如，我們可能需要刪除一些功能在掌握，但應該只在未來的版本中以某種方式部署 - 類似的事情）。 – plalx

Git分支模型：幾個問題

回答

相關問題