2

2 人目の開発者を雇ったばかりなので、Web ファイルの管理に GIT を使用することを検討しています。

GitHub は使用しませんが、NAS ドライブ (共有ドライブ) があるため、最初の考えは次のような計画です。

  • DVCS (ルート)
    • マスター (NAS)
      • プロジェクト1
      • プロジェクト 2
    • 開発者1 (NAS)
      • プロジェクト1
      • プロジェクト 2
    • 開発者2 (NAS)
      • プロジェクト1
      • プロジェクト 2
    • developer1 (ローカル ワークステーション)
      • プロジェクト1
      • プロジェクト 2
    • developer2 (ローカル ワークステーション)
      • プロジェクト1
      • プロジェクト 2

したがって、基本的に各開発者は、マスター プロジェクト リポジトリを開発者リポジトリ (品質管理) に複製し、次にこの開発者リポジトリをローカル リポジトリに複製します。彼らは変更/編集を行い、上級開発者が承認できるように、これらの変更をコミットして開発者リポジトリにプッシュします。彼らがこれを行うと、マスターにプッシュされます。

これが正しいアプローチなのか、ブランチを使用する必要があるのか​​ 、それとも別のワークフローが必要なのかわかりません。

4

1 に答える 1

1

この質問に対する「正しい」答えはありません。適切なワークフローとは、あなたとあなたのチームにとってうまくいくものです。

そうは言っても、開発者が 2 人しかいなければ、ベア リポジトリが複数必要だと感じる理由がよくわかりません。この場合の最も簡単な方法は次のとおりです。

  1. NAS に 1 つの中央リポジトリを用意します。

    • 開発コードを統合するためのマスター ブランチ。
    • 開発者が master にマージするトピックに取り組むフィーチャー ブランチ。
    • 開発者がバックアップやチェリー ピッキングのためにプッシュできるが、リベースや強制プッシュは自由に行えるユーザー プライベート ブランチ。
    • モデルに適合する場合、リリースされたコードの安定したブランチ。一部のショップでは、継続的な配信を行う場合、マスターのタグだけが必要です。

  2. 開発者は、ネットワーク ドライブではなく、ワークステーションにクローンを保存します。

    • NAS がデータを失ったり、オフラインになったりした場合の冗長性を提供します。
    • 中央に保存されていない、またはプロジェクト履歴の一部にされていない使い捨てブランチを許可します。

小規模なチームは通常、プル リクエスト モデルの複雑さを必要としません。あなたのマイレージは異なる場合があります。

于 2012-06-19T15:54:36.253 に答える