1. 初心者向けの Git の詳細ガイド

今日はバージョン管理システム、つまり Git について説明します。

このツールを知り、理解することがなければ、本格的なプログラマーになることはできません。もちろん、継続的に使用するために、Git のすべてのコマンドと機能を頭の中に入れておく必要はありません。何が起こっているかをすべて理解するのに役立つ一連のコマンドを知っておく必要があります。

Git の基本

Git はコードの分散バージョン管理システムです。なぜそれが必要なのでしょうか? チームには、仕事を管理するための何らかのシステムが必要です。時間の経過とともに発生する変化を追跡するために必要です。

つまり、どのファイルがどのように変更されたのかを段階的に確認できる必要があります。これは、単一タスクのコンテキストで何が変更されたかを調査し、変更を元に戻すことができる場合に特に重要です。

次の状況を想像してみましょう。動作するコードがあり、その内容はすべて良好ですが、何かを改善または微調整することにしました。大したことではありませんが、私たちの「改良」によりプログラムの機能の半分が壊れ、動作できなくなりました。んで、どうする？Git がなければ、すべてが元の状態であったことを思い出そうと、何時間も座って考えなければなりません。しかし、Git を使用すると、コミットをロールバックするだけで済みます。

あるいは、2 人の開発者が同時に自分のコードを変更した場合はどうなるでしょうか? Git を使用しない場合は、元のコード ファイルをコピーし、個別に変更します。両方ともメイン ディレクトリに変更を追加したいときが来ます。この場合どうしますか?

Git を使用すればそのような問題は発生しません。

Gitのインストール

コンピュータに Java をインストールしましょう このプロセスは、オペレーティング システムによって若干異なります。

Windows へのインストール

いつものように、exe ファイルをダウンロードして実行する必要があります。ここではすべてが簡単です。最初の Google リンクをクリックし、インストールを実行するだけです。これを行うには、Windows が提供する bash コンソールを使用します。

Windows では、Git Bash を実行する必要があります。[スタート] メニューでは次のように表示されます。

これで、コマンド プロンプトを使用して作業できるようになりました。

Git を開くために毎回プロジェクトのあるフォルダーに移動する必要がないようにするには、必要なパスを指定してマウスの右ボタンでプロジェクト フォルダー内のコマンド プロンプトを開きます。

Linux へのインストール

Git は元々 Linux カーネル開発用に作成されたツールであるため、通常、Git は Linux ディストリビューションの一部であり、すでにインストールされています。しかし、そうでない状況もあります。確認するには、ターミナルを開いて git --version と記述する必要があります。わかりやすい答えが得られた場合は、何もインストールする必要はありません。

ターミナルを開いてインストールします。Ubuntu の場合は、次のように記述する必要があります: sudo apt-get install git。これで、どのターミナルでも Git を使用できるようになります。

macOS にインストールする

ここでも、最初に Git がすでに存在するかどうかを確認する必要があります (Linux の場合と同じ、上記を参照)。

お持ちでない場合は、最新バージョンをダウンロードするのが最も簡単な方法です。Xcode がインストールされている場合、Git は自動的にインストールされます。

Gitの設定

Git には、作業を送信するユーザーのユーザー設定があります。Git はコミットの作成時にこの情報を Author フィールドとして取得するため、これは理にかなっており、必要です。

次のコマンドを実行して、すべてのプロジェクトのユーザー名とパスワードを設定します。

git config --global user.name "Ivan Ivanov" git config --global user.email ivan.ivanov@gmail.com

特定のプロジェクト (個人プロジェクトなど) の作成者を変更する必要がある場合は、「--global」を削除できます。これにより、次のことがわかります。

git config user.name "Ivan Ivanov" git config user.email ivan.ivanov@gmail.com

ちょっとした理論

このトピックに入るには、いくつかの新しい言葉や行動を紹介する必要があります...そうしないと、話すことが何もなくなってしまいます。もちろん、これは英語から来た専門用語なので、括弧内に訳を追加します。

どのような言葉や行動でしょうか？

  • gitリポジトリ
  • 専念
  • ブランチ
  • マージ
  • 衝突
  • 引く
  • 押す
  • 一部のファイル (.gitignore) を無視する方法

等々。

Git のステータス

Git には、理解して覚えておく必要のあるいくつかの像があります。

  • 追跡されていない
  • 修正された
  • 演出された
  • 関与する

これをどのように理解すればよいでしょうか?

これらは、コードを含むファイルに適用されるステータスです。言い換えれば、それらのライフサイクルは通常次のようになります。

  • 作成されてもリポジトリにまだ追加されていないファイルは、「未追跡」ステータスになります。
  • Git リポジトリに既に追加されているファイルに変更を加えると、そのステータスは「変更済み」になります。
  • 変更したファイルの中から必要なものを選択し (たとえば、コンパイル済みクラスは必要ありません)、これらのクラスは「ステージング」ステータスに変更されます。
  • ステージングされた状態で準備されたファイルからコミットが作成され、Git リポジトリに入れられます。その後、「ステージング済み」ステータスのファイルはなくなります。ただし、ステータスが「変更済み」のファイルがまだ存在する可能性があります。

見た目はこんな感じです。

コミットとは何ですか?

バージョン管理に関しては、コミットが主要なイベントです。これには、コミットの開始以降に行われたすべての変更が含まれます。コミットは、単一リンクされたリストのように相互にリンクされます。

具体的には、最初のコミットがあります。2 番目のコミットが作成されると、(2 番目の) コミットは最初のコミットの後に何が来るかを認識します。このようにして、情報を追跡することができます。

コミットには、メタデータと呼ばれる独自の情報もあります。

  • コミットの一意の識別子。コミットを見つけるために使用できます。
  • コミットの作成者の名前 (コミットを作成した人)
  • コミットが作成された日付
  • コミット中に何が行われたかを説明するコメント

その様子は次のとおりです。

支店とは何ですか?

ブランチは、あるコミットへのポインタです。コミットはどのコミットが自分より前にあるかを知っているため、ブランチがコミットを指す場合、以前のすべてのコミットもそのコミットに適用されます。

したがって、同じコミットを指すブランチを必要な数だけ持つことができると言えます。

作業はブランチ内で行われるため、新しいコミットが作成されると、ブランチはポインタをより新しいコミットに移動します。

Git を始める

ローカル リポジトリだけでなく、リモート リポジトリでも作業できます。

必要なコマンドを練習するには、ローカル リポジトリに限定することができます。すべてのプロジェクト情報はローカルの .git フォルダーにのみ保存されます。

Java university

リモート リポジトリについて話している場合、すべての情報はリモート サーバー上のどこかに保存されます。ローカルに保存されるのはプロジェクトのコピーのみです。ローカル コピーに加えられた変更は、リモート リポジトリにプッシュ (git Push) できます。

ここと以下の説明では、コンソールでの Git の操作について説明します。もちろん、何らかの GUI ベースのソリューション (IntelliJ IDEA など) を使用することもできますが、まず、実行されているコマンドとその意味を理解する必要があります。

ローカル リポジトリでの Git の操作

ローカル リポジトリを作成するには、次のように記述する必要があります。

gitの初期化

これにより、コンソールの現在のディレクトリに隠し .git フォルダーが作成されます。

.git フォルダーには、Git リポジトリに関するすべての情報が保存されます。削除しないでください;）

次に、ファイルがプロジェクトに追加され、「未追跡」ステータスが割り当てられます。作業の現在のステータスを確認するには、次のように記述します。

gitステータス

私たちは master ブランチにいます。別のブランチに切り替えるまでここに残ります。

これは、変更されたがまだ「ステージング」ステータスに追加されていないファイルを示します。これらを「staged」ステータスに追加するには、「git add」と記述する必要があります。ここにはいくつかのオプションがあります。たとえば、次のとおりです。

  • git add -A — すべてのファイルを「ステージング」ステータスに追加します
  • git add 。— このフォルダーとすべてのサブフォルダーからすべてのファイルを追加します。基本的には前のものと同じです。
  • git add <file name> — 特定のファイルを追加します。ここでは、正規表現を使用して、特定のパターンに従ってファイルを追加できます。たとえば、 git add *.java: これは、java 拡張子を持つファイルのみを追加することを意味します。

最初の 2 つのオプションは明らかに単純です。最新の機能が追加されるとさらに面白くなるので、次のように書いてみましょう。

git add *.txt

ステータスを確認するには、すでに知られているコマンドを使用します。

gitステータス

ここでは、正規表現が正しく機能していることがわかります。test_resource.txt は「ステージング済み」ステータスになりました。

そして最後に、ローカル リポジトリを操作する最後の段階 (リモート リポジトリを操作する場合はもう 1 つあります ;)) — 新しいコミットを作成します。

git commit -m 「すべての txt ファイルがプロジェクトに追加されました」

次は、ブランチ上のコミット履歴を確認するための優れたコマンドです。それを活用してみましょう:

git ログ

ここでは、最初のコミットが作成されており、コマンドラインで指定したテキストが含まれていることがわかります。このテキストでは、このコミット中に何が行われたかを可能な限り正確に説明する必要があることを理解することが非常に重要です。これは将来何度も役立ちます。

まだ眠りに就いていない好奇心旺盛な読者は、GitTest.java ファイルに何が起こったのか疑問に思っているかもしれません。今すぐ調べてみましょう。これを行うには、以下を使用します。

gitステータス

ご覧のとおり、まだ「追跡されていない」状態で待機中です。しかし、それをプロジェクトにまったく追加したくない場合はどうすればよいでしょうか? 時々そういうことが起こります。

物事をさらに面白くするために、test_resource.txt ファイルを変更してみましょう。そこにテキストを追加してステータスを確認してみましょう。

gitステータス

ここでは、「未追跡」ステータスと「変更済み」ステータスの違いが明確にわかります。

GitTest.java は「未追跡」ですが、test_resource.txt は「変更済み」です。

ファイルが変更された状態になったので、ファイルに加えられた変更を調べることができます。これは、次のコマンドを使用して実行できます。

git diff

つまり、ここで私がテキスト ファイルに追加した内容がはっきりとわかります: hello world!

テキスト ファイルに変更を追加し、コミットを作成しましょう。

git add test_resource.txt
git commit -m 「こんにちは言葉を追加しました!」test_resource.txtへ」

すべてのコミットを確認するには、次のように記述します。

git ログ

ご覧のとおり、現在 2 つのコミットがあります。

同じ方法で GitTest.java を追加します。ここにはコメントはありません。コマンドだけです。

git add GitTest.java
git commit -m “GitTest.java を追加しました”
gitステータス

.gitignore の操作

明らかに、リポジトリにはソース コードのみを保持し、他には何も保持しないでください。それでは、他に何があり得るでしょうか？少なくとも、開発環境によって生成されたコンパイル済みのクラスやファイル。

Git にそれらを無視するように指示するには、特別なファイルを作成する必要があります。これを実行します。プロジェクトのルートに .gitignore というファイルを作成します。このファイルの各行は、無視するパターンを表します。

この例では、.gitignore ファイルは次のようになります。

*.class
ターゲット/
*.iml
.idea/

見てみましょう:

  • 最初の行は、.class 拡張子を持つすべてのファイルを無視します。
  • 2 行目は、「ターゲット」フォルダーとそれに含まれるすべてのものを無視することです。
  • 3 行目は、.iml 拡張子を持つすべてのファイルを無視します。
  • 4 行目は .idea フォルダーを無視します。

例を使ってみましょう。どのように動作するかを確認するために、コンパイルされた GitTest.class をプロジェクトに追加し、プロジェクトのステータスを確認してみましょう。

gitステータス

明らかに、(git add -A を使用して) コンパイルされたクラスを何らかの形で誤ってプロジェクトに追加したくないのは明らかです。これを行うには、.gitignore ファイルを作成し、前に説明したものをすべて追加します。

次に、コミットを使用して .gitignore ファイルをプロジェクトに追加しましょう。

git add .gitignore
git commit -m 「.gitignore ファイルを追加しました」

そして今、正念場です。「追跡されていない」コンパイル済みクラス GitTest.class があり、これを Git リポジトリに追加したくありませんでした。

これで、.gitignore ファイルの効果が確認できるはずです。

gitステータス

完全！.gitignore +1 :)

ブランチの操作

当然のことながら、1 つのブランチだけで作業するのは孤独な開発者にとっては不便であり、チームに複数人がいる場合は不可能です。これが支店がある理由です。

ブランチはコミットへの移動可能なポインタにすぎません。

このパートでは、さまざまなブランチでの作業、つまりあるブランチから別のブランチに変更をマージする方法、どのような競合が発生するかなどについて説明します。

リポジトリ内のすべてのブランチのリストを表示し、自分がどのブランチにいるかを理解するには、次のように記述する必要があります。

git ブランチ -a

master ブランチが 1 つだけあることがわかります。その前のアスタリスクは、その中にいることを示します。ちなみに、「git status」コマンドを使用して、どのブランチにいるかを確認することもできます。

次に、ブランチを作成するためのオプションがいくつかあります (他にもある可能性があります。これらは私が使用しているものです)。

  • 現在いるブランチに基づいて新しいブランチを作成します (99% の場合)
  • 特定のコミットに基づいてブランチを作成する (ケースの 1%)

特定のコミットに基づいてブランチを作成しましょう

コミットの一意の識別子に依存します。それを見つけるには、次のように書きます。

git ログ

「hello world を追加しました...」というコメントを付けてコミットを強調表示しました。その一意の識別子は 6c44e53d06228f888f2f454d3cb8c1c976dd73f8 です。このコミットから開始する「開発」ブランチを作成したいと思います。これを行うには、次のように書きます。

git checkout -b 開発 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

ブランチは、master ブランチからの最初の 2 つのコミットのみを使用して作成されます。これを確認するには、まず別のブランチに切り替えて、そこでのコミット数を確認します。

gitステータス
git ログ

そして予想どおり、コミットが 2 つあります。ところで、ここで興味深い点があります。このブランチにはまだ .gitignore ファイルがないため、コンパイルされたファイル (GitTest.class) は「未追跡」ステータスで強調表示されています。

これで、次のように記述してブランチを再度確認できます。

git ブランチ -a

「master」と「development」の 2 つのブランチがあることがわかります。現在開発中です。

現在のブランチに基づいてブランチを作成しましょう

ブランチを作成する 2 番目の方法は、別のブランチからブランチを作成することです。master ブランチに基づいてブランチを作成したいと考えています。まず、それに切り替える必要があり、次のステップは新しいものを作成することです。見てみましょう:

  • git checkout master — master ブランチに切り替える
  • git status — 実際に master ブランチにいることを確認します

ここでは、master ブランチに切り替え、.gitignore ファイルが有効になり、コンパイルされたクラスが「追跡されていない」として強調表示されなくなっていることがわかります。

次に、master ブランチに基づいて新しいブランチを作成します。

git checkout -b feature/update-txt-files

このブランチが「master」と同じかどうか不明な場合は、「git log」を実行してすべてのコミットを確認することで簡単に確認できます。それらは 4 つあるはずです。

紛争解決

競合とは何かを説明する前に、あるブランチを別のブランチにマージすることについて説明する必要があります。

この図は、あるブランチを別のブランチにマージするプロセスを示しています。

ここに本店があります。ある時点で、メイン ブランチからセカンダリ ブランチが作成され、変更されます。作業が完了したら、一方のブランチをもう一方のブランチにマージする必要があります。

この例では、feature/update-txt-files ブランチを作成しました。ブランチの名前が示すように、テキストを更新しています。

次に、この作業用に新しいコミットを作成する必要があります。

git add *.txt
git commit -m “更新されたtxtファイル”
git ログ

ここで、feature/update-txt-files ブランチをマスターにマージする場合は、マスターに移動して「git merge feature/update-txt-files」と記述する必要があります。

git チェックアウト マスター
git merge 機能/update-txt-files
git ログ

その結果、master ブランチには、feature/update-txt-files に追加されたコミットも含まれるようになりました。

この機能が追加されたため、機能ブランチを削除できるようになります。これを行うには、次のように書きます。

git Branch -D feature/update-txt-files

状況をさらに複雑にしてみましょう。txt ファイルを再度変更する必要があるとします。ただし、このファイルは master ブランチでも変更されるようになります。つまり、並行して変化していきます。新しいコードを master ブランチにマージしたいときに、Git は何をすればよいのかわかりません。

master に基づいて新しいブランチを作成し、text_resource.txt に変更を加えて、この作業のコミットを作成します。

git checkout -b feature/add-header

...ファイルに変更を加えます

git add *.txt
git commit -m 「ヘッダーをテキストに追加しました」

master ブランチに移動し、feature ブランチと同じ行にあるこのテキスト ファイルも更新します。

git チェックアウト マスター

…test_resource.txtを更新しました

git add test_resource.txt
git commit -m 「マスターヘッダーをテキストに追加しました」

ここで最も興味深い点です。feature/add-header ブランチからの変更を master にマージする必要があります。私たちは master ブランチにいるので、次のように書くだけで済みます。

git merge 機能/ヘッダーの追加

ただし、その結果、test_resource.txt ファイル内で競合が発生します。

ここで、Git がこのコードをマージする方法を独自に決定できなかったことがわかります。まず競合を解決し、それからコミットを実行する必要があることがわかります。

OK。競合のあるファイルをテキスト エディタで開くと、次のように表示されます。

ここで Git が何をしたかを理解するには、どの変更をどこに加えたかを覚えて比較する必要があります。

  1. master ブランチのこの行に加えられた変更は、「<<<<<<< HEAD」と「=======」の間にあります。
  2. feature/add-header ブランチ内の変更は、「======= と ">>>>>>> feature/add-header」の間にあります。

これは、Git がファイル内のこの場所でマージを実行する方法を見つけられなかったことを示す方法です。このセクションは異なるブランチから 2 つの部分に分割されており、マージ競合を自分で解決するよう勧められています。

けっこうだ。大胆にもすべてを削除して、「ヘッダー」という単語だけを残すことにしました。

変更状況を見てみましょう。説明は少し異なります。「修正された」ステータスではなく、「統合が解除された」状態です。それでは、5 番目のステータスについて言及できたでしょうか? これは必要ないと思います。どれどれ：

gitステータス

私たちはこれが特別で珍しいケースであると確信できます。続けましょう：

git add *.txt

説明では「git commit」のみを記述することを推奨していることに気づくかもしれません。それを書いてみましょう:

gitコミット

そしてまさにそのようにして、コンソール内の競合を解決しました。

もちろん、統合開発環境ではこれをもう少し簡単に行うことができます。たとえば、IntelliJ IDEA では、すべてが適切にセットアップされているため、その中で必要なアクションをすべて実行できます。しかし、IDE は「内部で」多くのことを実行しており、そこで何が起こっているのか正確に理解できないことがよくあります。そして、理解がないと問題が発生する可能性があります。

リモートリポジトリの操作

最後のステップでは、リモート リポジトリを操作するために必要なコマンドをさらにいくつか理解します。

先ほども述べたように、リモート リポジトリは、リポジトリが保存され、そこからクローンを作成できる場所です。

リモートリポジトリにはどのような種類がありますか? 例:

  • GitHub は、リポジトリと共同開発のための最大のストレージ プラットフォームです。
  • GitLab は、オープンソースを使用した DevOps ライフサイクルのための Web ベースのツールです。これは、独自の Wiki、バグ追跡システム、CI/CD パイプライン、その他の機能を備えたコード リポジトリを管理するための Git ベースのシステムです。
  • BitBucket は、Mercurial および Git バージョン管理システムに基づいたプロジェクト ホスティングおよび共同開発のための Web サービスです。かつては、無料のプライベート リポジトリを提供するという点で、GitHub よりも大きな利点がありました。昨年、GitHub もこの機能を誰でも無料で導入しました。
  • 等々…

リモート リポジトリを使用する場合、最初に行うことは、プロジェクトのクローンをローカル リポジトリに作成することです。

このために、ローカルで作成したプロジェクトをエクスポートしました。これで、誰もが自分でそのプロジェクトのクローンを作成できます。

git clone https://github.com/romankh3/git-demo

これで、プロジェクトの完全なローカル コピーが作成されました。プロジェクトのローカル コピーが最新であることを確認するには、次のように記述してプロジェクトをプルする必要があります。

git プル

私たちの場合、現時点ではリモート リポジトリには何も変更されていないため、応答は次のようになります。「すでに最新です。」

ただし、リモート リポジトリに変更を加えた場合、ローカル リポジトリはプル後に更新されます。

そして最後のコマンドは、データをリモート リポジトリにプッシュすることです。ローカルで何かを実行し、それをリモート リポジトリに送信したい場合は、まずローカルで新しいコミットを作成する必要があります。これを示すために、テキスト ファイルに何かを追加してみましょう。

ここで、私たちにとって非常に一般的なことです。この作業のためにコミットを作成します。

git add test_resource.txt
git commit -m "プッシュ用のテキストを準備しました"

これをリモート リポジトリにプッシュするコマンドは次のとおりです。

gitプッシュ

今のところはここまでです！

役立つリンク

2. IntelliJ IDEA で Git を操作する方法

このパートでは、IntelliJ IDEA で Git を操作する方法を学びます。

必須入力:

  1. 前の部分を読み、従って、理解してください。これにより、すべてがセットアップされ、すぐに使用できるようになります。
  2. IntelliJ IDEA をインストールします。ここではすべてが整っているはずです:)
  3. 完全に習得するには 1 時間を割り当ててください。

Git に関する記事で使用したデモ プロジェクトを使ってみましょう。

プロジェクトのクローンをローカルに作成する

ここには 2 つのオプションがあります。

  1. すでに GitHub アカウントをお持ちで、後で何かをプッシュしたい場合は、プロジェクトをフォークして独自のコピーを複製することをお勧めします。フォークの作成方法については、「フォーク ワークフローの例」という見出しの下の別の記事を参照してください。
  2. リポジトリのクローンを作成し、すべてをサーバーにプッシュすることなく、すべてをローカルで実行します。

GitHub からプロジェクトのクローンを作成するには、プロジェクト リンクをコピーして IntelliJ IDEA に渡す必要があります。

  1. プロジェクトのアドレスをコピーします。

  2. IntelliJ IDEA を開き、「バージョン管理から取得」を選択します。

  3. プロジェクトのアドレスをコピーして貼り付けます。

  4. IntelliJ IDEA プロジェクトを作成するように求められます。オファーを受け入れます:

  5. ビルド システムがないため、「既存のソースからプロジェクトを作成」を選択します。

  6. 次に、この美しい画面が表示されます。

クローン作成について理解したので、見てみましょう。

Git UI としての IntelliJ IDEA の概要

クローンされたプロジェクトを詳しく見てみましょう。バージョン管理システムに関する多くの情報がすでに得られています。

まず、左下隅にバージョン管理ペインがあります。ここでは、すべてのローカル変更を検索し、コミットのリストを取得できます (「git log」に似ています)。

ログの説明に移りましょう。開発がどのように進行したかを正確に理解するのに役立つ特定の視覚化があります。たとえば、txt commit にヘッダーが追加された新しいブランチが作成され、それが master ブランチにマージされたことがわかります。コミットをクリックすると、右隅にコミットに関するすべての情報 (すべての変更とメタデータ) が表示されます。

さらに、実際の変化も確認できます。また、そこで競合が解決されたこともわかります。IDEA もこれを非常によく示しています。

このコミット中に変更されたファイルをダブルクリックすると、競合がどのように解決されたかが表示されます。

左側と右側には、1 つにマージする必要がある同じファイルの 2 つのバージョンがあることがわかります。そして真ん中には、最終的なマージ結果があります。

プロジェクトに多くのブランチ、コミット、ユーザーがある場合は、ブランチ、ユーザー、日付ごとに個別に検索する必要があります。

始める前に、自分がどのブランチにいるのかを理解する方法を説明することも重要です。

右下隅に「Git: master」というラベルのボタンがあります。「Git:」に続くものはすべて現在のブランチです。ボタンをクリックすると、別のブランチへの切り替え、新しいブランチの作成、既存のブランチの名前変更など、さまざまな便利な操作を行うことができます。

リポジトリの操作

便利なホットキー

今後の作業のために、非常に便利なホットキーをいくつか覚えておく必要があります。

  1. CTRL+T — リモート リポジトリから最新の変更を取得します (git pull)。
  2. CTRL+K — コミットを作成/現在の変更をすべて表示します。これには、追跡されていないファイルと変更されたファイル (git commit) の両方が含まれます。
  3. CTRL+SHIFT+K — これは、変更をリモート リポジトリにプッシュするためのコマンドです。ローカルで作成され、リモート リポジトリにまだ存在していないすべてのコミットがプッシュされます (git Push)。
  4. ALT+CTRL+Z — 特定のファイル内の変更を、ローカル リポジトリに作成された最後のコミットの状態にロールバックします。左上隅でプロジェクト全体を選択すると、すべてのファイルの変更をロールバックできます。

私達は何が欲しいのか？

仕事を成し遂げるには、どこでも使われる基本的なシナリオをマスターする必要があります。

目的は、新しい機能を別のブランチに実装し、それをリモート リポジトリにプッシュすることです (その後、メイン ブランチへのプル リクエストを作成する必要もありますが、それはこのレッスンの範囲を超えています)。

これを行うには何が必要ですか?

  1. メイン ブランチ (たとえば、「master」) 内の現在の変更をすべて取得します。

  2. このメイン ブランチから、作業用に別のブランチを作成します。

  3. 新しい機能を実装します。

  4. メイン ブランチに移動し、作業中に新たな変更があったかどうかを確認します。そうでない場合は、すべて問題ありません。ただし、変更があった場合は、次の操作を実行します。作業ブランチに移動し、変更をメイン ブランチから私たちのブランチにリベースします。すべてがうまくいけば、素晴らしいことです。しかし、衝突が起こる可能性は十分にあります。偶然にも、リモート リポジトリで時間を無駄にすることなく、事前に解決することができます。

    なぜこれを行う必要があるのか​​疑問に思いますか? これは良いマナーであり、ブランチをローカル リポジトリにプッシュした後に競合が発生するのを防ぎます (もちろん、依然として競合が発生する可能性はありますが、競合は大幅に小さくなります)。

  5. 変更をリモート リポジトリにプッシュします。

リモートサーバーから変更を取得するにはどうすればよいですか?

新しいコミットの説明を README に追加し、これらの変更を取得したいと考えています。ローカル リポジトリとリモート リポジトリの両方で変更が行われた場合は、マージかリベースのどちらかを選択するよう求められます。私たちは合併することを選択します。

CTRL+T を入力してください:

README がどのように変更されたか、つまりリモート リポジトリからの変更が取り込まれたことがわかります。また、右下隅にはサーバーからの変更の詳細がすべて表示されます。

マスターに基づいて新しいブランチを作成します

ここではすべてがシンプルです。

右下隅に移動して、「Git: master」をクリックします。[+ 新しいブランチ]を選択します。

[チェックアウト ブランチ]チェックボックスを選択したままにし、新しいブランチの名前を入力します。私たちの場合: これはreadme-improverになります。

Git: master はGit: readme-improverに変更されます。

並行作業をシミュレーションしてみよう

競合が発生するには、誰かが競合を作成する必要があります。

ブラウザを介して新しいコミットで README を編集し、並列作業をシミュレートします。私たちが作業している間に誰かが同じファイルに変更を加えたかのようです。その結果、紛争が発生します。10 行目から「fully」という単語を削除します。

機能を実装する

私たちのタスクは、README を変更し、新しい記事に説明を追加することです。つまり、Git での作業は IntelliJ IDEA を経由します。これを追加：

変更が完了しました。これでコミットを作成できるようになりました。CTRL+Kを押すと、次のようになります。

コミットを作成する前に、このウィンドウが何を提供するのかを詳しく調べる必要があります。

「コミットメッセージ」セクションでは、コミットに関連付けられたテキストを記述します。次に、それを作成するには、 「コミット」をクリックする必要があります。

README が変更されたことを記述し、コミットを作成します。左下隅にコミット名を示すアラートがポップアップ表示されます。

main ブランチが変更されたかどうかを確認する

私たちは任務を完了しました。できます。私たちはテストを書きました。すべて順調。ただし、サーバーにプッシュする前に、その間にメイン ブランチに変更があったかどうかを確認する必要があります。どうしてそんなことが起こるのでしょうか？非常に簡単に、誰かがあなたの後にタスクを受け取り、その誰かがあなたのタスクを完了するよりも早くタスクを完了します。

したがって、master ブランチに移動する必要があります。これを行うには、以下のスクリーンショットの右下隅に示されている操作を行う必要があります。

master ブランチでCTRL+Tを押して、リモート サーバーから最新の変更を取得します。変更内容を見ると、何が起こったのかが簡単にわかります。

「fully」という単語が削除されました。おそらくマーケティング部門の誰かがそのように書くべきではないと判断し、開発者にそれを更新するタスクを与えたのでしょう。

これで、master ブランチの最新バージョンのローカル コピーができました。readme-improverに戻ります。

ここで、変更を master ブランチから私たちのブランチにリベースする必要があります。私たちはこれを行います:

すべてを正しく実行し、私の指示に従っていれば、結果として README ファイルに矛盾が表示されるはずです。

ここにも、理解し吸収すべき情報がたくさんあります。ここに示されているのは、競合しているファイル (この例では 1 つのファイル) のリストです。次の 3 つのオプションから選択できます。

  1. あなたのものを受け入れる — readme-improver からの変更のみを受け入れます。
  2. 彼らのものを受け入れる — マスターからの変更のみを受け入れます。
  3. マージ — 何を残し、何を破棄するかを自分で選択します。

何が変わったのかは不明です。master ブランチに変更がある場合は、そこに変更が必要になるため、単純に変更を受け入れることはできません。したがって、「merge」を選択します。

ここでは 3 つの部分があることがわかります。

  1. これらは readme-improver からの変更点です。
  2. 結合した結果。現時点では、これは変更前に存在していたものです。
  3. master ブランチからの変更。

誰もが満足できる統合結果を生み出す必要があります。変更前の変更内容を確認すると、単に「fully」という単語が削除されただけであることがわかります。いいよ、大丈夫！つまり、マージ結果からも削除してから変更を追加します。マージ結果を修正したら、 「適用」をクリックします。

次に、リベースが成功したことを示す通知がポップアップ表示されます。

そこには！最初の競合は IntelliJ IDEA を通じて解決しました。

変更をリモートサーバーにプッシュする

次のステップでは、変更をリモート サーバーにプッシュし、プル リクエストを作成します。これを行うには、CTRL+SHIFT+Kを押すだけです。すると、次のようになります。

左側には、リモート リポジトリにプッシュされていないコミットのリストが表示されます。右側には、変更されたすべてのファイルが表示されます。以上です！Pushを押すと幸せを体験できます:)

プッシュが成功すると、右下隅に次のような通知が表示されます。

ボーナス: プル リクエストの作成

GitHub リポジトリに移動してみましょう。GitHub が私たちが何を望んでいるのかをすでに知っていることがわかります。

[比較とプルリクエスト]をクリックします。次に、「プルリクエストの作成」をクリックします。事前に競合を解決したため、プル リクエストを作成するときにすぐにマージできるようになりました。

今のところはここまでです！