17

git-rebase のドキュメントを読むたびに、迷子になります。私には、一種の低レベルの操作のように感じます (読む: 闇の魔法)。

ドキュメントの引用：

次の履歴が存在し、現在のブランチが「トピック」であると仮定します。

       A---B---C topic
      /
 D---E---F---G master

この時点から、次のいずれかのコマンドの結果:

git rebase master 
git rebase master topic

だろう：

               A'--B'--C' トピック
              /
 D---E---F---Gマスター

問題は、なぜそのようなことをしたいのかということです。

1 つには、分岐が別の時点で開始されたかのように、履歴を「書き換える」ように見えます。基本的に、コミット履歴は「嘘の束」になります。

別のポイントは、安全ではないと感じることです。私は一度それを試してみましたが、たくさんの衝突があり、すべての地獄が解き放たれました. その地獄をどのように解決したか正確には覚えていませんが、記憶が正しければ、一時的なテストブランチかそのようなものでした。

もう 1 つの質問:使用方法がわからないために、非常に優れた/時間を節約できる一連の機能を見逃していませんgit-rebaseか?

編集：

関連する質問: git rebase の取り消し

4

4 に答える 4

8

たとえば、他の誰かが変更したコードにパッチを送信する場合に使用する必要があります。たとえば、ソフトウェアのリビジョン1.56から分岐し、その間にメンテナがリビジョン1.57に移行した場合、おそらくリビジョン1.57のパッチのみを受け入れるでしょう。

ブランチをリビジョン1.57にリベースし、すべての競合を修正し、パッチを確認して再送信します。

于 2009-05-28T20:36:20.683 に答える
8

まず、git には危険な操作はありません。rebase には中止操作があり、すべての操作が reflog に行われるため、何でも元に戻すことができます。実際、それはまったく逆です。

これにより、「良い」ビルドを作成する途中でなくても、好きなときにいつでも自由にコミットできます。公開するリビジョンは、途中で行ったすべてのステップを 1 つのコミットにまとめることでクリーンにすることができます。

私は常にリベースを使用しています（通常、フェッチフェーズの後にリベースするように構成したプルを介して非常に頻繁に使用します）。履歴を書き換えるとは考えないでください。公開する前にラフ ドラフトをクリーンアップするためのツールを提供するものと考えてください。

E今から 1 年後に、あなたが本当にこの機能を改訂に対してではなく改訂に対して開始したことをプロジェクトの誰かが知ることは重要Gですか?

不必要な再帰的なマージは、履歴のより重要な部分を覆い隠します。

于 2009-05-28T21:58:15.633 に答える
5

「トピック」を「マスター」にマージするとすぐに、とにかくそれらの競合が発生します。したがって、時々「トピック」を「マスター」にリベースすることをお勧めします (1 つの大きなステップを実行するよりも、小さなステップを実行する方が簡単です。少なくとも imo)。マージする前にリベースすると、すべての「危険な」ことがブランチで発生し、その後のマージは簡単になります。

于 2009-05-28T20:26:51.200 に答える
4

James Bowes によるgit rebase: keep your branch currentブログ投稿を参照してください。

于 2009-05-30T12:04:18.700 に答える