今更聞けない！Gitとは何か？仕組みから使い方まで初心者向けに徹底解説

Gitの必要性 ～なぜ今、Gitなのか？～

「別にファイル名に日付やバージョン番号を付けて管理すればいいんじゃない？」そう思う方もいるかもしれません。確かに、個人の小さなプロジェクトであれば、それでもなんとかなる場面もあるでしょう。しかし、プロジェクトが少しでも複雑になったり、複数人で作業したりするようになると、手動でのバージョン管理はすぐに限界を迎えます。

想像してみてください。

• 変更履歴の迷子: 数ヶ月前に変更した内容の意図を思い出せますか？「あの機能を追加する前の状態に戻したいけど、どのファイルがそれだっけ…？」
• 手戻りの恐怖: 新しい機能を実装してみたものの、バグだらけで動かなくなってしまった。元の安定していたバージョンに戻したいけど、どこまで戻せばいいのか、どのファイルが影響を受けているのか分からない…。
• 共同作業の混乱: チームメンバーが同じファイルを同時に編集してしまい、お互いの変更が上書きされて消えてしまった！「誰が最新版を持っているの？」「マージ作業が地獄…」
• バックアップの不安: 大切なファイルが入ったUSBメモリを紛失！あるいは、パソコンが突然クラッシュ！これまでの努力が水の泡に…

これらの問題は、開発の現場では日常茶飯事です。そして、これらの問題を解決するために生まれたのがGitなのです。

特に現代のソフトウェア開発は、スピードと品質が同時に求められます。アジャイル開発のような反復的な開発スタイルが主流となり、短いサイクルで機能追加や修正を繰り返していく中で、変更履歴を正確に管理し、問題発生時に迅速に対応できる体制は不可欠です。

また、リモートワークが普及し、地理的に離れたメンバーと共同作業する機会も増えています。Gitのような分散型バージョン管理システムは、このような働き方にも非常に適しています。

つまり、Gitは単なる「便利なツール」というだけでなく、現代の効率的で安全な開発プロセスを支える「必須のインフラ」と言えるでしょう。プログラミングを学ぶ上で、プログラミング言語そのものと同じくらい、Gitの知識とスキルは重要視されています。

Gitのメリット ～Gitがもたらす恩恵～

Gitを導入することで、具体的にどのようなメリットが得られるのでしょうか？主なものを挙げてみましょう。

1. 詳細な変更履歴の管理と追跡

   Gitは、いつ、誰が、どのファイルのどの部分を、なぜ変更したのかを「コミットメッセージ」と共に記録します。これにより、プロジェクトの歴史が一目瞭然になります。後から「この変更は何のためだったっけ？」と悩むことが減り、バグの原因特定や機能改善の際に非常に役立ちます。

   コミットとは？
   Gitにおける「コミット(commit)」とは、ファイルやディレクトリの変更内容をリポジトリ（保存場所）に記録する操作のことです。セーブポイントを作るようなイメージです。コミット時には、何を変更したのかを示す「コミットメッセージ」を付与します。

2. 過去のバージョンへの簡単な復元

   「やっぱり前のバージョンに戻したい」という時、Gitなら数コマンドで簡単に特定の時点の状態に戻すことができます。重要なファイルを誤って削除してしまったり、意図しない変更を加えてしまったりした場合でも、安心して作業を進められます。これは、まるで「タイムマシン」を手に入れたようなものです。

3. ブランチによる効率的な並行作業

   Gitの最も強力な機能の一つが「ブランチ(branch)」です。ブランチとは、現在の作業状態から分岐させて、独立した作業スペースを作ることです。例えば、

   • 現在の安定版（例：masterブランチ）はそのままに、新しい機能開発用のブランチ（例：feature-Aブランチ）を作る。
   • バグ修正用のブランチ（例：bugfix-001ブランチ）を作って、他の作業に影響を与えずに修正に集中する。

   このように、複数の作業を並行して進めることができ、それぞれが完了したら元のブランチに統合（マージ）することができます。これにより、開発効率が飛躍的に向上します。

4. チームでの円滑な共同作業

   Gitは分散型であるため、各開発者が自分のローカル環境で作業を進め、準備ができたら変更内容を中央のリポジトリ（例：GitHub上のリポジトリ）に共有することができます。誰がどのような変更を行ったかが明確になり、変更内容の衝突（コンフリクト）が発生した場合でも、Gitの機能を使って比較的容易に解決することができます。

5. オフラインでの作業が可能

   分散型であるため、ネットワークに接続されていない環境でも、ローカルリポジトリでコミットを行ったり、ブランチを作成したりといったほとんどの作業が可能です。インターネット環境が不安定な場所や、移動中でも作業を続けられます。

6. 軽量かつ高速な動作

   Gitは非常に効率的に設計されており、大規模なプロジェクトでも軽快に動作します。ブランチの作成や切り替え、コミットといった基本的な操作は一瞬で完了することが多く、ストレスなく作業に集中できます。

7. データの完全性の確保

   Gitは、すべてのファイルやコミットに対して「ハッシュ値」と呼ばれるチェックサムを生成し、データの整合性を常にチェックしています。これにより、ファイルが知らぬ間に破損したり改ざんされたりすることを防ぎます。

8. 豊富なエコシステムとコミュニティ

   Gitは世界中で広く使われているため、学習リソースが豊富に存在します。また、GitHub、GitLab、BitbucketといったGitをホスティングするサービスも充実しており、これらを利用することで、より便利にGitを活用できます。困ったときには、インターネットで検索すれば多くの解決策が見つかるでしょう。

Gitのデメリット ～知っておきたい注意点～

多くのメリットがあるGitですが、いくつかのデメリットや注意点も存在します。これらを理解しておくことも重要です。

1. 学習コストがかかる

   Gitは非常に多機能で、独自の概念（リポジトリ、コミット、ブランチ、マージ、ステージングエリアなど）が多くあります。これらを理解し、使いこなせるようになるまでには、ある程度の学習時間と実践が必要です。特に最初のうちは、コマンドの意味や操作の流れに戸惑うことが多いかもしれません。

   ステージングエリア（インデックス）とは？
   コミットする変更を選択するための一時的な場所です。ファイル全体ではなく、ファイルの一部の変更だけをコミットすることも可能です。「カゴに入れる」ようなイメージで、コミットしたい変更をまずステージングエリアに追加します。

2. コマンドライン操作への慣れが必要な場合がある

   Gitの全ての機能を利用するには、コマンドラインインターフェース（CUI）での操作が基本となります。GUIツール（グラフィカルユーザーインターフェースを持つツール）も存在し、初心者にとってはとっつきやすいですが、複雑な操作やトラブルシューティングの際には、結局コマンドラインの知識が必要になることが多いです。

3. コンフリクトの解決が難しい場合がある

   複数人で同じファイルの同じ箇所を編集した場合、「コンフリクト（衝突）」が発生します。Gitはコンフリクトを検知してくれますが、それをどのように解決するかは人間が判断する必要があります。特に複雑なコンフリクトの場合、解決に手間取ることがあります。

   コンフリクトは怖いものではありません！Gitが「ここ、複数の人が違う変更をしたけど、どっちが正しい？」と教えてくれているサインです。落ち着いて対処すれば大丈夫です。

4. 大きなバイナリファイルの扱いは得意ではない

   Gitは主にテキストファイルの差分を効率的に管理するように設計されています。そのため、画像ファイル、動画ファイル、実行ファイルといった大きなバイナリファイルのバージョン管理にはあまり向いていません。これらのファイルをGitで管理すると、リポジトリのサイズが非常に大きくなり、動作が遅くなる原因となります。（Git LFSという拡張機能で対応することも可能です）

5. 誤った操作によるリスク

   強力なツールである反面、操作を誤ると意図しない結果を招く可能性もあります。例えば、強制的なプッシュ（git push --force）などで他の人の変更を上書きしてしまったり、重要なブランチを誤って削除してしまったりするリスクです。ただし、Gitには多くの安全装置や復旧手段も用意されています。

これらのデメリットは、Gitの学習を進め、経験を積むことで克服できるものがほとんどです。最初から完璧を目指す必要はありません。少しずつ、できることから始めていきましょう。

Gitのインストール

Gitを利用するためには、まずお使いのコンピュータにGitをインストールする必要があります。OSごとにインストール方法が異なります。

Windowsの場合

1. Git for Windows のダウンロード: 公式サイト git-scm.com からインストーラーをダウンロードします。通常は「Standalone Installer」の64-bit版を選べば問題ありません。
2. インストール: ダウンロードしたインストーラーを実行し、指示に従ってインストールを進めます。多くの設定項目がありますが、最初のうちはデフォルトのままで問題ありません。特に以下の点は確認しておくと良いでしょう。
   • Choosing the default editor used by Git: Gitがコミットメッセージなどを編集する際に使うエディタを選びます。普段使っているエディタ（VS Codeなど）があればそれを選択し、なければデフォルトのVimのままでも構いませんが、Vimは操作に癖があるので注意が必要です。
   • Adjusting your PATH environment: 「Git from the command line and also from 3rd-party software」が推奨です。これにより、コマンドプロンプトやPowerShellなどからGitコマンドが使えるようになります。
3. インストールの確認: インストール後、コマンドプロンプトまたはGit Bash（Git for Windowsと一緒にインストールされる専用のコマンドラインツール）を開き、以下のコマンドを入力してバージョン情報が表示されれば成功です。

   git --version

   例: git version 2.43.0.windows.1 のように表示されます。

Macの場合

Macにはいくつかのインストール方法があります。

1. Xcode Command Line Tools を利用する方法 (推奨):

   ターミナルを開き、以下のコマンドを入力します。

   git --version

   　

   もしGitがインストールされていなければ、「command line developer tools をインストールしますか？」というダイアログが表示されるので、「インストール」をクリックして進めます。これにはGitが含まれています。

   すでにインストールされている場合は、バージョン情報が表示されます。

2. Homebrew を利用する方法:

   パッケージマネージャーのHomebrewを使っている場合は、ターミナルで以下のコマンドを実行します。

   brew install git

   　

3. 公式サイトからインストーラーをダウンロードする方法:

   公式サイト git-scm.com からインストーラーをダウンロードして実行することも可能です。

4. インストールの確認: ターミナルを開き、以下のコマンドを入力してバージョン情報が表示されれば成功です。

   git --version

   　

Linux (Debian/Ubuntu系) の場合

ターミナルを開き、以下のコマンドを実行します。

sudo apt update
sudo apt install git

インストールの確認:

git --version

Linux (Fedora/RHEL/CentOS系) の場合

ターミナルを開き、以下のコマンドを実行します。

sudo dnf install git  # Fedora の場合
sudo yum install git  # RHEL/CentOS の場合

インストールの確認:

git --version

これで、あなたのコンピュータでGitが使えるようになりました！

Gitの初期設定

Gitをインストールしたら、最初にいくつかの基本的な設定を行っておく必要があります。特に、ユーザー名とメールアドレスの設定は必須です。これらの情報は、あなたがコミット（変更の記録）を行う際に、「誰が変更したのか」を示すために使われます。

ターミナル（Windowsの場合はGit Bashやコマンドプロンプト、MacやLinuxの場合はターミナル）を開き、以下のコマンドを一行ずつ実行してください。"Your Name" と "your_email@example.com" の部分は、ご自身の名前に置き換えてください。GitHubなどのサービスに登録している場合は、そこで使っているものと同じにすると分かりやすいでしょう。

git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"

--global
オプションを付けることで、このコンピュータ上の全てのGitリポジトリでこの設定が使われるようになります。プロジェクトごとに異なる名前やメールアドレスを使いたい場合は、そのプロジェクトのディレクトリ内で --global を付けずに設定します。

設定内容を確認するには、以下のコマンドを実行します。

git config --global user.name
git config --global user.email

あるいは、すべての設定一覧を見ることもできます。

git config --list

他にも、デフォルトのエディタを設定したり、改行コードの扱いを設定したりすることもできますが、まずはユーザー名とメールアドレスの設定が最も重要です。

リポジトリの作成 ～冒険の始まり～

Gitでバージョン管理を始めるには、まず「リポジトリ(repository)」を作成する必要があります。リポジトリとは、プロジェクトのファイルやディレクトリ、そしてそれらの変更履歴などをまとめて格納しておく「保管庫」のようなものです。Gitの操作は、基本的にこのリポジトリに対して行われます。

リポジトリを作成する方法は、主に2つあります。

1. 新しいプロジェクトのために、ローカルに新規リポジトリを作成する。
2. 既に存在するリモートリポジトリ（例: GitHub上のプロジェクト）を、ローカルにコピー（クローン）してくる。

ここでは、まず1つ目の「新規リポジトリを作成する」方法を見ていきましょう。

1. 新規ローカルリポジトリの作成 (git init)

あなたのコンピュータ上で、新しくバージョン管理を始めたいプロジェクト用のフォルダがあるとします。例えば、MyProject という名前のフォルダを作り、その中でGitの管理を始めたい場合の手順です。

1. プロジェクトフォルダを作成し、そこに移動します。

   ターミナルで以下のコマンドを実行します。（フォルダ名はお好きなものにしてください）

   mkdir MyProject  # MyProjectという名前のフォルダを作成
   cd MyProject     # MyProjectフォルダに移動

   　

2. Gitリポジトリを初期化します。

   MyProject フォルダの中で、以下のコマンドを実行します。

   git init

   これを実行すると、ターミナルに以下のようなメッセージが表示されます（表示内容はGitのバージョンや環境によって多少異なります）。

   Initialized empty Git repository in /path/to/your/MyProject/.git/

   これで、MyProject フォルダがGitリポジトリとして初期化されました！ このフォルダの中に .git という隠しフォルダが作成されます（通常は見えません）。この .git フォルダに、変更履歴や設定情報など、Gitが管理するための全ての情報が格納されます。この .git フォルダは絶対に手動で編集したり削除したりしないでください。

たったこれだけです！ これで、MyProject フォルダ内のファイルの変更をGitで追跡できるようになりました。まだファイルは何もない空っぽの状態ですが、最初の「保管庫」ができたというわけです。

2. 既存のリモートリポジトリのクローン (git clone)

もう一つの方法は、既にGitHubなどのリモートサーバー上に存在するGitリポジトリを、自分のローカル環境に丸ごとコピーしてくる方法です。これを「クローン(clone)」と呼びます。

例えば、GitHub上にある有名なオープンソースプロジェクトに参加したい場合や、チームメンバーが作成したリポジトリで作業を始めたい場合などに使います。

クローンするには、対象リポジトリのURL（通常はHTTPS形式かSSH形式）が必要です。GitHubのリポジトリページに行くと、緑色の「Code」ボタンからURLをコピーできます。

ターミナルで、リポジトリをクローンしたい場所に移動し（例えば、デスクトップなど）、以下のコマンドを実行します。[リポジトリのURL] の部分を実際のURLに置き換えてください。

git clone [リポジトリのURL]

例えば、Bootstrapという有名なCSSフレームワークのリポジトリをクローンする場合は以下のようになります。

git clone https://github.com/twbs/bootstrap.git

これを実行すると、bootstrap という名前のフォルダが作成され、その中にリポジトリの全てのファイルと変更履歴がダウンロードされます。そして、この bootstrap フォルダは自動的にGitリポジトリとして初期化されています（.git フォルダが内部に作られています）。

git clone を使うと、リモートリポジトリとの連携設定（origin という名前でリモートが登録される）も自動的に行われるため、すぐに git pull や git push といったコマンドでリモートと同期できるようになります。

最初のうちは、まず自分で新しいプロジェクトフォルダを作り、git init でリポジトリを初期化してみることから始めるのがおすすめです。実際にファイルを作成し、変更を加えて、コミットしていくという一連の流れを体験することで、Gitの基本的な操作に慣れることができます。

GUIツールかCUI（コマンドライン）か？

Gitを操作する方法には、大きく分けて2つのアプローチがあります。

• CUI (Command Line Interface): ターミナル（コマンドプロンプトやGit Bashなど）でGitコマンドを直接入力して操作する方法。
• GUI (Graphical User Interface): マウス操作で視覚的にGitを操作できる専用のアプリケーションソフトウェアを使う方法。

GUIツール

GUIツールは、Gitの操作をグラフィカルな画面で行えるため、初心者にとってはコマンドを覚える手間が少なく、直感的に理解しやすいというメリットがあります。代表的なGUIツールには以下のようなものがあります。

• SourceTree: Atlassian社（JiraやBitbucketの開発元）が提供する無料のGitクライアント。WindowsとMacに対応しており、高機能で人気があります。
• GitHub Desktop: GitHubが公式に提供しているクライアント。GitHubとの連携がスムーズで、シンプルな操作性が特徴です。WindowsとMacに対応。
• GitKraken: 美しいUIと高機能を兼ね備えた有償（無料版もあり）のGitクライアント。Windows, Mac, Linuxに対応。
• VS Code (Visual Studio Code) のGit連携機能: 人気のテキストエディタであるVS Codeには、強力なGit連携機能が組み込まれており、エディタ内で多くのGit操作をGUIで行えます。
• その他IDEのGit統合機能: IntelliJ IDEA, PhpStorm, Eclipseなど、多くの統合開発環境（IDE）にもGitクライアント機能が搭載されています。

これらのツールを使うと、ブランチの構造を視覚的に確認したり、変更差分（diff）を分かりやすく表示したり、複雑なマージ操作をサポートしてくれたりします。

CUI (コマンドライン)

一方、CUIでの操作は、最初はとっつきにくいかもしれませんが、以下のようなメリットがあります。

• Gitの全機能を利用できる: GUIツールは全てのGitコマンドを網羅しているわけではありません。CUIならGitが提供する全ての機能にアクセスできます。
• 処理が高速: 一般的にGUIツールよりもCUIの方が動作が軽快です。
• 自動化しやすい: シェルスクリプトなどと組み合わせて、Git操作を自動化することが容易です。
• 環境を選ばない: サーバー環境など、GUIが使えない環境でもCUIなら操作できます。
• Gitの仕組みを深く理解できる: コマンドを直接叩くことで、Gitが内部で何をしているのかをより深く理解する助けになります。

どちらを選ぶべき？

「どちらが良い」と一概には言えません。それぞれのメリットを理解し、状況や好みに応じて使い分けるのが理想的です。

初心者の方へのおすすめ:

1. まずはCUIで基本的なコマンドをいくつか覚えて、Gitのコアな概念を理解する。（add, commit, push, pull, branch, checkout, merge, status, log など）
2. その上で、GUIツールも試してみて、日々の作業で便利だと感じる部分で活用する。 例えば、変更差分の確認やブランチの全体像の把握などにはGUIツールが非常に役立ちます。
3. 複雑な操作やトラブルシューティングが必要になった場合は、CUIに戻って対応する。

VS CodeのようなエディタのGit統合機能は、CUIとGUIの良いとこ取りとも言え、コードを書きながらシームレスにGit操作を行えるため、非常に人気があります。

最終的にはCUIでの操作に慣れておくと、Gitをより深く、より柔軟に使いこなせるようになります。しかし、最初から全てをCUIでやろうとして挫折してしまうよりは、GUIツールをうまく活用しながら、徐々にCUIにも慣れていくという進め方が現実的かもしれません。

このブログでは、主にCUIでのコマンド例を中心に解説していきますが、GUIツールを使う場合でも、裏側では同じようなコマンドが実行されているということを意識すると、理解が深まるでしょう。

git init ～物語の始まり～

意味: 新しいGitリポジトリを作成（初期化）します。

使い方:

git init

解説:
このコマンドは、カレントディレクトリをGitリポジトリとして設定します。実行すると、.git というサブディレクトリが作成され、Gitがバージョン管理を行うために必要なファイルや設定が格納されます。このコマンドは、新しいプロジェクトを開始する際に最初に一度だけ実行します。

例:
MyNewProject というフォルダを作成し、その中でGit管理を始めたい場合。

mkdir MyNewProject
cd MyNewProject
git init

これで、MyNewProject フォルダがGitリポジトリになりました。

git clone [リポジトリのURL] ～仲間を増やす～

意味: 既存のリモートリポジトリ（例: GitHub上のリポジトリ）をローカル環境に複製（クローン）します。

使い方:

git clone https://github.com/user/repository.git

解説:
指定したURLのリポジトリを丸ごとダウンロードし、ローカルに同じ名前のディレクトリを作成して、その中に展開します。このディレクトリは自動的にGitリポジトリとして初期化され、リモートリポジトリとの接続情報（origin という名前で登録される）も設定されます。これにより、すぐに git pull や git push が可能になります。

例:
あるオープンソースプロジェクトのリポジトリを自分の手元に持ってきたい場合。

git clone https://github.com/some-opensource/project.git

カレントディレクトリに project というフォルダが作成され、その中にリポジトリの内容が展開されます。

特定のフォルダ名を指定してクローンすることも可能です。

git clone https://github.com/some-opensource/project.git MyLocalProjectName

この場合、MyLocalProjectName という名前のフォルダにクローンされます。

git status ～現状把握～

意味: リポジトリ内のファイルの状態（変更されたファイル、ステージングされたファイルなど）を表示します。

使い方:

git status

解説:
このコマンドは、Gitを使う上で最も頻繁に利用するコマンドの一つです。現在のブランチ名、コミットされていない変更があるファイル、ステージングエリア（インデックス）に追加されているファイル、まだGitによって追跡されていない新しいファイルなどを教えてくれます。次に何をすべきかのヒントも表示されることが多いです。

表示される主な状態:

• Changes to be committed: ステージングエリアに追加されていて、次のコミットに含まれる変更。
• Changes not staged for commit: 作業ディレクトリで変更されたが、まだステージングされていない変更。
• Untracked files: Gitがまだ追跡していない新しいファイル。
• nothing to commit, working tree clean: 全ての変更がコミット済みで、作業ディレクトリに変更がないクリーンな状態。

例:
README.md というファイルを変更し、newfile.txt という新しいファイルを作成した場合、git status を実行すると、これらのファイルの状態が表示されます。

git add [ファイル名 or ディレクトリ名] ～変更を記録の準備～

意味: 指定したファイルの変更内容を、次のコミットに含めるためにステージングエリア（インデックス）に追加します。

使い方:

git add myfile.txt                 # myfile.txt をステージング
git add myfolder/                  # myfolder 内の全ての変更をステージング
git add .                          # カレントディレクトリ以下の全ての変更をステージング (注意して使用)
git add -p                         # 変更箇所を一つ一つ確認しながら対話的にステージング

解説:
Gitでは、ファイルを変更しただけでは自動的にコミットの対象にはなりません。まず git add コマンドを使って、「この変更を次のコミットに含めますよ」という意思表示をする必要があります。これにより、変更内容がステージングエリアという一時的な場所に送られます。

ステージングエリアを使うことで、複数のファイルに変更を加えた場合でも、コミットしたい変更だけを選択してコミットすることができます。例えば、ファイルAとファイルBを変更したけれど、今回はファイルAの変更だけをコミットしたい、という場合に便利です。

git add . は非常に便利ですが、意図しないファイルまでステージングしてしまう可能性があるので、実行前に git status で状態を確認する癖をつけると良いでしょう。

例:
index.html と style.css を変更し、script.js を新しく作成した場合。

git add index.html
git add style.css
git add script.js

または、まとめてステージングする場合:

git add .

git commit -m "コミットメッセージ" ～歴史を刻む～

意味: ステージングエリアに追加された変更内容を、ローカルリポジトリに記録（保存）します。

使い方:

git commit -m "最初のコミット：プロジェクトの初期ファイルを追加"

解説:
git add でステージングした変更を、実際にリポジトリの歴史の一コマとして記録するのが git commit です。各コミットには、その変更内容を説明する「コミットメッセージ」を必ず付ける必要があります。-m オプションは、コマンドラインで直接メッセージを指定する方法です。

コミットメッセージは、後から変更履歴を見たときに「このコミットは何をしたのか」を理解するための非常に重要な手がかりになります。具体的で分かりやすいメッセージを書くように心がけましょう（例：「ユーザー登録機能のバグ修正」「ヘッダーのデザイン変更」など）。

-m オプションを付けずに git commit だけを実行すると、設定されたテキストエディタ（デフォルトではVimなど）が起動し、そこでコミットメッセージを入力することになります。複数行の詳細なメッセージを書きたい場合はこちらの方が便利です。

例:
index.html と style.css の変更をステージングした後、コミットする。

git add index.html style.css
git commit -m "ウェブサイトの基本的なレイアウトを作成"

これで、ローカルリポジトリに変更が記録されました。この時点ではまだリモートリポジトリ（GitHubなど）には反映されていません。

git log ～歴史を振り返る～

意味: これまでのコミット履歴を表示します。

使い方:

git log
git log --oneline                  # 各コミットを1行で簡潔に表示
git log --graph                    # ブランチの分岐やマージの様子をアスキーアートで表示
git log -p                         # 各コミットの変更内容（パッチ）も表示
git log --author="Your Name"       # 特定の作者のコミットのみ表示
git log myfile.txt                 # myfile.txt に関連するコミットのみ表示

解説:
git log を実行すると、新しいコミットから順に、コミットのハッシュ値（各コミットの一意なID）、作者、日時、コミットメッセージなどが表示されます。プロジェクトがどのように変更されてきたかを確認するのに非常に便利です。

多くのオプションがあり、表示形式をカスタマイズしたり、特定の条件で絞り込んだりできます。--oneline や --graph は特によく使われます。

ログ表示を終了するには、q キーを押します（lessコマンドの操作に準じます）。

例:
プロジェクトのコミット履歴を1行で確認したい場合。

git log --oneline

出力例:

c1a2b3d (HEAD -> main) Add new feature X
e4f5g6h Fix bug in login page
a7b8c9d Initial commit

git branch ～平行世界を作る～

意味: ブランチの作成、一覧表示、削除などを行います。

使い方:

git branch                         # ローカルブランチの一覧を表示（現在のブランチに * が付く）
git branch [ブランチ名]              # 新しいブランチを作成
git branch -d [ブランチ名]           # マージ済みのブランチを削除
git branch -D [ブランチ名]           # マージされていないブランチを強制的に削除 (注意して使用)
git branch -a                      # ローカルブランチとリモート追跡ブランチの一覧を表示
git branch -m [旧ブランチ名] [新ブランチ名] # ブランチ名を変更

解説:
ブランチは、Gitの強力な機能の一つで、開発の主軸となる流れ（例: main や master ブランチ）から分岐して、独立した作業を行うためのものです。新しい機能の開発、バグ修正、実験的な試みなどを、他の作業に影響を与えることなく安全に進めることができます。

git branch [ブランチ名] で新しいブランチを作成しても、現在の作業ブランチは移動しません。作成したブランチに移動するには、後述する git checkout または git switch コマンドを使います。

例:
feature-login という名前の新しいブランチを作成し、一覧を表示する。

git branch feature-login
git branch

出力例:

  feature-login
* main

* が付いている main が現在のブランチであることを示します。

git checkout [ブランチ名 or コミットハッシュ] / git switch [ブランチ名] ～世界を移動する～

意味: 作業するブランチを切り替える、または特定のコミットの状態に戻します。

使い方 (ブランチ切り替え):

git checkout [既存のブランチ名]        # 指定したブランチに切り替える
git checkout -b [新しいブランチ名]     # 新しいブランチを作成して、そのブランチに切り替える (branch + checkout)

# Git 2.23以降では、より分かりやすいコマンドが導入されました
git switch [既存のブランチ名]          # 指定したブランチに切り替える (推奨)
git switch -c [新しいブランチ名]       # 新しいブランチを作成して、そのブランチに切り替える (推奨)

使い方 (特定のコミットに戻る/ファイル復元):

git checkout [コミットハッシュ]         # 指定したコミットの状態にする（HEADが分離した状態になる）
git checkout [コミットハッシュ] -- [ファイル名] # 特定のファイルの過去のバージョンを復元

解説:
git checkout は多機能なコマンドで、ブランチの切り替えだけでなく、作業ツリーのファイルを特定の状態に戻すためにも使われます。最近のGitバージョン (2.23以降) では、ブランチ操作専用の git switch と、ファイル復元専用の git restore が導入され、役割が明確になりました。可能であれば git switch の使用を推奨します。

ブランチを切り替えると、作業ディレクトリ内のファイルが、そのブランチの最新のコミットの状態に変わります。まだコミットしていない変更がある場合は、切り替え前にコミットするか、git stash で一時退避させる必要があります。

例:
feature-login ブランチに切り替える。

git checkout feature-login

または (推奨):

git switch feature-login

新しい new-feature ブランチを作成し、すぐにそのブランチに移動する。

git checkout -b new-feature

または (推奨):

git switch -c new-feature

git merge [ブランチ名] ～世界を統合する～

意味: 指定したブランチの変更内容を、現在のブランチに取り込み（統合し）ます。

使い方:

# まず、取り込み先のブランチ（例: main）に移動する
git switch main

# 次に、取り込みたいブランチ（例: feature-login）を指定してマージする
git merge feature-login

解説:
例えば、feature-login ブランチでログイン機能の開発が完了したとします。その成果を主軸の main ブランチに反映させたい場合に git merge を使います。まず main ブランチに移動（switch または checkout）してから、git merge feature-login を実行すると、feature-login ブランチでの変更が main ブランチに取り込まれます。

マージにはいくつかの方法がありますが、Gitは可能な限り自動でマージしようとします。もし、異なるブランチで同じファイルの同じ箇所が編集されていた場合、「コンフリクト（衝突）」が発生します。この場合は、手動でコンフリクトを解決し、再度コミットする必要があります。

コンフリクトが発生した場合の対処 (概要):

1. git status でコンフリクトしているファイルを確認。
2. コンフリクトしたファイルを開くと、<<<<<<<, =======, >>>>>>> といったマーカーで衝突箇所が示されている。
3. マーカーを参考に、どちらの変更を残すか、あるいは両方を組み合わせるかなどを編集して修正する。
4. 修正後、git add [コンフリクトしたファイル名] で解決したことをGitに伝える。
5. 全てのコンフリクトを解決したら、git commit を実行してマージを完了させる（通常、コミットメッセージは自動で生成される）。

コンフリクトの解決は最初は難しく感じるかもしれませんが、慣れれば大丈夫です。落ち着いて対処しましょう。

git pull [リモート名] [ブランチ名] ～最新情報を取り込む～

意味: リモートリポジトリの最新の変更内容を取得し、現在のローカルブランチにマージします。

使い方:

git pull origin main   # originリモートのmainブランチの最新情報を取得し、現在のブランチにマージ
git pull               # 現在のブランチがリモートの特定のブランチを追跡している場合、省略可能

解説:
git pull は、内部的に2つの操作を行っています。

1. git fetch: リモートリポジトリの最新の情報をローカルにダウンロードします（ローカルの作業ファイルは変更されません）。リモート追跡ブランチ（例: origin/main）が更新されます。
2. git merge: ダウンロードした最新の情報（例: origin/main）を、現在のローカルブランチ（例: main）にマージします。

チームで開発している場合、他の人がリモートリポジトリにプッシュした変更を取り込むために、作業を始める前や定期的に git pull を実行するのが一般的です。これにより、常に最新の状態で作業を進めることができ、後々のマージコンフリクトを減らすことにも繋がります。

もしローカルでコミットしていない変更がある状態で git pull を実行し、リモートの変更と衝突する可能性がある場合は、エラーになることがあります。その場合は、ローカルの変更をコミットするか、git stash で一時退避させてから再度 git pull を試みます。

例:
GitHub上の origin リポジトリの main ブランチの最新の変更を、現在のローカルの main ブランチに取り込む。

git switch main      # mainブランチにいることを確認
git pull origin main

git push [リモート名] [ブランチ名] ～自分の変更を共有する～

意味: ローカルリポジトリのコミットを、リモートリポジトリにアップロード（共有）します。

使い方:

git push origin main      # ローカルのmainブランチの変更を、originリモートのmainブランチにプッシュ
git push origin feature-x # ローカルのfeature-xブランチを、originリモートに新しく作成してプッシュ
git push                  # 現在のブランチがリモートの特定のブランチを追跡している場合、省略可能

解説:
ローカルでコミットした変更は、まだ自分のコンピュータ上にしか存在しません。git push を使うことで、これらの変更をGitHubなどのリモートリポジトリに送信し、他のチームメンバーと共有したり、バックアップしたりすることができます。

初めてローカルブランチをリモートにプッシュする場合（例えば、新しく作った feature-x ブランチを初めてプッシュする場合）は、git push -u origin feature-x (または git push --set-upstream origin feature-x) のように -u オプションを付けると、ローカルの feature-x ブランチがリモートの origin/feature-x ブランチを追跡するようになり、次回からは git push だけで済むようになります。

プッシュする前に、リモートリポジトリが自分より新しいコミットを持っている可能性があります（他の誰かがプッシュした場合など）。その状態でプッシュしようとすると、エラー（non-fast-forward error）になります。この場合は、まず git pull でリモートの変更を取り込んでマージし、コンフリクトがあれば解決してから再度 git push を試みます。

例:
ローカルの main ブランチで行ったコミットを、origin という名前のリモートリポジトリの main ブランチにプッシュする。

git push origin main

git remote -v / git remote add ～遠隔地との繋がり～

意味: リモートリポジトリの管理（一覧表示、追加、削除など）を行います。

使い方:

git remote -v                                # 登録されているリモートリポジトリの一覧とURLを表示
git remote add [リモート名] [リポジトリのURL]  # 新しいリモートリポジトリを登録
git remote remove [リモート名]                 # 登録されているリモートリポジトリを削除
git remote rename [旧リモート名] [新リモート名] # リモートリポジトリ名を変更
git remote show [リモート名]                   # 特定のリモートリポジトリの詳細情報を表示

解説:
Gitは分散型バージョン管理システムなので、ローカルリポジトリは複数のリモートリポジトリと連携することができます。git remote コマンドは、これらのリモートリポジトリの「ニックネーム」と実際のURLを管理します。

git clone でリポジトリを作成した場合、通常は origin という名前でクローン元のリポジトリが自動的に登録されます。git remote -v でこれを確認できます。

自分で git init したローカルリポジトリを、後からGitHubなどに作成した空のリモートリポジトリに接続したい場合は、git remote add を使います。

例:
origin という名前でリモートリポジトリ https://github.com/user/myproject.git を登録する。

git remote add origin https://github.com/user/myproject.git

登録後、git remote -v で確認すると、以下のように表示されます。

origin  https://github.com/user/myproject.git (fetch)
origin  https://github.com/user/myproject.git (push)

これで、origin という名前を使って、このリモートリポジトリに対して git pull や git push ができるようになります。