0

エージェンシーでの git 開発プロセスの適切なワークフローを見つけるのに苦労しています。

私たちの状況にかなり合っているように見えるので、git flow を使用したいと思います。このアプローチに関する私の問題は次のとおりです。

機能 a と機能 b の開発を開始します。両方とも個々の機能ブランチ内にあります。機能の作業が完了すると、それらは開発にマージされます。ここで、QA を担当するクライアントが、develop ブランチがチェックアウトされているテスト サーバーを調べます。

クライアントは次のように判断します: 機能 b は公開できますが、機能 a は再度作業する必要があります。

機能 a の開発によって行われた変更を元に戻し、機能 b をデプロイするにはどうすればよいでしょうか?

また、マージして開発する前に、個々の機能ブランチで QA を行うことも考えました。しかし、それがこの問題に対処する良い方法かどうかはわかりません

そのような問題のベストプラクティスはありますか?

4

1 に答える 1

0

通常、ブランチ開発はそのままでは稼働しません。

開発の機能はマージされているか、（特定のケースでは）本番ブランチでチェリーピックされています。

私が1年以上成功裏にフォローしてきたスキーム：

  • master - 開発ブランチ、クライアント アクセスなし (注目に値する - 小さな機能リクエストとマイナーなバグ修正は、機能ブランチなしで master で直接行われます。あなたのケースではないかもしれません)
  • stage - ステージング ブランチ、クライアント QA、マスターから派生
  • プロダクション - ライブ アプリ リリース
于 2013-06-18T18:53:36.920 に答える