1

互いに依存している 5 つの git プロジェクトがあるとします。

  1. データベース (以下のサーバーと通信)
  2. レンダリング サーバー (以下のサーバーと通信)
  3. メイン アプリケーション サーバー (REST API)
  4. 起動: 上記の Amazon 4 EC2 マシンを構築するためのスクリプトと json。
  5. テスト: App Server で実行
  6. Javascript API (REST API に依存)
  7. JS および REST API ドキュメント (REST API に依存)

上記の git プロジェクト部門は、実用的な方法で並行ワークフロー編成に進化したと思います。

問題は、システム全体の成功は、上記の 7 つのプロジェクトが互いに一貫した状態で一貫していることを確認することにかかっているということです。

一方では、1 つのプロジェクトの time_1 SHA-1 ハッシュと同じプロジェクトの time_2 SHA-1 を比較することで、システム全体の変化を表す方が簡単に見えます。

一方、私はこれらのSOの回答を読みました。これは、あまりにも多くのプロジェクトをグループ化することの複雑さのコストについて言及しています。さらに、Linus は、さまざまなプロジェクトにブランチを使用することさえできる git システムの柔軟性と、後でグループ化戦略を切り替える機能についても言及しています (ただし、リスクを嫌う初心者なので、このアプローチは行いません)。

運用上のリスクが高く、専門的な経験が少ない企業を考慮したアドバイスやガイドラインをいただければ幸いです。

4

1 に答える 1

1

もう少し複雑ですが、「グループ化」戦略にはメリットがあり、試してみる価値があります。これはサブモジュール
と 呼ばれ、すべてのプロジェクトに対して 1 つの一意の参照を定義できると同時に、それらのプロジェクトを独立した git リポジトリとして管理できます。

「サブモジュールの本質」で説明したように、新しいサブモジュールの状態を親リポジトリに記録する限り、サブモジュールを変更できます。

于 2012-06-04T04:33:24.863 に答える