環境部品スキップ
リモートの新しいブランチの作成、ロールバック、その他の操作など、gitを説明するプロジェクトを0から作成します。
すべての説明の間に質問と質問があります
- 基本部品説明
- 実用的な高度な部分
基本的な内容
githubにすでにウェアハウスがある場合は、アイデアを使用してクローンを作成します
以下のインターフェースにある場合は、以下の手順に従ってください
クローンのダウンロードを実行する
次のインターフェースの場合は、
同上
githubに既存のプロジェクトがない場合、または新しいプロジェクトを作成する場合
IDEAを介して新しい通常のプロジェクトを作成します（mavenは問題ありません）
以下に示すように
TestGitの通常のmavenプロジェクト（新しいプロジェクトはバージョン管理されていません）
最初のステップは、アイデアの上部にあるVCSオプションに対応するVCS（VCSのバージョン管理システムの頭字語）を導入することです。サイドにはウィンドウとヘルプがあります。
以下に示すように、バージョン管理をオンにします
ここでデモとしてGitを選択します
下の図に示すように、スクリーンショットに説明があります
この時点で、ここでのバージョン管理はローカルウェアハウスであることに注意してください。
ローカルサブミッションとリモートサブミッションに送信され ます（ログインが必要なgithubアカウント）
以下のようにアイデアでgithubにログインします
ログインするには2つの方法があります。
最高の権限を記録するためのアカウント+パスワードには、アカウントのすべての特権があります
トークンのログイン権限はアカウント所有者によって作成され、対応する権限が割り当てられます
トークン作成アドレス：https : //github.com/settings/tokens
以下に示すように：
以下の例に示すように、割り当てられた対応する権限を選択し、メモに記入する必要があります（後で直接管理するために、主にどのトークンがこのトークンであるかを知ることです）
作成後、取得したトークンをIDEAで直接ログインできます
ローカルで送信
まず最初に、どのファイルを送信する必要があるかに注意を払う必要があります。ファイルを選択===》右クリック===》 git ==》ファイルにバージョン管理を追加
初心者によくある間違い：
追加する項目を直接選択します（不要なファイルもバージョン管理されます）
私のアドバイスは：
追加操作にsrcフォルダーとpom.xmlファイルを追加し、次のファイルのコードに関連する構成ファイルを追加するだけです。
.ideaフォルダー
xxxxx.imlファイル
このようなファイルは、コンピューターの環境設定であるため、送信されないようにIdeaによって自動的に生成されます。
これらのファイルが送信された場合、チームが一緒に開発することは良くありません。
これらのファイルはクローンがダウンしたときにクローンされるため、相手のアイデアは自分のコンピューターに構成をロードする代わりにプロジェクトの下の構成ファイルを使用します
特定のjdkのバージョンとパス（相手がjdkを見つけられない可能性があり、SDKを手動で設定する必要がある場合があります）と相手のアイデアの使用方法およびその他の設定は、自分のコンピューターのアイデアの構成になります。したがって、追加するアイテムを直接選択しないでください
手動で対応するファイルを選択し、このような不要なファイルは追加しないでください。
元に戻すを元に戻すには、Ctrl Z、または以下に示すようにファイルGitを選択します。
一般的に言えば、Add srcフォルダーとpom.xmlファイルのみが必要です
git送信の機能があります。フォルダーの下のファイルがバージョン管理されていない場合、ファイルを送信すると、ウェアハウスにsrcなどのフォルダーはなく、pom.xmlファイルのみがあることがわかります。
つまり、Gitはフォルダーではなくファイルのバージョン管理のみを実行するので、理解が容易です。
ローカルコミットをする
主に後のデモンストレーション用のデータを生成するために、ここでsrcに新しいHelloクラス（パッケージパスtop.huashengshu）を作成し、それを
送信ボタンのツールバーの√記号
もちろん、右クリックして送信することもできます。または、上記のVCSオプションバーのgitから送信することもできます。直接送信するには、上のボタンをクリックしてください
ローカル送信の場合は「コミット」をクリックします
リモート送信の場合、次を選択します。
ローカル送信後にログを表示
プロジェクトをgithubのリモートウェアハウスに共有します（ない場合は作成し、ある場合は送信して、ここで直接作成します）。
githubアカウントにログインする必要があります。次のポップアップボックスが表示され、ウェアハウス名、説明、非公開かどうかを入力します
githubのnewに対応
以下に示すように成功後：
アイコンの説明：
緑の枝はローカルの枝を表しています
黄色の1つはヘッドポインタで、黄色のラベルはローカル提出会議の後に移動します
上のスクリーンショットは間違っており、3つのブランチレコードがあり、ヘッドの黄色のマークは現在のブランチの位置を示すためにのみ使用されます。送信すると、ブランチは黄色のマークに従って遅延します。
新しいローカル支店
新しいリモートブランチ
リモートブランチはローカルブランチのプッシュによって生成さ れる必要があります
つまり、プッシュ操作によってブランチの作成がトリガーされます。リモートブランチを送信しておらず、ローカルブランチをリモートにプッシュして新しいブランチを生成する場合は、次の手順に従ってください。
次に、[プッシュ]をクリックして新しいブランチを作成します。以下に示すように、githubに移動して、新しく作成されたブランチを確認します
また、以下のように押すこともできます
さらに、以下を介してプッシュをトリガーできます
さらに、右クリックして新しいリモートブランチの作成をトリガーします
上記はより基本的な分岐操作です
上級部
含む紛争管理、ブランチのロールバック、コミット処理エラー
コードの競合処理
一般的に言って、大規模なプロジェクトは多くの人が共同で開発するもので、Gitを日常業務に使用しながらコードを提出したり、引き下げたりすることがよくあります。
多くの人はプロジェクトを修正するときにいくつかの問題に遭遇します
たとえば、プログラマAが夜間にコードを送信した
翌日、プログラマーAとプログラマーBが出社しました。まず、サーバー上のコードが更新されているかどうか、つまり次の操作を確認します。
したがって、プログラマBが取得するコードは次のとおりです。
プログラマAが仕事に出かけた後、昨夜突然コードにバグがあると思ったので、プログラマAはすぐに修正してコードを提出しました。
プログラマBによる以前のバージョンのgitは、上記のバージョンです。
プログラマAがコードを送信すると、リモートウェアハウスのコードは次のようになります。
プログラマーBは、プログラマーAがコードを再度送信したことを知らないため、プログラマーBが自分のコードを完了した後、プログラマーBのコンピューター上のコードは次のようになります。
現時点では、サーバー上のバージョンが変更されているため、プログラマーAのコードを確実に保持できるようにするため、メインブランチにプッシュする場合、プログラマーは次のようにコードを統合する必要があります。
ここでは、コード行の数が異なるため、それらは直接マージされます。プログラマAとプログラマBは同じクラスを操作しますが、お互いに影響を与えることはなく、直接マージされます。
上記のコミットとプッシュでは、このクラスコードが異なり、背景色が独自のコードであり、リモートサーバーが左側のウィンドウであることが推奨されます。
最終結果：
プログラマBとプログラムAが同じコード行を変更する場合、プログラマAのコードを使用するか、プログラマBのコードを使用するか、または両方を追加するかを手動で確認する必要があります。
サーバーのバージョンが
どちらも更新プロジェクトを実行しました。プログラマーAとプログラマーBはお互いのコードを変更しました。プログラマーAは、最初に次のものを送信します。
Bもコードを変更し、どちらも同じコード行を変更した
最初に提出するようにプログラマAに依頼します。Aは通常どおり提出できます。Bはプロンプトを出します
プログラマーBの操作：
Accept Yoursを選択すると、プログラマAのコードが上書きされます
Accept theirsを選択した場合、プログラマBの行への変更は有効にならず、送信されます。
マージを選択した場合は、手動で選択します（これは、プログラマAによって変更されたコードを知る必要があるため、通常は開発時に選択されます）。
最初に競合を解決する必要があるため、マージの結果は拒否されます。つまり、マージがローカルで実行され、マージ後にコードがリモートにプッシュされます。
現時点では、ボタンを使用して操作することはできません。マージするブランチを選択（リモートウェアハウスをローカルブランチにマージ）してから、ブランチを押し上げる必要があります。
この時点で、成功して理解しやすいことがわかります。マージされたコードは、プログラマーB自身が変更したコードです。gitの場合、これは1人での操作（強調）と同じです。安全で自然と見なされます。正常に送信できます
最終的なgithubは、プログラマーBがマージした後のローカルの現在のマスターブランチでもある必要があります。githubでの最終的な結果を図に示します
説明は成功し、同じコード行を変更するさまざまな状況が解決されました。
この種の競合の場合、ローカルでブランチにマージし、他のユーザーが再度コードを送信しないようにする必要があります。gitでは、一度に1人のユーザーしかコードを変更できません。複数のユーザーがコードを変更する場合でも、一度にコードを変更する必要があります。段落内の1人のユーザーのみがコードを変更でき、他のユーザーはコードを送信します。競合を最初に解決してから送信する必要があります。
プログラマーAが送信を続ける場合、プログラマーBはAの最終バージョンが送信されるのを待つ必要があります。プログラマーBは、リモートウェアハウスからローカルウェアハウスにコードをマージし、競合を解決した後でそれを送信します。プログラマAが提出期間中にコードを再度提出した場合、プログラムBはマージしてから提出する必要があります（ある期間に1人だけが正常に提出できます）。
コードのロールバック操作
プログラマAを例にとります。
プログラマーAのローカルサブミッションレコードは次のとおりです。
まず、ロールバックコードには4つの形式があることを理解する必要があります：ソフト、混合、ハード、保持
ソフト、混合、ハード、キープの違いを区別するには、まずgitがバージョン管理を実行する方法とgitの原理を理解する必要があります。
gitの原則：
Gitはファイルのステータスを判断してバージョン管理を行います。gitはファイルのステータスをどのように判断しますか？Gitはファイルに対してハッシュ値アルゴリズムを実行し、ハッシュアルゴリズムを通じてハッシュ値を取得します。このハッシュ値と現在のヘッド（ヘッドポインター）が指す現在のブランチのハッシュ値を比較します。異なる場合は、現在のファイルが変更されたことを意味します（少なくともヘッドと比較した場合）。
コードを送信すると、現在のハッシュ値が判断され、ローカルで最後に更新されたプロジェクトのハッシュ値と比較されます。まず、リモートウェアハウスから取得した最後のハッシュと、リモートウェアハウスのヘッドが実行したハッシュ値との比較を判断します。一貫性があるかどうかに関係なく、コードはユーザーによってのみ変更されるため、競合は発生しません。そうでない場合は、リモートウェアハウスが誰かによって変更されたため、リモートウェアハウスのヘッドポインタが新しい場所を指し、ハッシュ値は新しいハッシュ値です。
それはCASアルゴリズムのようなビットは、 最初のサービス倉庫ファイルが変更されているかどうかを決定します。
プログラマーBの提出記録の分析：
黄色のラベルと緑と紫のラベルがすべて同じ場所を指していることがわかります
黄色のラベルは、ヘッドポインターが指している提出レコードの場所です。緑のラベルは現在の提出レコードを表します（gitがアップロード操作を実行するとき、最初にローカルで提出します。これは緑色のマークです。提出後、黄色のマークの頭は緑色と同じ位置を指します。 ）
リモートコミットがプッシュされると、特定のブランチレコードにプッシュされます。
このとき、操作を送信する前に、サーバーコードが他のプログラマーによって変更されたかどうか（ハッシュ値を比較することによって）が判断されます。
- つまり、プログラマーBのコンピューターは、ローカルウェアハウスが最後に更新されたときに、最後の更新中に取得したハッシュ値を保存する必要があります。
- この時点で最後のハッシュ値とgithubのハッシュ値を比較します。リモートウェアハウスファイルが変更されているかどうかを確認します。変更されている場合（同じファイルのハッシュ値）。現時点では、ハッシュ値は元のハッシュ値ではありません。その場合、送信する前にgithubウェアハウスをローカルウェアハウスにマージする必要があります。変更がない場合は、githubで誰もコードを変更していないことを意味します。コードを変更したのは1人だけなので、直接送信できます）
Gitには3つの概念があります
- レコードを送信
- バッファエリア
- 作業エリア
ワークスペースは、アイデアがリアルタイムでコードと操作を変更する瞬間です
キャッシュ領域は、git AddコマンドとRollbackコマンドを使用してバージョン管理する必要があるファイルを手動で選択するためのものです。
送信レコードは、ファイルをキャッシュ領域に送信することです
ワークスペースからは送信されませんが、キャッシュの中間層から送信されます
ソフト、ミックス、ハード、キープの違い
アイデアのヒントは
上記の「ファイルは変更されません」は作業領域を指します（つまり、ファイルの内容を変更せずにリアルタイムでファイルを変更します）
ソフトでもミックスでもロールバックできますので、下図のように、選択した位置にヘッドポインタを再実行してください。
ただし、2つのロールバックの違いは、ソフト操作ではキャッシュ内のファイルが取り消されないのに対し、混合するとキャッシュとパーティションのレコードが同じになることです。
次の図に示すように、バッファ領域にファイルを追加することについて話していると仮定して、追加を右クリックします
赤はgitで管理されていないファイルを意味し、キャッシュに追加します
その後、ファイルのステータスが緑色に変わり、ファイルがgitによって管理されていることを示します
ソフトロールバックを実行するだけでは、キャッシュの状態は変化せず、ファイルも変化しません
これは、ロールバックするように選択したレコード位置をヘッドポインターが指しているというだけのソフトと同じです。現在のファイルステータスは次のとおりです。ソフトを通じて2番目の送信位置にロールバックします。
ソフトとミックス
効果を実証するために、一度送信して、このブランチレコードが最初にどのように行われたかを確認します。
ローカルでサブミットするだけで、もう1つのブランチが見つかります。実際には、mixedでもこの効果を達成できます。ヘッドによって実行されるハッシュ値がキャッシュ領域と異なる限り、サブミットを行うことができます
一部のファイルのバージョン管理をキャンセルするなど、ファイルのステータスを変更する場合は、混合を選択できます。選択した瞬間にロールバックされます。バージョン管理されているファイルの場合、現時点でバージョン管理されていないファイルがキャッシュ領域にあると、以下に示すようにバージョン管理の効果がキャンセルされます。最初の瞬間に混ぜたいだけ
統合する場合、前面に接続する必要があります
以下は更新アイテムです。表示されない場合がありますので、更新してください
ハードとキープ
ハードは理解しやすい、つまり必須のロールバックです。この操作により、すべての状態が選択した瞬間にロールバックされ、ファイルは以前の送信に変更され、コードは以前の送信に戻ります。これについてのデモはありません。ローリングは本当にロールバックされました。そして、決して前の状態に戻らないでください。以前のソフトとは異なり、混合
そしてキープ
私の理解では、HARDとKEEPはワークスペースで動作します。
そして、ソフトとミックスはバッファ領域で動作します
実際のケース
プログラマーAは古い従業員です
プログラムBは新入社員です。誤操作により、.ideaフォルダーがリモートウェアハウスのgithubに送信されました。リードプログラマAと他の従業員は、アイデア環境をSDKなどの独自の環境に変更する必要があります。
問題：
IDEAのGit操作を介してリモートウェアハウスgithubから.ideaフォルダーを削除する必要がありますが、プログラマーBによって送信されたコードは削除されません
回答：
私のアプローチは、正しく統合されたコードのみを含み、バージョン管理キャッシュに.ideaフォルダーを含まない、従業員Bのコンピューター上にキャッシュを構築することです
次に、キャッシュ領域を介して新しいブランチを作成し、.ideaフォルダーに誤って送信されたブランチをバイパスします。そして、ブランチをデフォルトのブランチとして設定します
つまり、.ideaフォルダーがバージョン管理に含まれないように混合ロールバックを使用します。混合メソッドはワークスペースのコードを変更しないため、ヘッドポインターはロールバックする場所を指します。もちろん、プロジェクトを更新する必要があります。プログラマーBのローカルウェアハウスにリモートでマージし、混合してから、バージョン管理が必要なファイルをgitバージョン管理に手動で追加します。
プッシュで新しいブランチを作成するのが最善です
以下のように操作します
開始状態
提出が完了していることがgithubで確認でき、現在は再編成されています
現時点では、バージョン管理に含まれておらず、送信されています。次のマージが発生した場合は、通常、バージョンを選択してください。私はここでのシミュレーションなので、実際にはコードはローカルワークスペースに基づいている必要があります。
その後、あなたは押すことができます
成功すると、作成されたnewBranchブランチがgithubに見つかります
次のステップは、彼をデフォルトのブランチとして設定することです（IDEAには対応する操作があるはずです）。
以下のようにブランチを削除したい場合
