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

Question

目前开发的项目采用git作为版本管理工具， 平时开发有两个分支，develop和master 在develop上开发， 在master发布正式版本。 目前有这样一种情况： 有一个设计好的功能，由于种种原因，在develop分支上开发完成后...

我想大声告诉你 · Answer

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< にマージします。 /code> そしてオンラインにします🎜
feature/aaa の開発を続け、最後にそれを develop、master にマージします🎜

PHP中文网 · Answer

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 します。 > オンラインにします。

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

PHP中文网 · Answer

リーリー

phpcn_u1582 · Answer

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

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

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

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

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

怪我咯 · Answer

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

高洛峰 · Answer

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

我想大声告诉你 · Answer

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

巴扎黑 · Answer

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

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

全員に返信(8)返信します