Git 入門: 初心者向けの包括的なガイド

紹介の代わりに

こんにちは！今日はバージョン管理システム、つまり Git について説明します。Git を知らない/理解していなければ、プログラミングとは何の関係もありません。ただし、継続的に使用するために Git のコマンドや機能をすべて頭の中に入れておく必要がないのが利点です。何が起こっているかをすべて理解するのに役立つ一連のコマンドを知っておく必要があります。

Git の基本

Git はコードの分散バージョン管理システムです。なぜそれが必要なのでしょうか? 分散チームには、作業を管理するための何らかのシステムが必要です。時間の経過とともに発生する変化を追跡するために必要です。つまり、どのファイルがどのように変更されたのかを段階的に確認できる必要があります。これは、単一タスクのコンテキストで何が変更されたかを調査し、変更を元に戻すことができる場合に特に重要です。

Gitのインストール

コンピュータに Java をインストールしましょう。

Windows へのインストール

いつものように、exe ファイルをダウンロードして実行する必要があります。ここではすべてが簡単です。最初の Google リンクをクリックし、インストールを実行するだけです。これを行うには、Windows が提供する bash コンソールを使用します。Windows では、Git Bash を実行する必要があります。[スタート] メニューでの表示は次のとおりです。これで、操作できるコマンド プロンプトが表示されます。Git を開くために毎回プロジェクトのあるフォルダーに移動する必要がないようにするには、必要なパスを指定してマウスの右ボタンでプロジェクト フォルダー内のコマンド プロンプトを開きます。

Linux へのインストール

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

macOS にインストールする

ここでも、まず Git がすでに存在するかどうかを確認する必要があります。お持ちでない場合は、ここから最新バージョンをダウンロードするのが最も簡単な入手方法です。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 には、理解して覚えておく必要があるいくつかの像があります。

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

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

これらは、コードを含むファイルに適用されるステータスです。

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

以下にその様子を示します。

コミットとは何ですか?

バージョン管理に関しては、コミットが主要なイベントです。これには、コミットの開始以降に行われたすべての変更が含まれます。コミットは、単一リンクされたリストのように相互にリンクされます。より具体的に言うと、最初のコミットがあります。2 番目のコミットが作成されると、最初のコミットの後に何が来るかを認識します。このようにして、情報を追跡することができます。コミットには、メタデータと呼ばれる独自の情報もあります。

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

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

支店とは何ですか?

ブランチは、あるコミットへのポインタです。コミットはどのコミットが自分より前にあるかを知っているため、ブランチがコミットを指す場合、以前のすべてのコミットもそのコミットに適用されます。したがって、同じコミットを指すブランチを必要な数だけ持つことができると言えます。作業はブランチ内で行われるため、新しいコミットが作成されると、ブランチはポインタをより新しいコミットに移動します。

Git を始める

ローカル リポジトリだけでなく、リモート リポジトリでも作業できます。必要なコマンドを練習するには、ローカル リポジトリに限定することができます。すべてのプロジェクト情報はローカルの .git フォルダーにのみ保存されます。リモート リポジトリについて話している場合、すべての情報はリモート サーバー上のどこかに保存されます。ローカルに保存されるのはプロジェクトのコピーのみです。ローカル コピーに加えられた変更は、リモート リポジトリにプッシュ (git Push) できます。ここと以下の説明では、コンソールでの Git の操作について説明します。もちろん、何らかの GUI ベースのソリューション (IntelliJ IDEA など) を使用することもできますが、まず、実行されているコマンドとその意味を理解する必要があります。

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

次に、記事を読みながら、私が行ったすべての手順を実行することをお勧めします。これにより、教材の理解と習熟度が向上します。さて、食欲をそそります！:) ローカル リポジトリを作成するには、次のように記述する必要があります。

git init

これにより、コンソールの現在のディレクトリに .git フォルダーが作成されます。.git フォルダーには、Git リポジトリに関するすべての情報が保存されます。削除しないでください ;) 次に、ファイルがプロジェクトに追加され、「未追跡」ステータスが割り当てられます。作業の現在のステータスを確認するには、次のように記述します。

git status

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

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

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

git add *.txt

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

git status

ここでは、正規表現が正しく機能していることがわかります。test_resource.txt は「ステージング済み」ステータスになりました。そして最後に、ローカル リポジトリを操作するための最後の段階 (リモート リポジトリを操作する場合はもう 1 つあります ;)) — 新しいコミットを作成します。

git commit -m "all txt files were added to the project"

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

git log

ここでは、最初のコミットが作成されており、コマンドラインで指定したテキストが含まれていることがわかります。このテキストでは、このコミット中に何が行われたかを可能な限り正確に説明する必要があることを理解することが非常に重要です。これは将来何度も役立ちます。まだ眠りに就いていない好奇心旺盛な読者は、GitTest.java ファイルに何が起こったのか疑問に思っているかもしれません。今すぐ調べてみましょう。これを行うには、以下を使用します。

git status

ご覧のとおり、まだ「追跡されていない」状態で待機中です。しかし、それをプロジェクトにまったく追加したくない場合はどうすればよいでしょうか? 時々そういうことが起こります。物事をさらに面白くするために、test_resource.txt ファイルを変更してみましょう。そこにテキストを追加してステータスを確認してみましょう。

git status

ここでは、「未追跡」ステータスと「変更済み」ステータスの違いが明確にわかります。GitTest.java は「未追跡」ですが、test_resource.txt は「変更済み」です。ファイルが変更された状態になったので、ファイルに加えられた変更を調べることができます。これは、次のコマンドを使用して実行できます。

git diff

つまり、ここで私がテキスト ファイルに追加した内容がはっきりとわかります: hello world! テキスト ファイルに変更を追加してコミットを作成しましょう。

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

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

git log

ご覧のとおり、現在 2 つのコミットがあります。同じ方法で GitTest.java を追加します。ここにはコメントはありません。コマンドだけです。

git add GitTest.java
git commit -m "added GitTest.java"
git status

.gitignore の操作

明らかに、リポジトリにはソース コードのみを保持し、他には何も保持しないでください。それでは、他に何があり得るでしょうか？少なくとも、開発環境によって生成されたコンパイル済みのクラスやファイル。Git にそれらを無視するように指示するには、特別なファイルを作成する必要があります。これを実行します。プロジェクトのルートに .gitignore というファイルを作成します。このファイルの各行は、無視するパターンを表します。この例では、.gitignore ファイルは次のようになります。

```
*.class
target/
*.iml
.idea/
```

見てみましょう:

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

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

git status

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

git add .gitignore
git commit -m "added .gitignore file"

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

git status

完全！.gitignore +1 :)

ブランチなどの操作

当然のことながら、1 つのブランチだけで作業するのは孤独な開発者にとっては不便であり、チームに複数人がいる場合は不可能です。これが支店がある理由です。前に述べたように、ブランチはコミットへの移動可能なポインタにすぎません。このパートでは、さまざまなブランチでの作業、つまりあるブランチから別のブランチに変更をマージする方法、どのような競合が発生するかなどについて説明します。リポジトリ内のすべてのブランチのリストを表示し、自分がどのブランチにいるかを理解するには、次のように記述する必要があります。

git branch -a

master ブランチが 1 つだけあることがわかります。その前のアスタリスクは、その中にいることを示します。ちなみに、「git status」コマンドを使用して、現在どのブランチにいるかを確認することもできます。ブランチを作成するためのオプションがいくつかあります (他にもあるかもしれません。これらは私が使用しているものです)。

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

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

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

git log

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

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

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

git status
git log

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

git branch -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 "updated txt files"
git log

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

git checkout master
git merge feature/update-txt-files
git log

その結果、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
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

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

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

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

git merge feature/add-header

しかし、その結果、test_resource.txt ファイル内で競合が発生します。ここでは、Git がこのコードをマージする方法を独自に決定できなかったことがわかります。まず競合を解決し、それからコミットを実行する必要があることがわかります。OK。競合のあるファイルをテキスト エディタで開くと、以下が表示されます。ここで Git が何をしたかを理解するには、どこにどのような変更を加えたかを覚えておいて、比較する必要があります。

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

これは、Git がファイル内のこの場所でマージを実行する方法を見つけられなかったことを示す方法です。このセクションは異なるブランチから 2 つの部分に分割されており、マージ競合を自分で解決するよう勧められています。けっこうだ。大胆にもすべてを削除し、「ヘッダー」という単語だけを残すことにしました。変更のステータスを見てみましょう。説明は少し異なります。「修正された」ステータスではなく、「統合が解除された」状態です。それでは、5 番目のステータスについて言及できたでしょうか? これは必要ないと思います。どれどれ：

git status

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

git add *.txt

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

git commit

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

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

最後のステップでは、リモート リポジトリを操作するために必要なコマンドをさらにいくつか理解します。先ほども述べたように、リモート リポジトリは、リポジトリが保存され、そこからクローンを作成できる場所です。リモートリポジトリにはどのような種類がありますか? 例:

• GitHub は、リポジトリと共同開発のための最大のストレージ プラットフォームです。以前の記事でも説明しました。GitHub
  でフォローしてください。私は仕事のために勉強している分野で自分の作品をそこで披露することがよくあります。

• GitLab は、オープン ソースを使用したDevOpsライフサイクルのための Web ベースのツールです。これは、独自の Wiki、バグ追跡システム、CI/CD パイプライン、その他の機能を備えたコード リポジトリを管理するためのGitベースのシステムです。 Microsoft が GitHub を買収したというニュースの後、一部の開発者はプロジェクトを GitLab に複製しました。
  

• BitBucket は、Mercurial および Git バージョン管理システムに基づいたプロジェクト ホスティングおよび共同開発のための Web サービスです。かつては、無料のプライベート リポジトリを提供するという点で、GitHub よりも大きな利点がありました。昨年、GitHub もこの機能を誰でも無料で導入しました。

• 等々…

リモート リポジトリを使用する場合、最初に行うことは、プロジェクトのクローンをローカル リポジトリに作成することです。このために、ローカルで作成したプロジェクトをエクスポートしました。これで、次のように記述することで、誰もが自分でそのプロジェクトのクローンを作成できるようになりました。

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

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

git pull

私たちの場合、現時点ではリモート リポジトリには何も変更されていないため、応答は次のようになります。「すでに最新です。」ただし、リモート リポジトリに変更を加えると、プルした後にローカル リポジトリが更新されます。そして最後のコマンドは、データをリモート リポジトリにプッシュすることです。ローカルで何かを実行し、それをリモート リポジトリに送信したい場合は、まずローカルで新しいコミットを作成する必要があります。これを実証するために、テキスト ファイルに何か他のものを追加してみましょう。これは私たちにとって非常に一般的なものです。この作業のためのコミットを作成します。

git add test_resource.txt
git commit -m "prepared txt for pushing"

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

git push

まあ、それが私が言いたかったすべてです。ご清聴ありがとうございました。GitHubでフォローしてください。そこでは、私の個人的な研究や仕事に関連したさまざまな素晴らしいサンプル プロジェクトを投稿しています。

便利なリンク

• 公式Git ドキュメント。参考としておすすめします。