git rebaseパラメータの理解と記憶

これまでのところ、gitの最も混乱する部分は、別のブランチにリベースすることです。具体的には、混乱を招くのはコマンドライン引数です。

1つのブランチの小さな部分を別のブランチの先端にリベースするたびに、git rebaseのドキュメントを確認する必要があり、3つの主要な引数のそれぞれが何であるかを理解するのに約5〜10分かかります。

git rebase <upstream> <branch> --onto <newbase>

別のブランチへのリベースの種類が与えられた場合、これらの3つのパラメーターのそれぞれが何に設定されるべきかを覚えるのに役立つ良い経験則は何ですか？

私がgit-rebaseのドキュメントを何度も何度も何度も何度も繰り返したが、（退屈な科学的なホワイトペーパーなど）常に理解するのは難しいことを覚えておいてください。そのため、現時点では、他の人を巻き込んで把握する必要があると感じています。

私の目標は、これらの基本的なパラメータのドキュメントを確認する必要がないことです。今のところ、それらを覚えることはできず、すでに大量のリベースを行っています。したがって、これまでに他のすべてのコマンドとそのパラメーターを記憶できたが、でリベースできないことは少し変わっています--onto。

--ontoとりあえずスキップしましょう。 upstreamそしてbranch、かなり基本的なものであり、実際には一種の模倣でcheckoutあり、-2 branch番目の引数はオプションです：

git branch <newbranch>
git branch <newbranch> <base>
git checkout -b <newbranch>
git checkout -b <newbranch> <base>
git rebase <upstream>
git rebase <upstream> <branch>

_{（別に、これらの引数の名前rebase。、「上流」と「ブランチ」は非常にIMO記述されていない私は、一般的にpeachoftreeのようにそれらを考える、<start>と<end>私はそれらを使用することがありますどのようにしています、： git rebase <start> <end>）}

2番目のブランチを省略した場合、結果は、最初にそのブランチをチェックアウトしてから、そのブランチを指定していないかのように実行するのとほぼ同じです。例外はbranch、現在のブランチを変更しないことです。

git checkout <base> && git branch <newbranch> && git checkout <previous_branch>
git checkout <base> && git checkout -b <newbranch>
git checkout <end>  && git rebase <start>

rebase呼び出されたときに何が行われるかを理解するために、私は最初にそれを特別なタイプのマージとして考えることから始めました。実際にはそうではありませんが、最初にリベースを理解し始めたときに役立ちました。peachoftreeの例を借りるには：

A--B--F--G master
    \
     C--D--E feature

このgit merge master結果：

A--B--F-----G master
    \        \
     C--D--E--H feature

一方、git rebase master（ブランチでfeature！）結果は次のようになります。

A--B--F--G master
          \
           C'--D'--E' feature

どちらの場合も、とのfeature両方のコードが含まれています。をオンにしていない場合は、2番目の引数を使用してショートカットに切り替えることができます 。上記と同じことを行います。masterfeaturefeaturegit rebase master feature

今、スペシャルのために--onto。これで覚えておくべき重要な部分は、<start>指定されていない場合、デフォルトであるということです。したがって、上記で--onto具体的に指定した場合、これは同じ結果になります。

git rebase --onto master master
git rebase --onto master master feature

_{（私が--onto指定せずに使用することはありません。<end>なぜなら、すでにオンになってfeatureいる場合、これら2つは同じだと思っていても、精神的に解析する方が簡単だからです。}

なぜ--onto役立つかを理解するために、ここに別の例を示します。私がオンfeatureになっていてバグに気付いたとしましょう。それを修正し始めましたfeatureがmaster、誤ってではなく分岐してしまいました。

A--B--F--G master
    \
     C--D--E feature
            \
             H--I bugfix

私が望んでいるのは、これらのコミットが「bugfix依存」しないように「移動」することですfeature。現状では、この回答で上記に示したあらゆる種類のマージまたはリベースfeatureは、2 つのコミットとともに3つのコミットを取得しbugfixます。

たとえば、git rebase master bugfix間違っています。たまたまからのすべてのコミットが含まれる範囲<start>には、上で再生されます：<end>featuremaster

A--B--F--G master
    \     \
     \     C'--D'--E'--H'--I' bugfix
      \
       C--D--E feature

私たちが実際に望んでいるのは、の上で再生されるからfeatureまでのコミットの範囲bugfixですmaster。それ--ontoが目的です-「開始」ブランチとは異なる「再生」ターゲットを指定します。

git rebase --onto master feature bugfix

A--B--F--G master
    \     \
     \     H'--I' bugfix
      \
       C--D--E feature

復習すると、リベースは主に、2つのブランチが互いに独立して開発された場合にコミット履歴を直線的に見せたい場合に使用します。基本的には、コミット履歴を書き換えます。

私がそれをしたい方法は git rebase --onto <target branch> <start branch> <end branch>

どこ<target branch>あなたが上にリベースされている分岐があり、<start branch>通常のブランチで<end branch>分割し、<end branch>あなたがリベースされているブランチです。

あなたがから始めるなら

A--B--F--G master
    \
     C--D--E feature

そして、やります

git rebase --onto master master feature

あなたは得るでしょう

A--B--F--G master
          \
           C'--D'--E' feature

知っておくとよいもう1つのことは、<target branch>デフォルトでと<start branch>なるので、同じリベースを実行できることです。

git rebase --onto master feature

さらにヘルプが必要な場合は、涙のないリベースガイドをチェックしてください