私は最近 git ワークフローを調べていて、どれが私たちのチームに最適かを調べています。
私たちが使用できる最高の(または最高の 1 つの) git ワークフローは何でしょうか? このワークフローは、次の点の一部/ほとんど/すべてを尊重する必要があります。
- 2 つのチーム (それぞれ約 8 人) が git を使用し、両方とも同じアプリケーションで作業します。各チームには、プライベート リポジトリがある場合とない場合があります。
- アプリケーションにはいくつかのバージョンがあります。バージョン (n+1) の開発の開始は、バージョン (n) のリリース前に開始される場合があります。バージョン (n+1) の開発は、バージョン (n) に含めるべきではありません
- クライアントは、前の月に開発された次のリリースに機能 x を含めないことを土壇場で決定する場合があります。
- プロジェクトの歴史は理解しやすいものでなければなりません。
私のワークフローのアイデア: ここにあるものとは少し異なるワークフロー: http://nvie.com/posts/a-successful-git-branching-model/
- SSH で利用できる、2 つのチーム用の 1 つの中央リポジトリ。
- 支部長安定です。
- ブランチ開発は作成されません。代わりに、アプリケーションの各バージョンには独自のブランチがあり、チームはそれらで開発します。バージョン (n+1) のブランチは、バージョン (n) のブランチから作成されます。したがって、ブランチ (n) でバグ修正が行われている間に、ブランチ (n+1) で新しい開発が発生する可能性があります。
- モデルのように、新しい機能とバグ修正ごとにブランチが作成されます。
- チームごとに 2 つのメイン リポジトリを使用するのは簡単ではないように思われるため、両方のチームに 1 つの中央リポジトリのみを使用します。チームごとに 2 つのリポジトリを使用するワークフローはどのようなものでしょうか? それだけの価値はありますか?
- 早送りが発生した場合、機能 x が含まれないようにする方法がないように見えるため、ほとんどの (すべてではないにしても) マージは早送りしないでください。
- リリース時に、バージョン (n) をマスターにマージし、タグを付ける
また、この戦略では支店が多すぎませんか? リリース後、簡単に約 30 ~ のバグ修正が行われる可能性があります。バグ修正ごとにブランチを作ると、あっという間にたくさんのブランチができてしまいます。それを避けるための解決策はありますか?
パッチワークフローは良いアイデアでしょうか? どうなり得るか?すべてのバグ修正と機能に独自のパッチがあり、クライアントが必要なものを選択できるようになると思います.
お手伝いありがとう。