国产av日韩一区二区三区精品,成人性爱视频在线观看,国产,欧美,日韩,一区,www.成色av久久成人,2222eeee成人天堂

推薦Gitlab flow中的merge request方式
master, develop分支都是不讓直接push的
master = production
develop = next release
當有新需求時，建立需求分支 feature/aaa
開發(fā)完成后創(chuàng)建 merge request
code review 后合并 feature/aaa 到 develop 分支
上線時合并 develop 分支到 master
發(fā)布 master 分支

對于樓主的問題可以這樣
基于 feature/aaa 建立新分支 feature/bbb 完成補救工作后合并到 develop, feature/aaa 建立新分支 feature/bbb 完成補救工作后合并到 develop, master 然后上線
繼續(xù) feature/aaa 的開發(fā)工作，最后合并到 develop, feature/aaa 的開發(fā)工作，最后合并到 develop, master

可以參考 git workflow

大致就是 從 master分支checkout一個hotfixes分支。在hotfixes把補救的寫好，然后分別merge到master和develop。此時就可以刪除這個hotfixes分支。

然后再從develop分支開發(fā)完善你的功能，最后把develop分支merge到master上線。

或許還有更好的方法，僅供參考

雷雷

先幫樓主解決這個問題。

樓主的分支策略不用做特殊處理，按照正常的流程，結合 git 的功能即可處理的很好：

• 首先，在 develop 上開發(fā)完成的 commit 后繼續(xù)提交補救性的代碼，以保證 develop 的特性可以正常發(fā)布使用。這里樓主提到的“補救性的方案”其實是特性開發(fā)的一部分，不算 bugfix 。
• 之后，在測試通過后可以進入 release 流程。如果樓主本來的分支策略中有 release 分支，可以在上一步結束后就打出 release 分支，develop 繼續(xù)接受新的特性提交。而這次設計的方案和臨時性的補救在 release 上接受 bugfix。
• 上面其實都是正常的開發(fā)發(fā)布流程。后續(xù)的設計的開發(fā)和補救功能的刪除怎么辦呢？其實后續(xù)的開發(fā)其實可以看做改進或者是新特性都可以，正常開發(fā)就好。你們可以根據需要在這個改進的過程中任何的節(jié)點 revert 當初的補救提交（git revert 命令)。
• revert 補救和“原有的設計”實現后，在按照正常的發(fā)布流程發(fā)布就好了。

按照我的理解，樓主所說的“原功能”、“補救方案”這些都是正常的代碼提交。樓主所困惑的應該是臨時補救方案最終要被丟棄（回滾）這個問題如何處理，所以使用上面提到的 git revert 命令應該能滿足樓主的預期。這樣既能保證所有的對代碼庫的操作都可以被記錄在主干（master、develop）中，也避免了復雜的分支模型等問題。

另外，不知道樓主使用的分支策略是不是 按照 @rsj217 提到的 workflow 來做的。如果 develop 是所有開發(fā)人員的主要開發(fā)分支的話，我覺得 develop 最好還是不要接受未完成的開發(fā)特性直接提交比較好。日常的開發(fā)工作，尤其是多特性/分支并行開發(fā)的情況下，多個特性分支能避免相互之間的干擾。
回到樓主的問題上來，這個不能使用的設計方案可以繼續(xù)開發(fā)，不要合并到 develop 上去?；谶@個分支 checkout 一個補救特性的開發(fā)分支，測試完成后合并到 develop 進入發(fā)布流程即可。后面的 merge 和 revert 建議還是要的，非迫不得已不要違背流程做特殊處理，而且這樣保留了所有的代碼commit操作。

建議參考git工作流 master主分支 develop用于開發(fā) release用于發(fā)布新版本 hotfix用于修復線上bug等緊急操作

姑且說你的補救分支是develop1，上線之后develop1和master會merge到一起變成了新的master,原功能的分支develop等成熟穩(wěn)定之后merge下新master（很大可能會沖突）,把develop1的那部分刪掉，測試沒問題上線。有點麻煩，可能還有點笨，可是git每次merge都是向前產生了一個新的點，你要是想等develop穩(wěn)定了把master回退，如果中間有其他發(fā)布了，不久丟東西了么。
或許還有更好的方法，僅供參考

如果看 A successful Git branching model 吃力，可以看 Juven Xu 的翻譯 一個成功的Git分支模型

使用git-flow會對你有幫助，可以用簡單的命令，幫你完成創(chuàng)建，完成分支。并且有規(guī)范的release,hotfix,feature工作流