4

私は 7 人のプログラマーがいる小さな開発オフィスで働いており、現在 Git バージョン管理を実装しています。以前はバージョン管理システムがありませんでした。遅刻しないよりはましですよね？

そうは言っても、次の構造を実装することを考えています。

開発サーバー

  • メイン リポジトリ - 開発の安定版
  • 開発者リポジトリ - 開発者ごとに 1 つの開発リポジトリ

テストサーバー

  • メイン リポジトリ - 安定したテスト バージョン。変更はメインの開発リポジトリからプッシュされます

本番サーバー

  • メイン リポジトリ - 変更はメインのテスト リポジトリからプッシュされます

この構造は適切ですか、それとも分散バージョン管理システムのポイントを見逃していますか? 誰かが私にいくつかの指針や実用的な例を教えてもらえますか?

編集1:

皆さんのフィードバックに感謝します - 物事がより明確になりました. 開発者リポジトリ(ローカル)、開発 (ベア) リポジトリ、テスト リポジトリ、本番リポジトリなどの構造がより論理的な選択であることは理解しており、一部の人が開発リポジトリを不要なステップと見なす理由も理解できます。

いくつかのテストを行って、どの構造が最も好きかを確認すると思います。ありがとう

4

3 に答える 3

4

これは多かれ少なかれそれについてです。ただし、これらは注意する必要があるものです。

  • 開発サーバーの「メインリポジトリ」をベアリポジトリにします。
  • 開発者はサーバー上に自分用のリポジトリを持っている必要はありませんが、自分のコンピューター上にローカルにメインリポジトリのコピーを持っています。
  • すべての開発者は、メインの開発リポジトリからフェッチ/マージし、プッシュバックする前に競合を解決する必要があります。
  • テストサーバーと本番サーバーにプッシュしないでください。これらのリポジトリから、開発サーバーとテストサーバーからそれぞれフェッチしてマージします。これは、これらのリポジトリがむき出しではなく、実際には独自のコミットを持っている可能性があるためです。
  • テスト/本番サーバーから変更をフェッチする責任を1人（または開発者の1人）に持たせ、それらを現在の安定版とマージして、メインリポジトリにプッシュします。このようにして、テストサーバーのバグ修正が開発にマージされます。
于 2012-07-20T10:17:01.633 に答える
1

これが私が提案するものです：

  • 一部のサーバーに裸のリポジトリを用意します。誰もがプッシュ/プルするレポです。あなたはそれで働きません。集中型 SCM 上のサーバーと見なすことができます。
  • 開発サーバーを用意する必要はありません。各開発者は、自分のローカル コンピューターに自分のリポジトリのコピーを持ちます。
  • テスト サーバーには、リポジトリのコピーがあります。作業はすべてコンピューターから行われるため、通常はプッシュする必要はありません。
  • 同じことが運用サーバーにも当てはまります。

Git の使用方法、別名ワークフローについては、この回答で説明した基本的な方法をお勧めします。

于 2012-07-20T11:53:23.773 に答える
0

開発サーバー

メイン リポジトリ - 開発の安定バージョン 開発者リポジトリ - 開発者ごとに 1 つの開発リポジトリ

各開発者がサーバー上に独自のレポを必要とするとは思いません。リポジトリを自分のコンピューターにクローンするだけです。

また、すべての開発者がメイン リポジトリにプッシュできるようにする必要はありません。チーム リーダーのみがメイン リポジトリへのプッシュ アクセスを持つ必要があります

于 2012-07-20T12:23:55.503 に答える