マージコマンドと比較したgitrebaseコマンドの使用

gitrebaseコマンド

1.基本的な使用法

  1. githubで新しいプロジェクトを作成します

    画像-20211213205417673
  2. デフォルトでマスターブランチがあります(注: Githubによってデフォルトで作成されたブランチがメインブランチです)

    画像-20211213205622555
  3. プロジェクトをローカルに複製する

日々の開発をシミュレートする

同級生の操作

  1. gitlogを実行する

    画像-20211213205839717

    現時点では、プロジェクトの提出レコードは1つだけであることがわかります。

  2. ファイルを追加し、コミットおよびプッシュ操作を実行します

    画像-20211213205906793 画像-20211214091804785
  3. Githubを更新して、クラスメートAから送信されたレコードを見つけます

    画像-20211213210040623
  4. 2つのコミットレコードを持つローカルマスターブランチに基づいて新しいブランチ開発をチェックアウトし、ブランチをリモートリポジトリにプッシュします

    画像-20211213210123526
  5. リモートウェアハウスを確認してください。もう1つの開発ブランチがあります

    画像-20211213210141254
  6. この時点で、ローカルgitブランチ図は次のようになります(C1、C2は送信されたバージョンを表します)

    画像-20211213210200295
  7. クラスメートAがdevブランチに基づいて関数を開発し、ローカルで3つの新しいコードを送信したとします。gitログは次のとおりです。

    画像-20211213210237887
  8. この時のgitブランチ図は以下の通りです

    画像-20211213210253548

同級生Bの操作

クラスメートAが4番目のローカル送信を行う準備ができる前に、別のクラスメートBがマスターブランチ送信をリモートウェアハウスにプッシュした場合、つまり、マスターの実際の送信はこの時点で進んでいます。

画像-20211213210406182

同級生の操作

  1. マスターブランチに切り替えて、マスターBから送信された最新のコードを取得します

  2. この時の分岐図は次のとおりです。

    画像-20211213210607938
  3. クラスメートAによって開発された開発ブランチはC2コミットポイントに基づいて切り出され、この時点でマスターブランチが更新されています。クラスメートAが開発を完了し、その機能をマスターブランチにマージする必要がある場合、彼は2つ持つことができます。選択肢:

    • gitマージ
    • git rebase

方法1:git merge

マスターブランチに切り替えて、コマンドを実行します。git merge devコマンドの実行プロセスは次のとおりです。

  • devブランチとmasterブランチの最も近い共通の祖先、つまりC2のコミットポイントを見つけます

  • devの最新のコミット(C5)とmasterの最新のコミット(C6)をマージして、新しいコミット(C7)を生成します。競合がある場合は、競合を解決する必要があります。

  • 上記の2つのブランチdevにすべてのコミットポイント(C2以降)を配置し、マスターブランチにコミット時間の順序でマスターを配置します(つまり、コミットされたすべてのレコードが保持されます)

  • このときの分岐図は次のとおりです。

    画像-20211213210912489

その後、クラスメートAはdevブランチで開発を続け、マスターは前進を続けます。マージが発生した場合は、上記の手順を繰り返します。

この方法のデメリット:

マージはすべてのブランチのすべての種類の情報を記録するため、プロジェクトブランチが多く、コミットが多い場合、次の状況が発生します。これは複雑すぎます。

画像-20211214095613790

方法2:git rebase

  1. リベースする前に、マスターコードを最新のものにプルする必要があります

  2. devブランチでgit rebase masterコマンドと、実行後の効果は次のようになります。

    画像-20211214100149789

    これ以上コミットがなく、C3、C4、C5など、devが変更された後にコミットハッシュ値が数回送信されたことがわかります。

  3. マスターブランチに切り替えて実行git rebase devします。実行後の効果は次のとおりです。

    画像-20211214100956938

    リベースメソッドを使用してブランチをマージし、マスターブランチ全体に新しいコミットがないことがわかりました。元の開発ブランチ(C3、C4、C5)のコミットのハッシュ値は、リベース後に変更されました。マスターブランチ全体が変更されました。以下に示すように、コミットレコードは線形に記録されます。

    画像-20211214101648176

    注:元のマスターのC6は、開発者のC3の前にあります。

要約する

  1. git merge操作はブランチをマージして、2つのブランチの各コミットが(プッシュ時間ではなく)コミット時間に従ってソートされ、2つのブランチの最新のコミットポイントが新しいコミットにマージされ、最終的なブランチツリーは次のようになります。非全体の線形線の形で提示されます。

  2. git rebase操作は、実際には、元のブランチのコミットポイントに基づいて現在リベースブランチを実行しているすべてのコミットを1つずつパッチ(パッチ)に分割し、元の最新のコミットに基づいて新しいコミットハッシュ値を再生成しますブランチ。その時点でコミットします(したがって、マスターを最新のものにプルする必要があります)。これにより、ブランチツリー全体が完全に線形に保たれます。

  3. 2つの方法の比較チャート:

    画像-20211214102904271

2.-iパラメータマージコミット

毎日の開発では、コードの変更が頻繁に行われ、前のコミットを1つのコミットにマージしたい場合があります(たとえば、関数の複数のコミットは最後のコミットのみを保持します)。これは、gitrebase-iコマンドを使用して実行できます。

フォーマット:

git rebase -i [startpoint] [endpoint]

ここで、-iは–interactiveを意味します。つまり、ユーザーが編集してマージ操作を完了するためのインタラクティブインターフェイスがポップアップ表示されます。[startpoint] [endpoint]は編集間隔を指定します。[endpoint]が指定されていない場合、間隔はデフォルトで現在の間隔になります。ブランチHEADが指すコミットポイント(注:この間隔は、前に開き、後で閉じる間隔を指定します

例:

// 合并从当前head到15f745b(commit id)
git rebase -i 15f745b

// 合并最近的两次提交
git rebase -i HEAD~2

このコマンドを実行すると、viエディターにジャンプします。

このエディターで圧縮するコミットのフロントエンドをsに変更します。sはsquashの省略形です。これは、このコミットが最後のコミットに圧縮されることを意味します。

画像-20211214102904271

入力:wqして保存すると、次のインターフェイスがポップアップ表示されます。

画像-20211214105155877

Enterキーを押し:wqて保存してから、Enterキーをgit push -f押してgithubと同期します。

3.補足説明

git rebase --continue:リベース操作を続行します。たとえば、リベース中に競合が発生した場合は、ソリューションの完了後にgit addを実行し、実行してリベース操作git rebase --continueを続行します。

git rebase --abort:このリベース操作を終了します。

おすすめ

転載: blog.csdn.net/weixin_49343190/article/details/121924180