3

チームで Git Flow を使用しています。私たちは皆、機能の開発から分岐し、コード レビュー後に再びマージします。これは私たちにとってはうまく機能しますが、開発者が完了するまでに 1 か月以上かかる機能が 1 つあります。この間にいくつかのリリースがあります。

これを促進するためのいくつかの質問：

  • これをどのように処理する必要がありますか？
  • このように処理する必要がありますか？
  • それとも、機能をより小さなマージ リクエストに分割する必要がありますか?
  • それを切り刻む場合、それが公開プロジェクトである場合、この機能の一部が進行中のリリースに影響を与えないようにするにはどうすればよいでしょうか?
  • この長期的な機能ブランチへの開発のマージは本当に悪いことですか? 私の同僚は、それがアンチパターンであることを懸念しています。
  • この長期的な機能に一貫して開発をマージしなければ、機能が最終的に完成したときに悪い結果が生じる可能性はありますか?
4

3 に答える 3

2

強いスタンスであなたの質問に答えることはできませんが、gitflow に関するブログ記事を紹介することはできます。

上部近くの画像に注目してください。これは、将来のリリースの機能 (したがって、長期的な機能) を示しています。

これは、状況がそれを必要とするときに必要な適切な行動であると私に信じさせます.

于 2015-11-06T16:06:42.010 に答える
1

以前の会社では、ブランチの少なくとも 3 分の 1 が、少なくとも 2 週間以上の「長期運用」でした (1 か月間開発されるブランチはかなり一般的な場所でした)。そのためにも gitflow パターンを使用しました。基本的には、ブランチで作業し、定期的にプル開発し、その上にブランチをリベースします。これは、アンチパターンと見なされている機能ブランチに開発をマージすることにかなり似ています。

本当の鍵は、ブランチのメンテナンスと、遅れをとりすぎないことでした。古くなったブランチは、時々更新しようとするのが最も苦痛です。他の優先事項の中で、ブランチについていく時間があるかどうかを考慮する必要があります。

テスト/環境のセットアップも重要です。長期間実行されているブランチを持つことは、おそらく重要な機能/変更であることを意味するため、おそらくそのようにもテストされるでしょう. QA 担当者 (チームでも、自分自身と他の開発者でも) が、分離された環境でブランチの準備が整ったときにブランチをテストできる場合、それは非常に役立ちます。

于 2015-11-06T16:31:59.897 に答える