3

rebaseif Mercurial拡張機能は、プル時に、競合なしでマージを自動的に実行できる場合にのみ、リベースを実行するプロセスを自動化します。（手動で解決する競合がある場合、リベースは行われないため、2つのブランチを手動でマージする準備が整います。）これにより、開発者がコードのさまざまな部分で作業しているときに履歴が単純化および線形化されますが、リベースはスローされます。開発者が作業を行っていたときの世界の状態に関する情報を削除します。私はこのような議論に同意する傾向があります一般的なケースでは、リベースは良い考えではありませんが、リベース-哲学が競合しない場合に魅力的である場合、私はリベースを見つけます。コードのさまざまな部分で変更が発生した場合、ロジックエラーのリスクがまだあることを理解していますが、私はそれについて気を配っています（そして、rebaseif拡張機能の作成者はそれが悪い考えだと感じるようになりました。）

私は最近、複雑で苦痛なバイセクトを経験しました。リポジトリに短いブランチのマージが多数あることが、バイセクトが暗黙のO（lg n）の約束を果たせなかった主な理由だと思います。マージを超えて範囲を拡張するために、「bisect --extend」を何度も実行する必要があることに気付きました。一度にいくつかのチェンジセットを実行して、基本的にbisect O（n）を作成します。また、リポジトリのグラフを見ると分岐を追跡できなかったため、バイセクトがどのように進んでいるかを追跡し、これまでに取得した情報を理解するのは非常に複雑でした。

bisectを使用する（そして改訂履歴を見て理解する）より良い方法はありますか、それとも開発でrebaseifをもっと使用していれば、プロセスはよりスムーズだったでしょう。または、競合していない場合にリベースを使用すると何がうまくいかないのかをより具体的に理解するのに役立ちますか？問題を引き起こす可能性があり、回避する必要がありますか？

rebaseifはより一般的なgitワークフローに一致すると思うので、これをより一般的に（Mercurialだけでなく）タグ付けしています。gitユーザーは落とし穴を見たことがあるかもしれません。

4

2 に答える 2

5

答えは簡単だと思います。ハードバイセクトとリスクの高いリベースとの間で分割する必要があります。

または、その間の何か: リベースが静かに何かを壊す可能性が非常に低い場合にのみリベースしてください。リベースに、リベース元の変更から意味的に離れているいくつかのチェンジセットのみが含まれる場合、通常はリベースしても安全です。

競合のないマージが問題を起こす例を次に示します。

次の内容のファイルから 2 つの分岐が始まるとします。

def foo(a):
    # do
    # something
    # with a (an integer)

...

foo(4)

ブランチ A では、これは次のように変更されます。

def foo(a):
    # now this function is 10 times faster, but only work with positive integers
    assert a > 0
    # do
    # something with
    # with a

...

foo(4)

ブランチ B では、次のように変更されます。

def foo(a):
    # do
    # something
    # with a (an integer)

...

foo(4)

...

foo(-1) # now we have a use case where we need to call foo with -1

意味的には、両方の編集が互いに競合します。ただし、Mercurial は競合することなく喜んでマージします (どちらの場合も、リベース時または通常のマージ時)。

def foo(a):
    # now this function is 10 times faster, but only work with positive integers
    assert a > 0
    # do
    # something with
    # with a

...

foo(4)

...

foo(-1) # now we have a use case where we need to call foo with -1

マージの利点は、後で問題が発生したことを理解できるため、それに応じて問題を修正できることです。リベースは、自動マージによって引き起こされるバグを理解するために必要な情報を破棄する可能性があります。

于 2012-10-08T19:30:48.337 に答える
2

反対の主な議論git rebaseは「履歴を失う」ことに関する哲学的なもののようですが、もし私がそれを本当に気にかけているなら、最後のビルドステップをチェックインにします (または、失敗したすべてのビルドを追跡する最初のビルドステップも!)。

私は Mercurial や bisecting に特に詳しくはありませんが (git に少し似ていることを除いて)、1 か月ほど git を使っていたので、リベースだけに固執しました。私もgit rebase -i --autosquashとgit add -pをよく使います。

IME、競合の修正に関しても、リベースとマージの間にそれほど大きな違いはありません。コードベースのビルドとテストが成功するかどうかによって条件付けられます。

おそらく私の考えは、git の設計に固有の弱点 (ブランチの履歴、つまり、実際に指されているコミットのサブセットを明示的に追跡していない) によってゆがめられているか、単に私の作業方法 ( diff は正常であり、ビルドされますが、確かにリベース後に中間コミットがビルドされることを確認していません)。

(余談ですが、個人的なプロジェクトでは、各ビルド出力と対応するソース スナップショットを追跡したいと思うことがよくありますが、これを行うのに適したものをまだ見つけていません。)

于 2012-10-08T19:03:47.433 に答える