複数の安定したブランチを持つgitワークフロー、svnと同期

Question

私たちのプロジェクトはconvertedからsvnからgitです。開発者は現在git-svnを使用していますが、 に移動して、ボンネットの下でより多くの電力を利用できます。ウィッシュリスト：リリースのメインラインとステージング作業の間

• 強力な分岐、例えばトピック/機能ブランチは
• 分離、並行して、時には複数の。
• lean &平均的で安定したJenkins-CIセットアップ - 最小限のメンテナンス（各リリース後のジョブ設定の変更対）
• 短い反復、開発チームは2週間ごとにQAにリリースします。独立してリリースされた同じソースから構築された複数の製品（P1..P3）;必ずしも外部にある必要はありません
• さまざまな圧力で
• "より良いチーム"のよりカジュアルで、非gitのユーザーを持って...彼らはS&U :)ですが、私たちは彼らに少なくとも1つのブランチ（トランク）へのアクセスをsvn与える必要があります。彼らの貢献はいくつかのディレクトリに制限されているので、ここではリスクはほとんどありません。

以下の戦略が有効ですか？

1. 開発：開発が起こるメインラインのブランチ、a'laのgitのフロー
2. 安定した製品の支店：製品1 ... product3を。これらのうちの1つ以上が、開発者リリース時にメインラインからマージされます。 gitの流れでは 'release start 1.4.3'と似ていますが、これらは永続的な分岐になります。リリースはここでタグ付けされ、その後統合されて開発されます。この点は、git-flowのマスターのように安定していて、いくつかのものだけです。
3. git-svnを直接使用するのを止めてください。代わりにミラーにプッシュ/プルしてください。必要に応じて機能ブランチを使用することもできます。
4. merge svn/trunk - > develop。 Svnは時折、孤立したチェックインを受けるでしょう。ジェンキンスの仕事によって自動化する計画を立て、失敗した場合に手動でマージできる人に通知する
5. merge development-> svn/trunk：定期的に（たとえば毎日）、バッチモードで。これはおそらく最も初心者のための部分です（少なくとも初心者向け）。それはうまく説明し、自動化されています、主として - rebase or some reset wizardy
6. CIのセットアップのようなものを計画することは簡単になり、例えばテストとDEVは、メインラインをオフに構築し、正式な製品は、独自の製品の枝

Git-Flow魅力的ですオフに構築します。しかし、私の場合は完璧なマッチのようには見えません。主に潜在的に並行リリース、複数の製品ライン、およびCI aspectsが原因です。

ご意見をいただければ幸いです。

Answer 1

いったんgitに変換すると、SVN用にいくつかのブランチを設定するのがかなりハッキーになります。私はそれらの "ユーザー"が学ぶべきか、または遠ざかるべきだと主張します。 gitの機能がより良いブランチ管理を行うために必要な場合は、S &に関係なく適切なソリューションです。

複数の本番リリースを管理するという点で、 Net-SNMPは非常にうまく機能します。我々は何年もの間維持されている数多くのプロダクションバージョンブランチを持っているので、パッチを追跡することは常にSVNの下で苦労していました。私たちの新しいWorkflowの下では、私たちははるかに幸せであり、一般的には、実際にマージするために、ブランチや別のパッチにパッチをドロップしなかったという感情を十分に持っています（SVNでは、 ）。