0

私は Git についてかなり研究してきましたが、小さなチームのワークフローに Git がどのように適合するかを除いて、基本的な概念は理解できました。

私が理解しているように、私は欲しい：

  1. 私と私のチームが作業 (変更をローカル コピーにプル) し、機能をテストするための 1 つの共有半公開レポ。

  2. テスト済みですぐに使用できるものをすべてプッシュする 1 つのレポ。

  3. 作業ディレクトリが実際の Web サイトのルート フォルダーであるライブ リポジトリ

私はこれを理解していますか、それとも必要以上に複雑にしていますか? 私の心を包み込もうとしているだけで、このトピックについて詳しく説明しているチュートリアルはほとんどありません.

4

3 に答える 3

0

適用できる git ワークフローは多数ありますが、開始点が必要な場合は、ブランチを通じてアプリケーションの変更を集中管理する優れた方法を説明しているnvie ブログ投稿をお勧めします。

詳しくはhttp://progit.org/book/ch3-4.htmlをご覧ください。

また、誰かがすでにこれについて質問しているようです:小さな開発チームのための Git ブランチ戦略

于 2012-04-24T17:51:14.400 に答える
0

開発/リリース/... に複数のリポジトリを使用する代わりに、1 つのリポジトリでブランチを使用します。

そのための可能なモデル (およびチームでの使用方法) に関するその他のアイデアは、次のブログ投稿で見つけることができます: http://nvie.com/posts/a-successful-git-branching-model/

(心配しないでください。上のグラフは複雑に見えますが、記事を読むだけで非常に明確になります :) )

無関係なメモ: Git は非常に強力で、多くのことに適していますが、使用が非常に複雑になることもあります (カーネル ハッカーによって作成されたバージョン管理システムに期待されるものとまったく同じです;D)。

分散型 VCS の場合、Bazaarが良い代替手段になるかもしれません。重要なアイデアを git と共有します。しかし、コンピューター サイエンスのバックグラウンドがなく、おそらく初めてバージョン管理を使用するチームにとっては、扱いがはるかに簡単になる傾向があると、さまざまな人から繰り返し聞いています。

(あなたの基準に合致する場合に備えて。私はあなたのチームを知りません。人々のバックグラウンドと経験の範囲は Web 開発において非常に幅広いです。ここでも VCS フレームワークを開始したくありません。)

于 2012-04-24T17:58:36.173 に答える
0

私の開発チームには、すべての変更がプッシュされるリモート リポジトリが 1 つしかありません。

開発中の機能は、マスター コピーの破損を避けるために分岐されるため、同時に複数のアクティブな分岐が存在する場合があります。各開発者は、開発サーバー上で実際に実行されている「ローカル」レポを持っています (私たちは SSH 経由で VIM を使用して開発を行う傾向があります)。各「ローカル」リポジトリは、ユーザーの名前でタグ付けされた一意の仮想ホストとして設定されます。その結果、開発サーバーで実行されているサイトの 3 つまたは 4 つの異なるバージョンが存在する可能性があります。これにより、開発者はコードの変更を即座にテストできます。

リリースの準備をするとき、完成したすべてのブランチがマージされ、結果のコードが git を介して、本番環境とほぼ一致するデプロイ前サーバーにプルされます。承認後、特定のコミットはバージョン番号でタグ付けされ、git を使用してプルされるか、実稼働サーバーに再同期されます。そこで、デプロイがスムーズに行われたことを確認するためにさらにいくつかのテストが行​​われます。

于 2012-04-24T17:48:46.313 に答える