gitrebaseコマンド
記事ディレクトリ
1.基本的な使用法
-
githubで新しいプロジェクトを作成します
-
デフォルトでマスターブランチがあります(注: Githubによってデフォルトで作成されたブランチがメインブランチです)
-
プロジェクトをローカルに複製する
日々の開発をシミュレートする
同級生の操作
-
gitlogを実行する
現時点では、プロジェクトの提出レコードは1つだけであることがわかります。
-
ファイルを追加し、コミットおよびプッシュ操作を実行します
-
Githubを更新して、クラスメートAから送信されたレコードを見つけます
-
2つのコミットレコードを持つローカルマスターブランチに基づいて新しいブランチ開発をチェックアウトし、ブランチをリモートリポジトリにプッシュします
-
リモートウェアハウスを確認してください。もう1つの開発ブランチがあります
-
この時点で、ローカルgitブランチ図は次のようになります(C1、C2は送信されたバージョンを表します)
-
クラスメートAがdevブランチに基づいて関数を開発し、ローカルで3つの新しいコードを送信したとします。gitログは次のとおりです。
-
この時のgitブランチ図は以下の通りです
同級生Bの操作
クラスメートAが4番目のローカル送信を行う準備ができる前に、別のクラスメートBがマスターブランチ送信をリモートウェアハウスにプッシュした場合、つまり、マスターの実際の送信はこの時点で進んでいます。
同級生の操作
-
マスターブランチに切り替えて、マスターBから送信された最新のコードを取得します
-
この時の分岐図は次のとおりです。
-
クラスメートAによって開発された開発ブランチはC2コミットポイントに基づいて切り出され、この時点でマスターブランチが更新されています。クラスメートAが開発を完了し、その機能をマスターブランチにマージする必要がある場合、彼は2つ持つことができます。選択肢:
- gitマージ
- git rebase
方法1:git merge
マスターブランチに切り替えて、コマンドを実行します。git merge dev
コマンドの実行プロセスは次のとおりです。
-
devブランチとmasterブランチの最も近い共通の祖先、つまりC2のコミットポイントを見つけます
-
devの最新のコミット(C5)とmasterの最新のコミット(C6)をマージして、新しいコミット(C7)を生成します。競合がある場合は、競合を解決する必要があります。
-
上記の2つのブランチdevにすべてのコミットポイント(C2以降)を配置し、マスターブランチにコミット時間の順序でマスターを配置します(つまり、コミットされたすべてのレコードが保持されます)
-
このときの分岐図は次のとおりです。
その後、クラスメートAはdevブランチで開発を続け、マスターは前進を続けます。マージが発生した場合は、上記の手順を繰り返します。
この方法のデメリット:
マージはすべてのブランチのすべての種類の情報を記録するため、プロジェクトブランチが多く、コミットが多い場合、次の状況が発生します。これは複雑すぎます。
方法2:git rebase
-
リベースする前に、マスターコードを最新のものにプルする必要があります
-
devブランチで
git rebase master
コマンドと、実行後の効果は次のようになります。これ以上コミットがなく、C3、C4、C5など、devが変更された後にコミットハッシュ値が数回送信されたことがわかります。
-
マスターブランチに切り替えて実行
git rebase dev
します。実行後の効果は次のとおりです。リベースメソッドを使用してブランチをマージし、マスターブランチ全体に新しいコミットがないことがわかりました。元の開発ブランチ(C3、C4、C5)のコミットのハッシュ値は、リベース後に変更されました。マスターブランチ全体が変更されました。以下に示すように、コミットレコードは線形に記録されます。
注:元のマスターのC6は、開発者のC3の前にあります。
要約する
-
git merge操作はブランチをマージして、2つのブランチの各コミットが(プッシュ時間ではなく)コミット時間に従ってソートされ、2つのブランチの最新のコミットポイントが新しいコミットにマージされ、最終的なブランチツリーは次のようになります。非全体の線形線の形で提示されます。
-
git rebase操作は、実際には、元のブランチのコミットポイントに基づいて現在リベースブランチを実行しているすべてのコミットを1つずつパッチ(パッチ)に分割し、元の最新のコミットに基づいて新しいコミットハッシュ値を再生成しますブランチ。その時点でコミットします(したがって、マスターを最新のものにプルする必要があります)。これにより、ブランチツリー全体が完全に線形に保たれます。
-
2つの方法の比較チャート:
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の省略形です。これは、このコミットが最後のコミットに圧縮されることを意味します。
入力:wq
して保存すると、次のインターフェイスがポップアップ表示されます。
Enterキーを押し:wq
て保存してから、Enterキーをgit push -f
押してgithubと同期します。
3.補足説明
git rebase --continue:リベース操作を続行します。たとえば、リベース中に競合が発生した場合は、ソリューションの完了後にgit addを実行し、実行してリベース操作git rebase --continue
を続行します。
git rebase --abort:このリベース操作を終了します。