0

最近、SCM ソフトウェアの使用を開始することを決定し (おそらく、かなり前から使用していたはずです)、Mercurial を試すことにしました。私が見つけた限りでは、Git よりも Windows の方が優れていると思われます。また、コマンド ラインの代わりに TortoiseHG を使用することも計画しています。私はまだ学習の初期段階にあり、相反する答えを見つけ続けている質問があります。

Apache サービスの PHP サイトがあります。将来サーバーを適切に仮想化できるようになるまで (開発者ごとに 1 つ)、各開発者の作業コピーを異なるポートに配置する予定です。新しい開発を続けている間、「安定した」ビルドのためにブランチ/タグ/何かを保持したいと思います。もちろん、バグ修正があればすぐにプッシュしたいのですが、開発ブランチにマージしたいとも考えています。

リポジトリのクローンを作成し、クローンに変更を加え、完了したらマージする必要があると聞いたことがあります。

また、ブランチを使用し、完了したらブランチをマージする必要があるとも聞きました。

リポジトリの場合、apache はどうしますか? 新しい機能を追加するたびに、別のディレクトリを指すように再構成する必要があるのは面倒です...

皆さんがこれを照らすことができる光をありがとう。助けてくれてありがとう！

これについてどうすればよいでしょうか？

[編集] あと、HGの「棚」「パッチ」って何？ダブルありがとう。

4

1 に答える 1

1

分散リビジョン管理システムでは、中央サーバーはなく、各「クローン」にはリポジトリ全体のコピーがあります。変更はローカル リポジトリで行われ、後で変更セットが他のリポジトリにプッシュ (またはプル) されます。したがって、実際にはすべてのクローンはブランチであり、すべての「コミット」はマージです。

以下にワークフローの例を示します。私が書いたことのより詳細な説明については、この記事(編集:リリース管理についてのこの記事を意味していましたが、他の記事も役に立ちます...)とこの短い Mercurial の概要を参照してください。

すべての開発者からのすべての最新情報を含む「メイン」リポジトリがあるとします。それを（1回）クローンして、「本番」リポジトリを作成できます。その後、最新の安定したリビジョン (タグを使用してマークされているはずです) に更新します。

また、開発者ごとに再度クローンを作成し (繰り返しますが、クローンは 1 回だけ行います)、相互に独立して動作させることもできます。(コミットはローカル リポジトリにのみ影響するため) 自由にコミットでき、理想的には、変更セットが安定している場合にのみ変更セットを "main" にプッシュする必要があります。他の開発者から変更セットをプルすることもできますが、マージをすぐに実行するかどうかは開発者次第です。「メイン」に安定したリリースがある場合は、そのようにタグ付けする必要があり、「プロダクション」はプルしてそのリビジョンに更新できます。

製品バージョンでバグが発見された場合、開発者は次のことができます。a) 現在の作業ディレクトリをコミット (またはシェルフ) します。b）作業ディレクトリを「本番」が実行されているのと同じリビジョンに更新します。c) バグを修正し、変更をコミットしてプッシュします。d) 彼が去った場所に再び更新し、通常どおり作業を続けます。新しいチェンジセットは、「プロダクション」がプルして更新するために利用でき、すべての開発者がそれを現在のリビジョンにマージすることもできます。

各作業コピーに固有のもの (ポート番号、データベース インスタンスなど) については、それらを別の構成ファイルに保存し、このファイルを無視する必要があります。このように、バージョンを変更しても、これらの値は個々の開発者と本番インスタンスで同じままです。

于 2012-07-11T02:48:32.653 に答える