如何在使用Git分支/合併的開發分支中提交buggy提交？

我正在研究不同的Git分支策略，我一直在卡住。假設你有一個主分支。此外，你有一個開發分支，這是一個從主分支。有功能/特性分支：如何在使用Git分支/合併的開發分支中提交buggy提交？

FixFrontEnd
FixBackEnd
ChangeConfig

三種不同的開發者每一個變化。 ChangeConfig開發人員可以快速完成，提交併合併到開發分支中。該開發分支現在已經構建並部署到開發環境。有人測試了這個新配置，並且它已被批准從Dev遷移到QA環境。 FixFrontEnd和FixBackEnd分支同樣可以找到成功。他們最終會繼續進行質量保證。

優先級改變下和三個補丁/功能左坐在QA。新的YetAnotherChange修復/功能使其成爲QA。我們在QA中發現了FixFrontEnd和ChangeConfig的問題。然而，YetAnotherChange必須立即生產。

一切我讀說，開發分支合併到主分支，使用主生產創建一個新的版本，它的部署。 FixFrontEnd和ChangeConfig會不會在合併中被拖拽到主上？大家如何接近這個？

櫻桃採摘似乎是一個複雜的選擇。我想就如何解決這個問題提出一些好主意。我正在尋找一個簡單的解決方案。另外，假設我們能夠挑選提交。我們怎樣才能真正相信櫻桃採摘和建造的內容與我們使用開發分支構建時的相同？我在這裏的樹林迷路了嗎？

來源

2016-11-29 Leroy Jenkins Coder

請向我們展示各個分支的一些圖表。 –

實際上，前端和後端通常被視爲單獨的項目，並且可能會更好，因爲兩個獨立的存儲庫。也許這對你的情況值得思考？ – halfer

所以你想修改生產而不需要修改FixFrontEnd和ChangeConfig分支。您可以使用這種方法來修復它。讓我們舉例說明通過下圖：

A---B---C master 
\ 
    D----E----F----G ----L develop 
    / |  \  \ 
    H  I  J  K

假設從各修補/功能分支機構提交歷史：

ChangeConfig： H和然後合併到開發分支

FixFrontEnd：我，然後合併開發分支

FixBackEnd： J然後合併開發分支

YetAnotherChange： K和然後合併到開發分支

你只需要找到d，F和L提交ID，然後使用git rebase --onto <commit id for D> <commit id for F> <commit id for L>，develop分支將不包含從FixFrontEnd和ChangeConfig變化分支機構。它可以用於生產。該圖將相等於：

A---B---C master 
\ 
    D ----G ----L develop 
     \  \ 
      J  K

注：墊底期間，也有可能有衝突的文件，你需要使用git add <conflicted filename>和git rebase --continue，那麼底墊仍將繼續。

來源

2016-11-29 05:45:22

在生產時，這不包括FixBackEnd嗎？這還沒有批准生產，因爲它仍然在QA中。那麼，我們爲什麼要把它合併到主人手中呢？我認爲主人應該代表什麼是生產。 –

@LeroyJenkinsCoder，是的，它不包含FixFrontEnd和ChangeConfig（問題分支）。對不起，誤解，我的意思是它已準備好生產。並且所有修復都在開發分支上執行，該圖將等於我答案中的最後一個（我剛剛添加它）。 –

一切我讀說，開發分支合併到主分支

不是真的：您可以：

上主的頂部（再快變基YetAnotherChange -forward主到YetAnotherChange HEAD）
合併master回develop
重新綁定develop之上的其餘功能分支。

任何重新綁定操作都會改變這些分支的歷史，因此需要與在這些分支上工作的開發人員進行良好的溝通，以便他們將工作樹重置爲新的分支HEAD。

來源

2016-11-29 05:45:37 VonC

如何在使用Git分支/合併的開發分支中提交buggy提交？

回答

相關問題