2012-12-14 5 views
7

私のチームにGitフローを導入しようとしています。私たちはかなり小さいチームであり、非常に機敏です。 1日に1回リリースしたいと考えています。これは、その日のすべての変更をテストするための時間が限られていることを意味します。ビジネスチームは、理想的ではありませんが、リリースされる機能を制御できるようにしたいと考えています。選択した機能を解放するgit flow

これは非常にうまくいきません。リリースブランチをカットしてから、選択した機能をマスターにマージする最良の方法を開発します。チェリーは唯一の選択肢ですか?より良い方法がありますか?

答えて

7

標準git flowビジネスチームが次のリリースにある機能を制御したい場合、処理は理想的ではありません。しかし、他の分岐機構でも同じ問題があります。

git flowのデフォルトの構造は、新しい機能ごとに機能ブランチを作成することです。新しいフィーチャーの構築(およびテスト)が完了したら、ブランチを開発ブランチにマージしてから、フィーチャーブランチを削除します。その後、この機能は次のリリースに含まれます。

次のリリースに機能を含めるべきでない場合、機能ブランチを開発ブランチにマージするべきではありません。それが含まれないことを確認する最善の方法です。また、他の開発者が新しい機能を使用するコードを作成することもできません。

チェリーピッキングをおすすめしません。まず、フィーチャーは複数のコミットを持つことができます(しばしばそうなります)、それを忘れるのは簡単です。第2に、機能Bが機能Aで追加されたコードを使用し、管理者が機能Aをリリースせずに機能Bをリリースしたい場合、機能Bが壊れている可能性があります。これらの依存関係は必ずしも見つけにくいものではありません。

管理者は新しい機能の優先順位付けを望んでいますが、各機能は開発完了後すぐに開発ブランチにマージする必要があります。

0

各機能に独自の分岐がある場合は、その機能分岐をマージするだけです。

+0

えええええええええええええええええええええええええええええええええええええええええええええええええええええええええええ、どうしてこの機能をお使いになっているのですか? – pal4life

+0

'git checkout master; git merge feature1 feature2 feature3 feature4' - それは必要なものではありませんか?それらのブランチをマージして、どの機能をリリースするかを選択します。マスターブランチにマージされていない機能はリリースしません。 – aragaer

+0

したがって、リリース予定の機能をマスターでマージし、フィーチャーブランチ内でのみリリースされない機能を残しておくことをお勧めしますか? – pal4life

関連する問題