2

私たちのプロジェクトはsvn から gitに変換されました。開発者は現在 を使用してgit-svnいますが、ボンネットの下でさらに多くの機能を利用したいと考えています。ウィッシュリスト:

  • トピック/機能ブランチなどの強力なブランチ
  • リリースのメインラインとステージング作業の間の分離、時には複数の並行作業。
  • 無駄のない平均的で安定した Jenkins-CI セットアップ - 最小限のメンテナンス (各リリース後にジョブ構成を変更する場合と比べて)
  • 短いイテレーション。開発チームは 2 週間ごとに QA にリリースします。必ずしも外ではない
  • 同じソースから構築され、個別にリリースされた複数の製品 (P1..P3)。さまざまな圧力で
  • 「より大きなチーム」には、よりカジュアルな非 git ユーザーがいます...彼らはS&Uです :).. しかし、少なくとも 1 つのブランチ (トランク) への svn アクセスを彼らに与える必要があります。彼らの貢献はいくつかのディレクトリに制限されているため、ここでは衝突のリスクはあまりありません。

次の戦略は機能しますか?

  1. 開発: 開発が行われるメインライン ブランチ、git-flow 風
  2. 安定した製品ブランチ: product1 .. product3. これらの 1 つ以上は、開発リリース時にメイン ラインからマージされます。git flow の 'release start 1.4.3' に似ているようですが、これらは永続的なブランチになります。リリースはここでタグ付けされ、開発にマージされます。この時点で、git-flow の master のように、そのうちのいくつかだけが安定します。
  3. git-svn を直接使用するのをやめてください - 代わりにミラーにプッシュ/プルしてください。必要に応じて機能ブランチを使用することもできます
  4. svn/trunk をマージ -> 開発します。Svn は時折、孤立したチェックインを取得します。そのため、Jenkins ジョブによって自動化することを計画しており、失敗した場合は手動でマージできるように人々に通知します
  5. merge development->svn/trunk: 定期的に (例: 毎日)、バッチ モードで。これはおそらく最も不安定な部分です（少なくとも初心者にとって）。リベースやリセットウィザードのようなものを計画しています
  6. CI のセットアップは簡単です。たとえば、メインラインからのテストおよび開発ビルド、独自の製品ブランチからの公式製品ビルドなどです。

Git-Flowは魅力的です。主に、うまく記述され、自動化されているためです。しかし、私の場合には完全に一致するようには思えません。主に、並行リリースの可能性、複数の製品ライン、およびCI の側面が原因です。

情報に基づいたご意見をお待ちしております。

4

1 に答える 1

3

さて、gitに変換すると、SVN用にいくつかのブランチを設定するのはかなりハッキーです。私はそれらの「ユーザー」が学ぶか、去るべきだと主張したいと思います。ブランチ管理を改善するためにgitの機能が必要な場合は、S＆Uに関係なく適切なソリューションです。

複数の製品リリースの管理に関して、私が思いついたNet-SNMP用の非常にうまく機能するモデルを提供します。何年にもわたって維持されている製品版のブランチがいくつかあるため、SVNではパッチの追跡が常に苦痛でした。私たちの新しいワークフローでは、実際のマージのためにパッチをいくつかのブランチにドロップしなかったので、私たちははるかに幸せで、一般的に十分に良い気持ちを持っています（すべてのブランチに各パッチが含まれていることを手動で確認する必要があったSVNとは対照的です） ）。

于 2012-03-05T19:25:18.490 に答える