2

リベース後に追加のコミットをプルする簡単な方法、またはリベースしないように誰かに指示する正当な理由を探しています。

基本的に、プロジェクトがありcronsます。私はこれを頻繁に変更しますが、プロジェクトのメンテナは、要求したときに変更を取り込み、毎回リベースします。

これは通常は問題ありませんが、次の2つのシナリオで問題が発生する可能性があります。

  • 2つのブランチから同時にリリースする
  • 後で追加のコミットをリリースする必要があります。

たとえば、リビジョンをコミットし1000ます。メンテナはプルしてリベースしてリビジョンを作成します1000'が、ほぼ同時に恐ろしい間違いに気づき、リビジョンを作成します1001（の子1000）。ターゲットブランチに存在しないため1000、これにより使用できないマージが作成され、メンテナは通常、私を笑って再試行するように指示します（これには、メインブランチの新しいチェックアウトを取得し、1000'からパッチを手動で作成してインポートする必要があります）他のチェックアウト）。2つの別々のブランチから同時にリリースしようとすると、同じ問題がどのように発生するかがわかると思います。

とにかく、メインブランチができたら、同じ変更を再度マージすることなく1000'プルインするためにできることはありますか？1001それとも、リベースはこれを台無しにしますか？とにかく、メンテナーにリベースをやめさせるために私が言えることはありますか？彼はそれを間違って使用していますか？

4

1 に答える 1

4

ジャッカ**になるのをやめるようにメンテナに伝えてください。

リベースは、リベースするチェンジセットを作成したユーザーのみが実行する必要があり、次のようなチェンジセットに対しては実行しないでください。

  • すでに他の誰かと共有しています
  • 他の誰かから得た

メンテナはおそらく、DVCSの分岐した性質ではなく、チェンジセットが直線に従うSubversionのような非分散バージョン管理システムを望んでいます。その点で、Mercurialの選択が間違っているか、Mercurialの使用法が間違っています。

また、リベースは履歴を変更する1つの方法であり、Mercurialはその（履歴の変更）ことを推奨しないため、リベースは拡張としてのみ利用可能であり、バニラMercurial構成の「箱から出して」利用することはできません。

だからあなたの質問に答えるために：いいえ、あなたのメンテナはDVCSの性質を壊すことを主張しているので、ツールはあなた（そして彼）と戦うでしょう、そしてあなたはツールをあなたと協力させるのに苦労するでしょう。

DVCSが実際にどのように機能するかを受け入れるようにメンテナに伝えます。今でも、彼は自分のリポジトリで新しいブランチやヘッドを受け入れないことを主張し、1つのヘッドを自分のリポジトリにプッシュバックする前に、プルしてマージすることを主張するかもしれませんが、それは問題ありません。

ただし、共有チェンジセットのリベースはそうではありません。

本当にリベースを使用したい場合、それを行う正しい方法は次のようになります。

  1. いくつかのソースリポジトリから最新の変更をプルします
  2. 多くのチェンジセットをローカルでコミットし、バグを修正し、新機能を追加します。
  3. 次に、プッシュしようとすると、ターゲットリポジトリに新しいヘッドが作成されることが通知されます。これは、ターゲットリポジトリに、最後にプルしたときに取得しなかった新しいチェンジセットがあることを示しています。これは、その後に追加されたためです。
  4. 代わりに、プルすると、ローカルリポジトリに新しいヘッドが追加されます。これで、新しいチェンジセットから作成されたヘッドと、他の人が作成したソースリポジトリから取得されたヘッドができました。
  5. 次に、ソースリポジトリから取得したものの上にチェンジセットをリベースします。つまり、履歴内のチェンジセットを移動して、現在のソースリポジトリ内の最新のチェンジセットから作業を開始したように見せます。
  6. 次に、新しいプッシュを試みて成功します

最終的な結果として、ターゲットリポジトリと独自のリポジトリには、ブランチとマージではなく、より線形のチェンジセット履歴が含まれます。

ただし、DVCSでは複数のブランチで問題がないため、これらすべてを実行する必要はありません。マージして作業を続けることができます。これは、DVCSが機能することになっている方法です。リベースは、本当に必要な場合に使用できる追加のツールです。

于 2013-01-26T20:59:58.127 に答える