私たちの仕事のやり方に合った Mercurial ワークフローを見つけるのに苦労しています。
私は現在、機能ごとのクローンを支持していますが、これは Subversion からの考え方のかなりの変化です。また、環境のセットアップにかかる現在の費用にも問題があります。
hg pull --rebase を使用すると、Subversion に似たワークフローが得られるように見えますが、いろいろ読んでみると、使用には慎重です。
私は概念を理解していると思いますし、歴史を書き直すことは理想的ではないことがわかりますが、私が個人的に容認できないと考えるシナリオを思い付くことができないようです.
hg pull --rebase が理論的または経験的に作成できる「最悪の」シナリオは何かを知りたいです。歴史を「書き換えるべき」かどうかについての意見ではなく、具体的な例が欲しいです。私は人々が意見を持っていることに反対しているわけではありませんが、インターネット上では多くの意見が表明されているように見えますが、それらを裏付ける例はあまりありません ;)
新しい Mercurial への改宗者が最初に学ぶ必要があるのは、不完全なコードをコミットすることに慣れることです。Subversion は、壊れたコードをコミットしてはならないことを教えてくれました。今こそ、その習慣を忘れる時です。頻繁にコミットすると、ワークフローの柔軟性が大幅に向上します。
私が見てhg pull --rebaseいる主な問題は、元に戻す方法がなくてもマージを中断できることです。DVCS モデルは、履歴を明示的に追跡するという考えに基づいており、リベースは、実際には同時に作業していたにもかかわらず、私の変更はすべてあなたの変更の後に行われたと言って、その考えを覆します。そして、あなたの変更が何であるかわからないため (以前の変更セットに基づいてコードを作成していたため)、あなたのコードに加えて私のコードが何かを壊さないかどうかを知ることは困難です。また、リベースによって分岐機能が失われます。これは、実際には DVCS の背後にある全体的な考え方です。
私たちのワークフロー ( Mercurial ホスティング システム全体を構築してきました) は、複数のクローン、またはブランチ リポジトリを維持することに基づいています。各開発チームまたは小規模チームには、「中央」リポジトリの単なるクローンである独自のブランチ リポジトリがあります。すべての新機能と大規模なバグ修正は、個人のブランチ リポジトリに移動します。そのコード ピアをレビューしてもらい、準備が整ったと判断されたら、それを中央レポジトリにマージできます。
これにより、いくつかのメリットが得られます。まず、私の変更はすべて「準備が整う」まで独自のリポジトリにあるため、ビルドを壊すことはありません。第二に、別の機能を実行する必要がある場合、または次のメジャー バージョンのように実行期間が長い場合は、別のブランチ リポジトリを作成できます。そして 3 つ目は、すぐに修正する必要があるバグが発生した場合に、中央リポジトリに簡単に変更を加えることができることです。
とはいえ、このワークフローを使用する方法はいくつかあります。最も単純で、私が始めたのは、個別のクローンを保持することです。website-central、などがありますwebsite-tghw。特に、それらの間をローカルでプッシュおよびプルできるため、うまく機能します。最近では、remotebranches拡張機能を使用してそれらを管理し、一度にすべてをプッシュしないようにhg nudgeを使用して、複数のヘッドを同じリポジトリに保持し始めました。
もちろん、このワークフローをあまり好まない人もいます。通常、Mercurial サーバーではサーバー側のクローンを作成するのが難しいためです。その場合、名前付きブランチを使用して、機能をまっすぐに保つことも検討できます。残念ながら、それらは Git ブランチほど柔軟ではありません (これが私たちがブランチ リポジトリを好む理由です) が、ブランチを閉じる方法と、ブランチを開始すると実際にそれらを取り除くことができない理由を理解すれば、うまく機能します。
これは少し長くなるので、Mercurial が (SVN を介して) 提供する優れた分岐とマージを採用することをお勧めして、最後にまとめます。確かに学習曲線はありますが、コツをつかめば、物事は本当に簡単になります。
質問のコメントから、根本的な問題は、開発者が一度に複数の機能/バグ修正/問題に取り組んでおり、作業ディレクトリにコミットされていない作業と、中央リポジトリにプッシュバックする準備ができているいくつかの完了した作業があることです。
問題をうまくカバーし、多くの前進につながる本当に素晴らしい交換があります.
http://thread.gmane.org/gmane.comp.version-control.mercurial.general/19704
マージを処理する別のクローンを用意するなど、コミットされていない変更を維持する方法はありますが、私のアドバイスは、分散型の作業方法を採用し、好きなだけコミットすることです。プッシュする前に、最後のいくつかのローカル コミットを (たとえば MQ を使用して) 単一の変更セットに結合します。