最近は体調が良くなく、技術記事も書いていません。今日、私は登って、GITのリベースモード（リベース）についてみんなとおしゃべりしました。
この記事は、特定のGIT基盤に基づいています。これまで触れたことがない場合は、以前に作成された2つの紹介記事を読むことができます。
アニメーション：リテラシーGitバージョンコントロール（パート1）
アニメーション：リテラシーGitバージョンコントロール（パート2）
チームワークプロジェクトでリベースモデルを初めて使用して学んだときは、上司から教科書のように教えられました。プロジェクトでの継続的な使用を通じて、私自身の使用法と見解のいくつかを要約しました。
GIT自体は初心者にとってはあまり良くありません。私個人としては、最初は基本的な概念が最初に連絡されたときに透過的に理解されていませんでした。これらの概念が実践されて独自の理解が形成されたときのみ、この概念が元々これを意味していたこと、およびこのコマンドがどのように見えるかを知ってください。
したがって、Xiaoluはできるだけ多くの絵を描き、意味のないものを少なくして、GITを完全に理解していない友人が助けを提供できるようにします。
1.リベースとは何ですか？
リベース、ローベースの意味がわかります。建物を建てるのと同じように、層ごとに積み上げられ、底が土台になります。建物の各層を土台と呼びます。
（理解を深めるために、上記の建物を例として取り上げます）
フロアが構築され、合計18フロアあり、各フロアを装飾するために複数のデコレータが必要であるとします。私の装飾チームには、A、B、Cの3人がいます。
Aは第1層を担当し、Bは第2層を担当し、Cは第3層を担当します。通常の論理によれば、3人より前に自分のフロアの装飾を終えた人は誰でも4階に行って装飾します。
しかし、問題があります。Bの2階も装飾されているが、Bが他の2人の最新の進捗状況を知らない場合、彼は何らかの方法で現在の進捗状況を最新に更新する必要があります（Bは装飾の次のステップを知っている必要があります）他の2つの進捗状況に基づいて装飾を継続するためにいくつかのフロア）。
上記の建物の建設例は、GITを使用してリベースするプロジェクトのチームワークにはあまり適していませんが、すべての人に一般的な印象を与えるためです。
2.なぜリベースを使用するのですか？
通常、チーム協力ではGITバージョンコントロールを使用します。各自が独自のブランチで開発します。最後に、担当者が各自で開発したブランチをメインブランチにマージします。リベースモデルがあります。それは何ですか。 ？
まず、プロジェクトが大きくなり、チームの人数が増え、提出されるブランチが増え、コミット後に全員をマスターブランチにマージする必要があります。gitブランチの図全体が見栄えが悪く、メンテナンスに役立たず、管理。（図に示すように）
第二に、プロジェクトはさまざまなコミットでいっぱいです。ある日緊急事態が発生した場合は、コードをロールバックし、疑わしい人生を見ることができるように、多数のコミットを1つずつ確認する必要があります。
上記の2つの理由により、従来の送信とマージを完全に諦める可能性があり、リベースモードで送信されたコードは非常に明確です。（以下に示すように）
3.リベースする方法は？
リベースする方法について、この部分で最も重要なことは、練習し、練習し、練習することです。練習はありません、あなたはそれを無料で読むことができます、私が言ったことを覚えておいてください。
リベースモードでは、以下の一般的に使用されるコマンドが使用されます。例として、上記の建物を取り上げます。
Bの第2層が終了したら、下の全員の開発の進捗状況を知り、全員の進捗状況に基づいて次の開発に進みます。
プロジェクトと同じように、開発した関数を送信したいのですが、現在の関数を開発するときに、リモートウェアハウスの誰かがすでにコードを送信している可能性があり、ローカルウェアハウスとリモートウェアハウスのコードに一貫性がありません。
プッシュコードの前にリモートウェアハウスコードとの整合性を実現するには、リベース（リベース）する必要があります。コマンドは次のとおりです。
1git pull base dev --rebase
この順序は、Bが装飾のために床の5階に直接行ったのと同じです。そして、私たちの装飾記録、つまり私たちの主要な開発ブランチは非常に明確になりました。これはコミットでいっぱいのブランチラインです。
4.ベースを壊しました
しかし、ここで問題が発生します。GITリベースモードを最初に使用したとき、何度もプレイして、ある程度の経験を積みました。
毎回最新のコードを送信すると、毎回リベースするのを忘れます。つまり、最新のリモートコードを考慮しないたびに、関数を開発して直接送信すると、オンラインコードがフォークされます（実際には、オリジナルの提出方法）。
とても心配です、どうすればいいですか？長男が出て行く、一人が最高、何も悪いことはない。
ロールバックとピックの方法を使用して、メインブランチが分岐しないようにします。いわゆるピックは、cherry-pickコマンドを使用して、マウントするブランチにコミットを再アタッチすることです。
1git cherry-pick <commit id>
ピッキングが終了したら、もう一度pushとprを実行すると、分岐したブランチが元の行に戻ります。いいじゃないですか。
概要
Gitのリベースを十分に理解した後は、特に難しいとは感じませんが、早い段階で接触したばかりで、理解できないことがたくさんあり、ゲームが壊れてしまうことがよくあります。そうは言っても、風雨を経験せずにどうやって虹を見ることができますか？