Mercurialを1年以上毎日使用した後、DVCSのより良いワークフローを見つけようとしています。 成功したGitブランチモデル に触発され、「毎日の作業をマスターリポジトリにプッシュし、リリースブランチを定期的に分岐する」ワークフローから「個別の機能ブランチで作業し、完成した機能をマージする」ワークフローに移行しますマスターに戻る」。
とにかく、Mercurialでのブランチとマージ(クローンを使用したブランチ)で私が抱えていた問題は、実際のマージプロセスです。追加のチェンジセットを生成するマージには問題はありませんが、問題は通常、元のチェンジセット+マージよりも多くの変更を含む大きなチェンジセットを生成することです。マージチェンジセットには、他のヘッドからのチェンジセットも含まれます。
そのため、最近マスターリポジトリからプルし、次に更新/マージし、最後にプッシュすると、これらの不要な大きなチェンジセットが作成されることに気付きました。
私たちがすべきことは、プル、アップデート、マージの代わりにリベースすることです。
現在、リベースは元々Mercurialの拡張機能でしたが、それでも拡張機能ですが、現在はMercurialディストリビューションと一緒に出荷されています。
他のスレッド、特に gitとMercurialの比較 をたどる場合、2つの最大の違いの1つは、gitがブランチをサポートしていないが、リベースをネイティブでサポートしているということです。 Mercurialには、リベース用のネイティブサポートはありませんが、ブランチをサポートしています。
ですから、私の質問は、機能ブランチを使用してより柔軟なワークフローを採用する必要がある場合、マスターブランチに混乱を引き起こさない、確実なブランチ/マージワークフローが必要です。マスターブランチは、Peachであり、実行されたマージ操作の追加のチェンジセットなしで、単一の機能を含むチェンジセットのみを含む必要があります。これはMercurialでリベースのサポートなしで実行できますか?
別の問題として、メインブランチにプッシュするときに、機能ブランチの複数のチェンジセットを単一のチェンジセットに集約する方法についていくつかの入力をお願いします。
私は Mercurialでの分岐に関するガイド を読みましたが、マージの容易さ、またはより具体的には、マージの結果がマスターブランチにコミットされる方法に関する賛否については触れていません。
機能ブランチに名前付きブランチを使用することを検討しましたか?この方法では、masterブランチがこれらのコミットによって汚染されない一方で、必要なだけコミットすることで機能を開発できます。機能の準備ができたら、対応する機能ブランチをマスターブランチにマージします。これにより、機能ブランチとマスターブランチの違いのみを含むマージチェンジセットが作成されます。 Mercuialを使い始めたとき、機能開発を個別のクローンのみで分離するワークフローも使用しました。しかし、私たちは名前ブランチを使用しているので、私たちの生活ははるかに簡単になりました。チェンジセットは明確に分離されており、混乱することなく1つのリポジトリ内にすべてのブランチを含めることができます。さらに、異なるブランチ間を簡単に切り替えることができます。そして、私が言ったように、あなたははるかにきれいな歴史を得ます。