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

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

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

可以參考 git workflow

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

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

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

develop（未開發(fā)新功能）-> develop（已開發(fā)新功能，新功能不可用）-> develop（繼續(xù)完善到可用）
                 └───> fix（補(bǔ)救）                                 ╲
                           └───> master（記得在~1版本打 tag 哦）      ╲ merge
           master（tag）<────────────────────────────┘               ↘
                 └───────────────────────────────────────────────> master

先幫樓主解決這個(gè)問題。

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

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

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

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

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

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

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

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