私のdvcsワークフローを理解する
Mercurialをバージョン管理システムとして使用して、新しいプロジェクトを構築します。
私はまだ私のワークフローがどのように見えるべきかを完全に理解しようとしているので、私が理解するのに助けが必要なケースを以下にリストしました。
複数のモジュールを持つ単一のアプリケーション（各モジュールは独自のリポジトリでホストされています）複数の開発者が同じモジュールに変更を加える必要があります。これはどのように管理する必要がありますか？
- Hgプルが実行され、すべての変更がローカル開発者のマシンで行われる必要があります。これらの変更が行われると、変更はdevにプッシュされます。
- 各機能/バグ修正がサーバー上に新しいリポジトリまたはブランチを取得し、開発者が変更をローカルhgからリモートhgにプッシュする必要があります。機能が完了すると、そのリポジトリ/ブランチは開発にマージされます。
- または両方の組み合わせ。小さな変更は直接開発に反映され、時間がかかる可能性のある機能には独自のブランチ/リポジトリがあります。
- または、より適していると思われるその他の戦略。
チェンジセットの概念はあなたのためにそうするようなものなので、チェンジセットごとに個別のリポジトリ/ブランチを作成する必要はありません。
私は主要な機能にブランチを使用していますが、ブランチが役立つ主な目的は、「hgupbranchname」または「hgupdefault」をすばやく簡単に実行して、新しい機能での作業とバグ修正での作業を切り替えることができることです。現在のコードベース。
「または両方の組み合わせ。小さな変更は直接開発に反映され、時間がかかる可能性のある機能には独自のブランチ/リポジトリがあります。」
これは完全に適切なオプションです。
開発者間でチェンジセットを共有するために「hgserve」を使用することもできることを忘れないでください。
提案：各モジュールが別々のリポジトリにあるのはなぜですか？それらは、完全に別個のリポジトリが必要になるほど十分に独立していますか？
複数の人が同じモジュールで作業するシナリオでは、一般的なDVCS方法論に従う必要があります。作業し、おそらく多くのコミットを行い、1日の終わりに、開発から変更をプルしてマージし、最後に開発にプッシュします。
まず、モジュールはプロジェクトに依存しませんか？そうでない場合は、サブリポジトリの使用を避けることを検討してください。サブリポジトリは最後の手段の機能と見なされます。
第二に、クローンに夢中にならないでください。ブランチを作成する代わりにそれを使用する人もいます（ dvcs-は一般的なワークフローの「クローンからブランチ」ですか？ を参照）。 Rhodecodeやなどのリポジトリ管理ソフトウェア/サービスを使用することをお勧めします Bitbucket、そして各開発者にこのワークフローに従うためのパブリックフォークを持たせます：
私はローカルリポジトリを持つのが好きですが、バックアップを忘れないでください。バックアップなしで1台のコンピューターに多くの作業を残したくありません。ただし、自分のリポジトリがあると、自由に試してみることができます。
小さな変更が何も壊さない限り、小さな変更を開発に戻すことができます。 （継続的インテグレーションと自動テストスイートがここで役立ちます。）それらがマイナーなコードの改善またはバグ修正である場合は、他の人がそれらを自分のリポジトリにプルできるようにする必要があります。