35

プルリクエストをデフォルトで機能ブランチから開発にマージさせたいです。

私はgitフローの使用を提唱しているので、機能のプルリクエストが送信されると、プルリクエストはマスターではなく開発にマージされる必要があります。

一部のマネージャーは、人間であるため、チームリーダーがその事実を見逃し、プルリクエストを誤ってマスターにマージして、後でリリースに問題を引き起こす可能性があるとコメントしました。

マージ地獄のリスクを軽減したいので、これはこの目標を達成するのに大いに役立ちます。

編集:私はhubflow(http://datasift.github.com/gitflow/)と呼ばれるgitflowのフォークを使用しています。デフォルトでは、機能ブランチが作成されると git hf feature start [tik-123] 、機能ブランチは仕様ごとに作成されますが、元の場所にプッシュされます。コラボレーションのためにこれが欲しいです。機能が完了すると、開発者はgithubの機能ブランチに移動し、プルリクエストを発行します。次に、チームリーダーはプルリクエストを確認し、機能がスプリントでリリースされる予定の場合は、機能を開発にマージします。

4

4 に答える 4

34

developまたは、プロジェクトにアクセスしたときに誰もが見るデフォルトのブランチを作成します。欠点は、それを複製した人は誰でもデフォルトで不安定なブランチを取得することですが、すべてのプル リクエストはデフォルトで開発ブランチにも送られます。

于 2013-02-13T16:35:17.283 に答える
10

masterdevelopブランチを使用する代わりに、とを使用stablemasterます。

次に、通常、新しいバージョンにタグを付ける前にそれらをマージすることをお勧めします。そのため、流用はまったくないか、ほとんどありません。私はこのスキーマを使用しており、通常は少し遅れてstable続きmaster、マージはほとんど早送りです。

ブランチをデプロイ可能に保つmasterには、準備ができたら機能ブランチをマージします。ただし、stableブランチがあるため、新しい機能を十分にテストする必要はありません。

于 2013-02-13T16:33:33.393 に答える
5

github にはgithub flowと呼ばれる独自の推奨ワークフローがあり、慣例により、すべてのプル リクエストはデフォルトですがmaster、好きなブランチに編集できるようになりました。

于 2013-02-13T16:27:13.000 に答える