「Myproject」というリポジトリがあり、その中に「MyProject-new changes」ブランチがあります。
ローカル マシンの "MyProject" リポジトリを c:/MyProject として複製しました
同様に、「MyProject-new changes」を c:/MyProject-new changes として複製します。
両方のリポジトリには、プルとマージ後に最新の変更が含まれています。
ここで、「MyProject-new changes」(ブランチ) の変更を「MyProject」にローカルにマージする必要があります。
マージしたら、これらの変更をコミットしたくありません.ブランチの変更が行われているので、変更を元に戻します。新しい変更を統合して、当面の結果を確認したいだけです。
次のことを教えてください
最も簡単な方法は、リポジトリの完全なクローンを作成し、思いのままにマージしてテストし、完了したらリポジトリを破棄することです。@Kirill はその方法を説明します。
しかし、なぜそれをするのですか？クローンで修正する問題や小さなマージ競合に遭遇するかもしれません。この作業を捨てるのは残念です。おそらく将来必要になるでしょう。もちろん、単純にクローンを維持することもできますが、前提を再考することをお勧めします: 2 つのブランチをマージしたくないのはなぜですか?
main ブランチ ( default) と feature ブランチnew-changesがあり、それらがどのように連携するかを安全に確認したいと考えています。リポジトリをクローンせずにこれを行うには、次の 2 つの方法があります。
ブランチを安全に保つには、 defaultからnew-changesにdefaultマージするだけです。
hg update new-changes # switch to the branch
hg merge -r default
新しい変更をテストし、問題を修正できるようになりました。これは非常に一般的なワークフローです。 への変更は、default実行時間の長いブランチに組み込まれ、ブランチが離れすぎないようにします。最終的に 2 つの開発ラインを統合する準備ができたらnew-changes、デフォルトのラインにマージすると、すべてが正しく機能します。
当分の間、両方のブランチを純粋に保ちたい場合は、新しいブランチtestingを作成し、既存の両方のブランチをそれにマージできます。保存して最終的に にマージするか、失敗した実験であることが判明したdefault場合は閉じることができます。new-changes(詳細:testingがいずれかのブランチの先頭にルートされている場合、そのブランチから「マージするものは何もありません」。他のブランチをマージするだけで済みます。)
メイン リポジトリを台無しにするリスクを冒したくない場合は、もちろん、クローンを作成して、クローンで上記のアプローチのいずれかを試すことができます。正しく機能したことを確認したら、すべてをメイン リポジトリにプッシュします。