这种场景下该采用怎么样的git分支管理策略？

Question

目前开发的项目采用git作为版本管理工具，

平时开发有两个分支，develop和master

在develop上开发，

在master发布正式版本。

目前有这样一种情况：

有一个设计好的功能，由于种种原因，在develop分支上开发完成后不能正常使用，

需要使用另一个补救性的设计方案临时代替，此代替方案需要上线，发布到master里面

当原功能成熟后，再删除这个补救方法，切换回原有的功能

请问我该使用哪种git分支策略？

Answer 1

Gitlabフローでのマージリクエスト方法を推奨します
マスターブランチと開発ブランチを直接プッシュすることはできません
マスター=プロダクション
開発 = 次のリリース
新しい要件がある場合は、要件ブランチ feature/aaa を作成します
開発が完了したらマージリクエストを作成します
コードレビュー後、feature/aaa を develop ブランチにマージしますfeature/aaa 到 develop 分支
上线时合并 develop 分支到 master
发布 master 分支

对于楼主的问题可以这样
基于 feature/aaa 建立新分支 feature/bbb 完成补救工作后合并到 develop, master 然后上线
继续 feature/aaa 的开发工作，最后合并到 develop, master オンラインにするときに deveve ブランチを master にマージします

master ブランチを解放します🎜 🎜投稿者の質問については、次のことができます🎜 feature/aaa に基づいて新しいブランチ feature/bbb を作成し、修正作業が完了したら、それを develop、master そしてオンラインにします🎜 feature/aaa の開発を続け、最後にそれを develop、master にマージします🎜

Answer 2

git ワークフローを参照できます

大まかに言うと、master ブランチ checkout から hotfixes ブランチまでです。修正を hotfixes に記述し、master と develop にそれぞれ merge します。この時点で、hotfixes ブランチを削除できます。 master分支checkout一个hotfixes分支。在hotfixes把补救的写好，然后分别merge到master和develop。此时就可以删除这个hotfixes分支。

然后再从develop分支开发完善你的功能，最后把develop分支merge到master

次に、develop ブランチから関数を開発して改善し、最後に develop ブランチを master に merge します。 > オンラインにします。

もっと良い方法があるかも知れませんが、参考までに#🎜🎜#

Answer 3

リーリー

Answer 4

まず投稿者がこの問題を解決できるよう手伝ってください。

元の投稿者のブランチ戦略は特別な処理を必要とせず、通常のプロセスに従って git の機能を組み合わせることで非常にうまく処理できます。

• まず、develop でのコミットが完了した後も引き続き修正コードを送信し、develop の機能がリリースされて正常に使用できることを確認します。投稿者がここで言及している「改善策」は、実際には機能開発の一部であり、バグ修正とはみなされません。
• その後、テストに合格した後、リリースプロセスに入ることができます。元の投稿者の元のブランチ戦略にリリース ブランチが含まれている場合は、前のステップの後にリリース ブランチを作成でき、開発は引き続き新しい機能の送信を受け付けます。今回の設計案と一時的な改善策は、リリース時にバグ修正が行われる予定です。
• 上記は実際には通常の開発およびリリースのプロセスです。その後の設計開発や救済機能の削除はどうなるでしょうか?実際、その後の開発は実際には改善または新機能とみなすことができ、単なる通常の開発と見なすことができます。必要に応じて、この改善プロセス中に任意のノードで元の修復コミット (git revert コマンド) を元に戻すことができます。
• revert 修正と「元の設計」が実装されたら、通常のリリース プロセスに従ってリリースするだけです。

私の理解によれば、投稿者が言及した「独自の機能」と「改善策」は通常のコードの提出です。投稿者が混乱しているのは、一時的な解決策が最終的に破棄される (ロールバックされる) という問題にどう対処するかということなので、上記の git revert コマンドを使用することで投稿者の期待は満たされるはずです。これにより、コード ベース上のすべての操作をトランク (マスター、開発) に確実に記録できるだけでなく、複雑なブランチ モデルなどの問題も回避できます。

---

さらに、投稿者が使用した分岐戦略が @rsj217 が言及したワークフローに従っているかどうかはわかりません。開発がすべての開発者にとってメインの開発ブランチである場合、開発は未完成の機能を受け入れずに直接送信する方が良いと思います。日々の開発作業、特に複数の機能/ブランチの並行開発の場合、複数の機能ブランチが相互に干渉することを回避できます。
元の投稿者の質問に戻りますが、この使用できないデザインは引き続き開発でき、開発にマージすべきではありません。このブランチに基づいて、修正機能の開発ブランチをチェックアウトします。テストが完了したら、開発ブランチをマージしてリリース プロセスに入ります。次のマージと元に戻す提案は依然として必要です。必要な場合を除き、プロセスに違反したり特別な処理を実行したりしないでください。これにより、すべてのコードのコミット操作が保持されます。

Answer 5

git ワークフロー マスター マスター ブランチを参照することをお勧めします。 開発は開発に使用されます。 リリースは、新しいバージョンのリリースに使用されます。 ホットフィックスは、オンラインのバグやその他の緊急操作を修正するために使用されます。

Answer 6

改善策ブランチがdevelop1であるとします。オンラインになった後、develop1とmasterがマージされて新しいマスターになります。元の機能ブランチdevelopが成熟して安定した後、それを新しいマスターにマージします(競合する可能性が非常に高くなります)。 )、develop1 のブランチを新しいマスターにマージし、その部分を削除すると、テストは問題なくオンラインになります。少し面倒で、少し愚かかもしれませんが、git がマージするたびに新しいポイントが前方に生成され、開発が安定するのを待ってマスターをロールバックしたい場合は、途中に他のリリースがある場合は実行されます。すぐに何かを失いますか？
もっと良い方法があるかもしれません、参考までに

Answer 7

「成功した Git ブランチング モデル」を読むのが難しい場合は、Juven Xu による「成功した Git ブランチング モデル」の翻訳を読むことができます

Answer 8

git-flow を使用すると、簡単なコマンドを使用してブランチを作成して完成させることができます。そして、標準化されたリリース、ホットフィックス、機能のワークフローがあります