最初のGitコマンドはこれ！初心者が迷わない使い方ガイド

By /

最初のGitコマンドはこれ！初心者が迷わない使い方ガイド【詳細解説】

ようこそ、バージョン管理の世界へ！

あなたがプログラミング学習を始めたばかりでも、ウェブサイト制作に挑戦中でも、あるいは単に文章や設定ファイルの変更履歴を効率的に管理したいと考えているだけでも、Gitは強力な味方になってくれます。

Gitは、あなたのプロジェクトの変更履歴を記録し、管理するためのツールです。これにより、いつでも過去の状態に戻したり、複数の人が同時に一つのプロジェクトで作業したり、新しい機能を安全に試したりすることが可能になります。

しかし、「Gitって難しいんでしょ？」「コマンドラインなんて触ったことない…」そう思っていませんか？

確かに、Gitにはたくさんのコマンドがあり、最初は少し戸惑うかもしれません。でも、安心してください。Gitを使い始めるのに、すべてのコマンドを知っている必要はありません。まずは、本当に基本的な、そして最もよく使うコマンドをいくつか覚えるだけで十分です。

この記事では、Gitを使ったバージョン管理の第一歩を踏み出すあなたのために、以下の点を徹底的に解説します。

  1. Gitとは何か？なぜ使うのか？
  2. Gitを使うための準備（インストールと初期設定）
  3. いよいよ最初のGitコマンド！リポジトリの作成 (git init)
  4. Gitの基本ワークフローを理解する（Working Directory, Staging Area, Repository）
  5. 変更の追跡 (git status)
  6. 変更をステージングする (git add)
  7. 変更をコミットする (git commit)
  8. 履歴を確認する (git log)
  9. もしもの時のために：基本的な「元に戻す」方法
  10. 一歩進んで：リモートリポジトリとの連携（GitHubなど）
  11. もう一歩進んで：ブランチの基本的な使い方
  12. 初心者がつまずきやすいポイントと対処法

この記事を読み終える頃には、あなたは自信を持ってGitを使い始め、プロジェクトの管理がずっと楽になっているはずです。さあ、 Gitの世界へ飛び込みましょう！

1. Gitとは何か？なぜ使うのか？

Gitは、分散型バージョン管理システム（Distributed Version Control System, DVCS）です。

「バージョン管理システム」とは、ファイルやディレクトリの変更履歴を記録し、管理するためのシステムのことです。例えるなら、WordやExcelで「名前を付けて保存」を繰り返すようなものですが、それをより効率的、自動的、かつ賢く行うツールです。

「分散型」とは、プロジェクトの完全な履歴が、中央サーバーだけでなく、関わる開発者一人ひとりのコンピューター上にも保存される仕組みを指します。これにより、ネットワークに接続していなくても作業ができたり、中央サーバーに何か問題が発生してもデータが失われにくいという利点があります。

なぜGitを使うべきなのか？

Gitを使うことには、多くのメリットがあります。

  • 変更履歴の記録と追跡: いつ、誰が、何を変更したのかを詳細に記録できます。これにより、「あの機能を追加する前の状態に戻したい」といった要望に簡単かつ安全に応えられます。
  • 過去の状態への復元: いつでもプロジェクトの特定の状態（コミット）に瞬時に戻ることができます。これは、大きな変更を加えて問題が発生した場合などに非常に役立ちます。
  • 複数人での共同作業: 複数の開発者が同じプロジェクトの異なる部分を同時に作業し、後でそれらを安全に統合（マージ）することができます。Gitが変更の衝突を検出し、解決を助けてくれます。
  • ブランチによる並行作業: メインの開発ラインから「ブランチ」を分岐させ、新しい機能開発やバグ修正を隔離された環境で行えます。これにより、メインの開発に影響を与えることなく、実験的な作業や並行開発を進めることができます。作業が完了したら、その変更をメインラインに取り込むことができます。
  • バックアップ: リモートリポジトリ（GitHub, GitLab, Bitbucketなど）にプッシュすることで、プロジェクトの履歴をクラウド上に安全にバックアップできます。ローカルのコンピューターに何かあっても安心です。
  • 効率的な開発: 変更点を比較したり、誰がどのコードを書いたかを確認したりするツールが揃っており、開発効率を向上させます。

プログラミングやチーム開発においては、今やGitはデファクトスタンダードと言っても過言ではありません。Gitを使えることは、開発者としての必須スキルになりつつあります。

2. Gitを使うための準備（インストールと初期設定）

Gitを使い始めるには、まずあなたのコンピューターにGitをインストールする必要があります。インストール自体は非常に簡単です。

インストールの手順

お使いのOSに合わせて、以下の手順でインストールしてください。

  • Windows:

    1. Git公式サイトのダウンロードページ (https://git-scm.com/downloads) にアクセスします。
    2. Windows用のインストーラーをダウンロードします。
    3. ダウンロードした.exeファイルを実行します。
    4. インストーラーの指示に従って進めます。特にこだわりがなければ、基本的にデフォルト設定のままで問題ありません。「Adjusting your PATH environment」の画面では、「Git from the command line, and also from 3rd-party software」を選択することをお勧めします。これにより、コマンドプロンプトやPowerShellからGitコマンドが使えるようになります。
    5. インストール完了後、コマンドプロンプトまたはPowerShellを開き、以下のコマンドを入力してGitのバージョンが表示されるか確認します。
      bash
      git --version
      バージョン情報が表示されれば成功です。

  • macOS:
    macOSには、Xcode Command Line Toolsに含まれる形でGitがプリインストールされていることが多いです。ターミナルを開き、以下のコマンドを入力して確認してみてください。
    bash
    git --version
    バージョン情報が表示されれば、インストールは不要です。もし表示されない場合や、より新しいバージョンが必要な場合は、以下のいずれかの方法でインストールします。

    • Homebrewを使う (推奨): Homebrewがインストール済みであれば、ターミナルで以下のコマンドを実行します。
      bash
      brew install git
    • 公式サイトからインストーラーをダウンロード: Git公式サイト (https://git-scm.com/downloads) からmacOS用のインストーラーをダウンロードして実行します。
      インストール後、再度 git --version で確認してください。

  • Linux (Debian/Ubuntu系):
    ターミナルを開き、以下のコマンドを実行します。
    bash
    sudo apt update
    sudo apt install git
    インストール後、git --version で確認してください。

  • Linux (Fedora/CentOS/RHEL系):
    ターミナルを開き、以下のコマンドを実行します。
    bash
    sudo dnf install git # Fedora 22以降
    # または
    sudo yum install git # CentOS/RHELなど
    インストール後、git --version で確認してください。

初期設定 (git config)

Gitを使い始める前に、あなたの名前とメールアドレスを設定しておきましょう。これらの情報は、あなたがどのコミットを行ったかを識別するために使用され、コミット履歴に記録されます。これは必須の設定です。

ターミナル（Windowsの場合はGit Bash、コマンドプロンプト、またはPowerShell）を開き、以下のコマンドを実行します。Your Name と [email protected] の部分は、あなたの実際の名前とメールアドレスに置き換えてください。

bash
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

--global オプションは、この設定があなたのコンピューター上のすべてのGitリポジトリに適用されることを意味します。プロジェクトごとに異なる名前やメールアドレスを使いたい場合は、--global オプションを付けずにリポジトリ内で設定することも可能です。

設定が正しく行われたか確認するには、以下のコマンドを使用します。

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

これで、Gitを使うための準備は完了です！

3. いよいよ最初のGitコマンド！リポジトリの作成 (git init)

Gitを使う上で最も基本的な単位はリポジトリ（Repository）です。リポジトリとは、特定のプロジェクトのファイル群と、それらの変更履歴すべてを格納する場所です。リポジトリを作成することで、Gitはそのプロジェクトのバージョン管理を開始します。

新しいプロジェクトでGitを使い始めたい場合、そのプロジェクトのディレクトリで実行する最初のGitコマンドが git init です。

git init コマンドの使い方

新しいプロジェクトディレクトリを作成し、その中に移動します。

“`bash

例: my_new_projectという名前のディレクトリを作成し、移動する

mkdir my_new_project
cd my_new_project
“`

このディレクトリの中で、以下のコマンドを実行します。

bash
git init

git init を実行すると何が起こるのか？

このコマンドを実行すると、Gitは現在のディレクトリをGitリポジトリとして初期化します。具体的には、そのディレクトリ内に.gitという名前の隠しディレクトリが作成されます。

Initialized empty Git repository in /path/to/your/project/my_new_project/.git/

このように表示されれば成功です。

この.gitディレクトリには、プロジェクトのすべての変更履歴、設定、ブランチ情報など、Gitがバージョン管理を行うために必要な情報がすべて格納されています。この.gitディレクトリの中身を自分で編集したり、削除したりしてはいけません。 Gitが内部的に管理している重要なデータです。

これで、my_new_project ディレクトリとそのサブディレクトリにあるファイルは、Gitによるバージョン管理の対象となりました。しかし、この時点ではまだ何も変更履歴は記録されていません。

4. Gitの基本ワークフローを理解する（Working Directory, Staging Area, Repository）

git initでリポジトリを作成したディレクトリ内には、大きく分けて3つの状態（領域）を意識する必要があります。この3つの状態を理解することが、Gitの基本的なワークフローを理解する鍵となります。

  1. Working Directory (作業ディレクトリ):
    これは、あなたが普段ファイルを作成したり編集したりする、目に見えるプロジェクトのディレクトリそのものです。このディレクトリで行ったファイルの変更は、まだGitによって追跡されている状態ではありません。

  2. Staging Area (ステージングエリア、インデックス):
    Working Directoryでの変更の中から、「次のコミットに含めたい変更」を選択し、一時的に置いておく場所です。ステージングエリアは、コミットする内容を準備するための「控え室」のようなものです。Gitでは、変更をコミットする前に、必ずこのステージングエリアを経由させる必要があります。

  3. Repository (Gitディレクトリ、ローカルリポジトリ):
    これは、先ほどgit initで作成された.gitディレクトリのことです。ステージングエリアにある変更を「コミット」することで、その時点でのプロジェクトの状態が確定され、スナップショットとしてこの領域に永続的に記録されます。この領域が、プロジェクトの完全な変更履歴を保持しています。

基本的なワークフローの流れ

Gitを使った作業の基本的な流れは以下のようになります。

  1. Working Directoryでファイルを編集する。（変更が発生）
  2. git status コマンドで変更点を確認する。
  3. git add <ファイル名> コマンドで、次のコミットに含めたい変更をStaging Areaに移動させる。（変更をステージングする）
  4. 再び git status コマンドで、ステージングされた変更を確認する。
  5. git commit -m "コミットメッセージ" コマンドで、Staging Areaにある変更をRepositoryに記録する。（コミットを作成する）
  6. このサイクルを繰り返す。

このワークフローは、慣れるまで少し時間がかかるかもしれませんが、Gitの強力さはこの仕組みに基づいています。特にStaging Areaの概念は、他のバージョン管理システムにはないGitの特徴であり、コミットの内容を柔軟にコントロールするために非常に重要です。

次のセクションからは、このワークフローで実際に使うコマンドを具体的に見ていきましょう。

5. 変更の追跡 (git status)

git status コマンドは、現在のWorking DirectoryとStaging Areaの状態を確認するために使います。プロジェクトの「今」がどうなっているのかを知る上で、最も頻繁に使うコマンドの一つです。

git status コマンドの使い方

リポジトリのルートディレクトリ（.gitディレクトリがある場所）で、以下のコマンドを実行します。

bash
git status

git status の出力例とその意味

git status の出力は、現在のリポジトリの状態によって変化します。いくつか例を見てみましょう。

  • 初期状態（何も変更していない）:
    “`
    On branch main
    Your branch is up to date with ‘origin/main’.

    nothing to commit, working tree clean
    ``
    これは、現在のブランチが    main（またはmaster`）であり、Working Directoryに変更がなく、コミットすべきものも何もない、つまり「きれいな状態」であることを示しています。

  • 新しいファイルを作成したが、まだGitに認識させていない:
    例えば、index.htmlという新しいファイルを作成したとします。git statusを実行すると、以下のようになります。
    “`
    On branch main
    Your branch is up to date with ‘origin/main’.

    Untracked files:
    (use “git add …” to include in what will be committed)

        index.html

    nothing added to commit but untracked files present (use “git add” to track)
    ``
    出力の    Untracked files:のセクションにindex.htmlが表示されています。これは、Gitがこのファイルに気づいているけれど、まだ一度もバージョン管理の対象にしていない（追跡していない）ことを意味します。次に説明するgit add` コマンドを使って、このファイルを追跡対象にする必要があります。

  • 既存のファイルを変更したが、まだステージングしていない:
    例えば、以前コミットしたファイル（例: style.css）を編集したとします。
    “`
    On branch main
    Your branch is up to date with ‘origin/main’.

    Changes not staged for commit:
    (use “git add …” to update what will be committed)
    (use “git restore …” to discard changes in working directory)

        modified:   style.css

    no changes added to commit (use “git add” and/or “git commit -a)”)
    ``
    出力の    Changes not staged for commit:のセクションにmodified: style.cssと表示されています。これは、style.cssファイルに変更があるが、まだStaging Areaに移動させていない（ステージングしていない）ことを意味します。この変更を次のコミットに含めるには、git add style.cssを実行する必要があります。また、この変更を破棄したい場合は、git restore style.css` を使うようにヒントが表示されています。

  • 変更をステージングしたが、まだコミットしていない:
    例えば、index.html を作成し git add index.html を実行した後や、style.css を編集し git add style.css を実行した後などです。
    “`
    On branch main
    Your branch is up to date with ‘origin/main’.

    Changes to be committed:
    (use “git restore –staged …” to unstage)

        new file:   index.html
    modified:   style.css

    ``
    出力の    Changes to be committed:のセクションに、次のコミットに含まれる予定の変更が表示されています。ここではindex.htmlが新規ファイルとして、style.cssが変更ファイルとしてステージングされていることがわかります。この状態でgit commitを実行すると、これらの変更が1つのコミットとして記録されます。もしステージングを取り消したい場合は、git restore –staged ` を使うようにヒントが表示されています。

git status コマンドは、あなたが今、Gitワークフローのどの段階にいるのか、次に何をすべきかのヒントを与えてくれます。何か迷ったら、まずは git status を実行する癖をつけましょう。

6. 変更をステージングする (git add)

Working Directoryで行った変更（新しいファイルの作成、既存ファイルの編集や削除）を、次のコミットに含めるためには、それらの変更をStaging Areaに移動させる必要があります。この操作を行うのが git add コマンドです。

なぜ「ステージング」が必要なのか？

Git初心者が最初につまずきやすいポイントの一つが、この「ステージング」の概念です。「どうして変更したファイルをそのままコミットできないの？」と思うかもしれません。

ステージングの利点は以下の通りです。

  • コミット内容の選択: 複数のファイルを変更した場合でも、その中の特定の一部のファイルだけをコミットに含めることができます。
  • ファイル内の部分的な変更をコミット: さらに高度な使い方として、一つのファイル内の変更の一部だけをステージングし、残りの変更は次のコミットに回す、といったことも可能です（git add -p オプションを使います。最初は知らなくても大丈夫です）。
  • コミット前の最終確認: ステージングエリアの状態を確認することで、意図しない変更をコミットしてしまうのを防ぐことができます。

つまり、ステージングエリアは、次のコミットの「内容」を細かく組み立てるための作業場なのです。

git add コマンドの使い方

git add コマンドは、引数としてステージングしたいファイルやディレクトリのパスを指定します。

  • 特定のファイルをステージング:
    bash
    git add index.html
    git add css/style.css
    複数のファイルを指定することも可能です。
    bash
    git add index.html css/style.css js/main.js

  • ディレクトリ内のすべての変更をステージング:
    特定のディレクトリ以下の新規ファイル、変更、削除をすべてステージングする場合。
    bash
    git add css/

  • 現在のディレクトリ以下のすべての変更をステージング:
    Working Directoryで行ったすべての変更（新規ファイル、変更、削除）を一括でステージングする場合に、最もよく使われる方法です。
    bash
    git add .
    このコマンドは、. が現在のディレクトリを意味するため、現在のディレクトリ以下のすべての追跡対象ファイルと追跡されていない新規ファイルの変更をステージングします。ただし、意図しないファイル（ビルド生成物や設定ファイルなど）までステージングしないように注意が必要です。後述する.gitignoreファイルを使うことで、特定のファイルをGitの管理対象から外すことができます。

git add 実行後の状態

git add を実行しても、画面には特に何も表示されないことが多いです（エラーがない限り）。変更が正しくステージングされたかを確認するには、必ず git status コマンドを使用します。

ステージングされた変更は、git status の出力で Changes to be committed: のセクションに表示されます。

これで、次のステップである「コミット」の準備が整いました。

7. 変更をコミットする (git commit)

Staging Areaにステージングされた変更を、Gitリポジトリに正式な変更履歴として記録する操作をコミット（Commit）と呼びます。コミットは、プロジェクトの特定時点でのスナップショットとして記録されます。

git commit コマンドの使い方

ステージングエリアにコミットしたい変更がある状態で、以下のコマンドを実行します。

bash
git commit

このコマンドを実行すると、Gitはあなたのデフォルトのエディタ（設定していなければ通常はVimなど）を起動し、コミットメッセージの入力を求められます。

コミットメッセージ

コミットメッセージは、そのコミットでどのような変更を行ったのかを説明する非常に重要な情報です。チームで開発する場合だけでなく、一人で開発する場合でも、後から履歴を見返したときに変更内容を理解するために不可欠です。

コミットメッセージの慣習として、以下のような書き方が推奨されます。

  • 1行目: 変更内容の要約を簡潔に書く（50文字以内が目安）。動詞から始め、何をどうしたのかを具体的に書く。「変更しました」のような抽象的な表現は避ける。
  • 2行目: 空白行を入れる。
  • 3行目以降: 変更の詳細、背景、技術的な詳細などを詳しく書く。

エディタが開いたら、1行目に要約、3行目以降に詳細を記述し、ファイルを保存してエディタを閉じます。Gitがその内容をコミットメッセージとして記録します。

もっと簡単なコミット方法 (-m オプション)

簡単な変更の場合や、メッセージを一行で済ませたい場合は、-m オプションを使ってコマンドライン上で直接メッセージを指定できます。

bash
git commit -m "Add initial index.html file"

この方法でコミットメッセージを入力するのが、初心者には最も手軽でお勧めです。

よくある -am オプション (少し注意)

時々、-am というオプションを目にするかもしれません。

bash
git commit -am "Update styles and script"

これは、git add . と git commit -m "..." を同時に行うコマンドのように見えますが、正確には少し異なります。-a オプションは、既にGitによって追跡されている（一度でもコミットされたことがある）ファイルの変更を自動的にステージングしてからコミットします。新規ファイルは-aではステージングされません。

初心者のうちは、まず git add . で変更をステージングし、git status でステージング内容を確認してから git commit -m "..." する、という手順を意識的に踏むことをお勧めします。これにより、意図しないファイルや変更をコミットしてしまうミスを防ぐことができます。慣れてきたら -am も便利ですが、新規ファイルには適用されないことを覚えておきましょう。

コミットの重要性

コミットは、あなたのプロジェクトの「セーブポイント」のようなものです。小さな機能追加、バグ修正、設定変更など、作業の区切りごとにこまめにコミットすることが推奨されます。こうすることで、後から特定の変更内容を見返したり、問題が発生した場合に容易にそのコミットの状態に戻ったりすることができます。

良いコミット習慣を身につけましょう！

8. 履歴を確認する (git log)

プロジェクトの変更履歴を確認するには、git log コマンドを使用します。これにより、これまでに作成されたコミットの一覧を時系列で見ることができます。

git log コマンドの使い方

リポジトリのルートディレクトリで、以下のコマンドを実行します。

bash
git log

git log の出力例

git log を実行すると、最新のコミットから順に、以下の情報が表示されます。

“`
commit f0e1c2d3b4a5e6f7g8h9i0j1k2l3m4n5o6p7q8r9 (HEAD -> main, origin/main)
Author: Your Name your.email@example.com
Date: Tue Oct 26 10:00:00 2023 +0900

Add basic layout and styles

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t (origin/develop)
Author: Another User another.user@example.com
Date: Mon Oct 25 15:30:00 2023 +0900

Implement user authentication feature

commit 1234567890abcdef1234567890abcdef12345678
Author: Your Name your.email@example.com
Date: Sun Oct 24 09:00:00 2023 +0900

Initial commit

“`

  • commit: 40文字の英数字の羅列は、そのコミットを一意に識別するハッシュ値です。このハッシュ値を使って、特定のコミットを参照したり操作したりできます。括弧内の HEAD -> main, origin/main は、現在作業しているブランチ（main）やリモート追跡ブランチ（origin/main）がどのコミットを指しているかを示しています。
  • Author: そのコミットを行った人の名前とメールアドレスです（git config --global user.name と user.email で設定した情報）。
  • Date: コミットが作成された日時です。
  • コミットメッセージ: git commit -m "..." やエディタで入力したメッセージが表示されます。

git log は、一度に多くのコミットが表示される場合があり、終了するには q キーを押します。

git log の便利なオプション

git log には、出力をカスタマイズするための便利なオプションがたくさんあります。初心者のうちによく使うものをいくつか紹介します。

  • --oneline: 各コミットを1行で簡潔に表示します。長いハッシュ値の代わりに短縮版のハッシュ値が表示され、履歴全体を把握しやすくなります。
    bash
    git log --oneline
    出力例:
    f0e1c2d (HEAD -> main, origin/main) Add basic layout and styles
    a1b2c3d (origin/develop) Implement user authentication feature
    1234567 Initial commit

  • --graph: ブランチとマージの履歴をテキスト形式のグラフで表示します。複数人で作業したり、ブランチを使ったりするようになると、履歴の構造を視覚的に理解するのに非常に役立ちます。--oneline と組み合わせて使うことが多いです。
    bash
    git log --graph --oneline

  • --all: 現在のブランチだけでなく、ローカルおよびリモートのすべてのブランチの履歴を含めて表示します。
    bash
    git log --all --graph --oneline
    これは、プロジェクト全体の履歴を把握するのに便利なコマンドです。

  • -p: 各コミットで具体的にどのようなファイルが変更され、どの行が追加/削除されたか（差分、diff）を表示します。
    bash
    git log -p

Gitの履歴は、プロジェクトの進化の記録です。git log を使って、これまでの歩みを振り返ってみましょう。

9. もしもの時のために：基本的な「元に戻す」方法

Gitを使っていると、「あ！間違えた！」という状況が必ず発生します。Gitは強力なバージョン管理システムなので、多くの場合、間違えても安全に元の状態に戻すことができます。ここでは、初心者がよく使う基本的な「元に戻す」方法をいくつか紹介します。

a) Working Directory での変更を元に戻す (まだ git add していない変更)

ファイルを編集したけれど、その変更はやっぱり不要だった、という場合です。この変更はまだStaging AreaにもRepositoryにも記録されていません。

git status で確認すると、Changes not staged for commit: のセクションに表示されている状態です。

この状態の変更を破棄して、最後にコミットまたはステージングした時の状態に戻すには、git restore コマンドを使用します。

bash
git restore <ファイル名>

例えば、index.html の編集内容を破棄したい場合は、以下のコマンドを実行します。

bash
git restore index.html

注意: このコマンドは、Working Directoryで行ったステージングされていない変更を完全に破棄します。一度実行すると元には戻せないので、慎重に行ってください。

b) Staging Area から変更を取り消す (ステージングしたけど、まだコミットしていない変更)

git add で変更をStaging Areaに移動させたけれど、次のコミットに含めるのはやめたい、という場合です。

git status で確認すると、Changes to be committed: のセクションに表示されている状態です。

このステージングを取り消して、Working Directoryに戻すには、git restore --staged コマンドを使用します。

bash
git restore --staged <ファイル名>

例えば、index.html のステージングを取り消したい場合は、以下のコマンドを実行します。

bash
git restore --staged index.html

このコマンドはステージングを取り消すだけで、Working Directoryでの実際のファイルの変更内容はそのまま残ります。ステージングを取り消した変更は、git status で Changes not staged for commit: のセクションに表示されるようになります。

補足: 以前は git reset HEAD <ファイル名> というコマンドがステージング取り消しによく使われていましたが、Gitのバージョン2.23以降は git restore --staged が推奨されています。

c) 直前のコミットメッセージを修正する

最後のコミットのメッセージに間違いを見つけた場合など、最新のコミットメッセージだけを修正したい場合は、git commit --amend コマンドを使用します。

bash
git commit --amend

このコマンドを実行すると、デフォルトのエディタが開き、直前のコミットメッセージが表示されます。メッセージを編集し、保存してエディタを閉じると、直前のコミットが新しいメッセージで「上書き」されます。

もし、直前のコミットでファイルをいくつかステージングし忘れたことに気づき、それも含めてコミットし直したい場合は、以下の手順で行います。

  1. ステージングし忘れたファイルを git add でステージングする。
  2. git commit --amend を実行する。

これにより、ステージングエリアに追加されたファイルも、元々のコミットに含められたかのように修正されます。

注意: git commit --amend は、直前のコミットを「置き換える」操作です。これにより、元のコミットのハッシュ値も変更されます。まだ誰とも共有していないローカルの最新コミットに対してのみ使用してください。一度リモートリポジトリにプッシュしたコミットに対して --amend を使うと、共同作業者に混乱を招く可能性があります（この場合の対処はより複雑になります）。

これらの基本的な「元に戻す」方法は、日々の開発作業で役立つはずです。もし何か大きな間違いをしてしまい、どうすればいいか分からなくなった場合は、落ち着いて git status を確認し、インターネットで「Git 元に戻す [状況]」のように検索するか、経験のある人に助けを求めましょう。Gitには強力な回復機能がありますが、複雑な操作は慎重に行う必要があります。

10. 一歩進んで：リモートリポジトリとの連携（GitHubなど）

これまでは、あなたのコンピューターの中だけでGitを使ってきました（ローカルリポジトリ）。しかし、Gitの真価は、リモートリポジトリと連携することで発揮されます。リモートリポジトリは、インターネット上や組織のネットワーク内にある、プロジェクトの共有リポジトリです。GitHub, GitLab, Bitbucketなどが代表的なリモートリポジトリホスティングサービスです。

リモートリポジトリと連携することで、以下のことが可能になります。

  • コードのバックアップ: プロジェクトの履歴を安全な場所に保管できます。
  • 共同開発: 複数の開発者が同じプロジェクトで共同作業できます。
  • コードの公開: 自分のプロジェクトを世界中に公開できます。

ここでは、リモートリポジトリとの基本的な連携方法として、既存のリポジトリをクローンする方法と、ローカルリポジトリをリモートにプッシュする方法を紹介します。

a) 既存のリモートリポジトリをクローンする (git clone)

他の人が作成したリポジトリや、GitHubなどに公開されているプロジェクトに参加したい場合、そのリモートリポジトリの内容を自分のローカルコンピューターにコピーしてくる必要があります。この操作をクローン（Clone）と呼び、git clone コマンドを使用します。

git clone コマンドは、リモートリポジトリのURLを引数に取ります。

bash
git clone <リモートリポジトリのURL>

例えば、GitHubにあるReactプロジェクトのリポジトリをクローンする場合、URLを指定して実行します。

bash
git clone https://github.com/facebook/react.git

このコマンドを実行すると、以下のことが起こります。

  1. 指定したURLのリモートリポジトリの内容が、現在のディレクトリ以下に新しいディレクトリとしてコピーされます（例: react）。
  2. コピーされたディレクトリは、自動的にGitリポジトリとして初期化されます（つまり、.gitディレクトリが作成されます）。
  3. リモートリポジトリは、デフォルトで origin という名前で設定されます。
  4. リモートリポジトリのメインブランチ（通常は main または master）の最新状態が、ローカルの作業ディレクトリにチェックアウトされます。

これで、あなたはローカルでそのプロジェクトの作業を開始できます。クローンされたリポジトリは、すでにリモートとの関連付けが設定されているため、すぐにプッシュやプルが可能です。

b) ローカルリポジトリをリモートにプッシュする (git push)

あなたがローカルで作成したリポジトリ（git init で作ったもの）を、新しく作成したリモートリポジトリ（GitHubなどで空のリポジトリを作成）にアップロードしたい場合、まずローカルリポジトリにリモートリポジトリの場所を教えてあげる必要があります。

リモートリポジトリを追加する (git remote add)

ローカルリポジトリにリモートの情報を追加するには、git remote add コマンドを使用します。

bash
git remote add <リモートの名前> <リモートリポジトリのURL>

慣習として、最初のメインリモートは origin という名前にすることが多いです。

“`bash

例: GitHubで新しい空のリポジトリを作成し、表示されるURLを使用

git remote add origin https://github.com/your_username/your_project.git
“`

このコマンドを実行しても特に何も表示されませんが、ローカルリポジトリが origin という名前で指定したリモートリポジトリと関連付けられました。

設定されたリモートを確認するには、git remote -v コマンドを使用します。

“`bash
git remote -v

出力例:

origin https://github.com/your_username/your_project.git (fetch)

origin https://github.com/your_username/your_project.git (push)

“`

ローカルの変更をリモートに送信する (git push)

ローカルでコミットした変更をリモートリポジトリに送信して反映させる操作をプッシュ（Push）と呼び、git push コマンドを使用します。

初めてローカルリポジトリをリモートにプッシュする場合、どのリモートのどのブランチにプッシュするかを指定する必要があります。

bash
git push -u <リモートの名前> <ローカルブランチの名前>

origin というリモートの main ブランチをプッシュする場合のコマンドです。

bash
git push -u origin main

-u オプション（または --set-upstream）は、ローカルの main ブランチが、リモートの origin/main ブランチを追跡するように設定します。一度この設定を行えば、次回からは単に git push だけで origin main にプッシュできるようになります。

一度プッシュが成功すると、GitHubなどのリモートリポジトリ上で、あなたのコミットやファイルが確認できるようになります。

c) リモートの変更をローカルに取り込む (git pull)

共同開発している場合や、別の場所でリモートリポジトリに変更が加えられた場合、その最新の変更を自分のローカルリポジトリに取り込む必要があります。この操作をプル（Pull）と呼び、git pull コマンドを使用します。

git pull は、リモートリポジトリから最新の変更を取得（fetch）し、それを現在のローカルブランチに統合（merge）するという二つの操作を同時に行います。

追跡設定済みのブランチ（git clone した直後や、git push -u を実行した後など）であれば、単に git pull と実行するだけで、関連付けられたリモートブランチから変更を取り込めます。

bash
git pull

通常はこれで十分です。もし、どのリモートのどのブランチからプルするかを明示的に指定したい場合は、以下のようにします。

“`bash
git pull <リモートの名前> <リモートブランチの名前>

例: origin リモートの main ブランチからプル

git pull origin main
“`

他の開発者がリモートにプッシュした変更や、あなた自身が別のコンピューターからリモートにプッシュした変更をローカルに取り込みたい場合は、作業開始時などに git pull を実行して、ローカルリポジトリを最新の状態に保ちましょう。

リモートリポジトリとの連携は、Gitを使った共同開発やプロジェクト管理の要となります。最初は少し複雑に感じるかもしれませんが、clone, add, commit, push, pull の基本的なサイクルを繰り返すことで、徐々に慣れていくはずです。

11. もう一歩進んで：ブランチの基本的な使い方

Gitの最も強力な機能の一つに、ブランチ（Branch）機能があります。ブランチは、プロジェクトのメインの開発ラインから分岐して、独立した並行作業ラインを作成するものです。

例えるなら、ブランチはプロジェクトの「タイムライン」を枝分かれさせるようなものです。メインのタイムライン（通常は main または master と呼ばれるブランチ）から分岐して、新しい機能の開発やバグ修正といった特定の目的のために別のタイムラインを作成できます。この別のタイムラインでの作業は、メインのタイムラインに影響を与えません。作業が完了したら、そのブランチで行った変更をメインのタイムラインに統合（マージ）することができます。

なぜブランチを使うのか？

  • 安全な並行作業: 新しい機能の開発や実験的な変更を、安定しているメインブランチに影響を与えることなく行えます。
  • 複数機能の同時開発: 複数の開発者がそれぞれ異なるブランチで作業することで、同時に複数の機能開発を進めることができます。
  • バージョン管理の整理: 機能開発、バグ修正、リリースなど、目的別にブランチを分けることで、変更履歴を整理し、管理しやすくなります。

基本的なブランチ操作コマンド

ブランチに関する基本的な操作は以下のコマンドで行います。

a) 現在のブランチを確認する (git branch)

現在自分がどのブランチで作業しているか、およびローカルに存在するブランチの一覧を確認するには、git branch コマンドを使用します。

bash
git branch

出力例:

develop
* main
feature/new-layout

アスタリスク (*) が付いているブランチが、現在チェックアウトしている（作業中の）ブランチです。

b) 新しいブランチを作成する (git branch <新しいブランチ名>)

新しいブランチを作成するには、git branch コマンドに続けて作成したいブランチの名前を指定します。

bash
git branch feature/user-profile

このコマンドは、現在のコミットを基点として feature/user-profile という新しいブランチを作成しますが、作業中のブランチは切り替わりません。git branch を再度実行すると、新しいブランチがリストに追加されているのが確認できます。

c) 別のブランチに切り替える (git switch <ブランチ名> または git checkout <ブランチ名>)

作成したブランチで実際に作業を開始するには、そのブランチに切り替える必要があります。この操作をチェックアウト（Checkout）と呼びます。Gitのバージョン2.23以降では、ブランチの切り替えには git switch コマンドを使用するのが推奨されています（以前からある git checkout は、ファイルの復元など多様な用途に使われるため、役割を分けるために導入されました）。

新しいブランチ feature/user-profile に切り替えるコマンドは以下のようになります。

bash
git switch feature/user-profile

または（古いバージョンや、switch に慣れていない場合）：

bash
git checkout feature/user-profile

切り替えに成功すると、以下のメッセージが表示されます。

Switched to branch 'feature/user-profile'

これで、あなたのWorking Directoryの内容は、feature/user-profile ブランチが指すコミットの状態に更新され、このブランチ上での作業を開始できます。ここで行うコミットは、main ブランチには直接影響を与えません。

d) ブランチを作成してすぐに切り替える

新しいブランチを作成し、すぐにそのブランチで作業を開始したいという状況は非常に多いです。この二つの操作を一度に行う便利なオプションがあります。

git switch の場合：
“`bash
git switch -c <新しいブランチ名>

例: 新しいブランチ feature/contact-form を作成し、切り替える

git switch -c feature/contact-form
“`

git checkout の場合：
“`bash
git checkout -b <新しいブランチ名>

例: 新しいブランチ bugfix/footer-bug を作成し、切り替える

git checkout -b bugfix/footer-bug
``-cや-b` オプションは、「新しいブランチを作成してチェックアウトする」という意味です。初心者のうちは、このコマンドをよく使うことになるでしょう。

e) ブランチでの作業とマージ（簡単な紹介）

新しいブランチで機能開発やバグ修正の作業を進めたら、git add と git commit を繰り返して変更を記録します。作業が完了し、その変更をメインのブランチ（例: main）に取り込みたい場合は、マージ（Merge）という操作を行います。

マージの手順は以下のようになります。

  1. 変更を取り込みたい側のブランチに切り替えます（例: main ブランチ）。
    bash
    git switch main
  2. 取り込み元（マージ元）のブランチを指定して git merge コマンドを実行します。
    bash
    git merge <マージしたいブランチ名>
    # 例: feature/user-profile ブランチの変更を main にマージ
    git merge feature/user-profile

マージが成功すると、feature/user-profile ブランチで行った変更が main ブランチの履歴に取り込まれます。マージ後に不要になったブランチは、git branch -d <ブランチ名> で削除できます（ただし、マージ済みのブランチに限ります。マージされていないブランチを強制削除するには -D オプションを使いますが、これは慎重に行う必要があります）。

ブランチとマージは、Gitを使ったチーム開発や複雑な開発ワークフローにおいて非常に重要な概念です。最初は「とりあえずブランチを作って作業し、終わったらマージする」という基本的な流れから慣れていきましょう。

12. 初心者がつまずきやすいポイントと対処法

Gitの学習過程で、多くの初心者が経験するであろう「つまずきポイント」と、その対処法を知っておくことで、無用なストレスを減らすことができます。

  • 今、自分がどのブランチにいるか分からない！
    • 対処法: git status コマンドを使いましょう。出力の最初の行 On branch <ブランチ名> で確認できます。git branch コマンドでも、* がついているブランチが現在作業中のブランチです。作業前に必ず確認する癖をつけましょう。
  • 変更したファイルが git status で表示されない、または意図しないファイルが表示される。
    • 対処法:
      • git status は、リポジトリのルートディレクトリから実行しているか確認してください。Gitはカレントディレクトリ以下のファイルを追跡します。
      • 表示されないファイルが新規ファイルの場合、Gitに認識されていない可能性があります。ディレクトリパスが正しいか確認してください。
      • 表示されるべきでないファイル（実行ファイル、ログファイル、依存関係のディレクトリなど）が表示される場合は、それらをGitの管理対象から外すために .gitignore ファイルを作成・編集する必要があります。プロジェクトのルートディレクトリに .gitignore という名前のファイルを作成し、無視したいファイル名やディレクトリ名を記述します。
  • git add . を実行したら、ステージングしたくないファイルまでステージングされてしまった。
    • 対処法: .gitignore ファイルを設定してください。また、ステージングしてしまった変更を取り消すには、git restore --staged <ファイル名> を使用します。
  • git commit を実行したら、エディタが起動したけど使い方が分からない（特にVim）。
    • 対処法:
      • Vimの場合: コミットメッセージを入力したら、Esc キーを押してノーマルモードにし、:wq と入力してEnterキーを押すと保存して終了できます。:q! で保存せずに終了（キャンセル）です。
      • デフォルトエディタの設定を変更する: Gitの設定で、使い慣れたエディタ（VS Code, Sublime Textなど）をデフォルトに設定できます。例えばVS Codeの場合：
        bash
        git config --global core.editor "code --wait"
      • 簡単なコミットは -m オプションを使う: 前述のように、簡単なメッセージなら git commit -m "メッセージ" でエディタを使わずに済みます。
  • git push したらエラーになった (認証エラーや権限エラー)。
    • 対処法: GitHubなどのリモートリポジトリにプッシュする場合、認証が必要です。SSHキーを設定するか、HTTPS接続の場合はパスワードやパーソナルアクセストークン（PAT）の使用が必要になることがあります。特にパスワード認証は非推奨になってきているため、PATやSSHキーの設定方法をリモートホスティングサービスのドキュメントで確認してください。また、そのリポジトリにプッシュする権限があるか確認してください。
  • git pull したらコンフリクト (Conflict) が発生した。
    • 対処法: コンフリクトは、自分が行った変更と、プルしてきたリモートの変更が同じファイルの同じ場所を編集していた場合などに発生します。Gitが自動的にマージできなかった箇所を手動で修正する必要があります。
      • git status を確認すると、コンフリクトが発生しているファイルが表示されます。
      • 該当のファイルを開くと、Gitがコンフリクト箇所を <<<<<<<, =======, >>>>>>> のようなマーカーで示しています。これらのマーカーを見ながら、最終的に残したいコードになるように手動で編集します。
      • コンフリクトを解消したファイルを git add <ファイル名> でステージングします。
      • すべてのコンフリクトを解消し、ステージングしたら、git commit を実行します。Gitは通常、マージコミットメッセージを自動生成してくれます。
      • コンフリクト解消はGitの少し応用的なトピックですが、避けては通れません。最初は難しく感じるかもしれませんが、何度も経験することで慣れていきます。
  • Gitのコマンドのヘルプを見たい。
    • 対処法: git help <コマンド名> または git <コマンド名> --help で、そのコマンドの詳細なヘルプ（英語）を見ることができます。
      bash
      git help commit
      git branch --help
    • または、Gitの公式ドキュメント (https://git-scm.com/doc) を参照するのも良いでしょう。

最初はエラーや分からないことに遭遇するのは当然です。重要なのは、エラーメッセージをよく読むこと、git status で現在の状況を確認すること、そして分からないことを恐れずに調べることです。多くの問題は、基本的なコマンドと少しの知識で解決できます。

13. Beyond the Basics（さらに先へ）

この記事では、Gitの基本的な使い方に焦点を当ててきました。これまでに紹介したコマンド (git init, git status, git add, git commit, git log, git restore, git clone, git remote, git push, git pull, git branch, git switch, git merge) を理解し、使いこなせるようになれば、一人での開発や簡単な共同開発は十分に可能です。

しかし、Gitにはさらに多くの強力な機能があります。もしGitをもっと深く学びたいと思ったら、以下のようなトピックに挑戦してみることをお勧めします。

  • マージ戦略とコンフリクト解消の詳細: マージの種類（Fast-forward merge, Recursive mergeなど）や、複雑なコンフリクトの解消方法。
  • リベース (Rebase): 履歴を書き換えることで、よりきれいな線形履歴を作成する高度な操作。ただし、共有した履歴のリベースは避けるべきという重要なルールがあります。
  • スタッシュ (Stash): 作業途中の変更を一時的に避けておき、後で元に戻す機能。ブランチを切り替える際などに便利です。
  • タグ (Tag): 特定のコミットに「v1.0.0」のような永続的な名前（タグ）を付ける機能。主にリリースバージョンを示すために使われます。
  • コミットの取り消し/編集 (Reset, Revert): 過去のコミットを取り消したり、その変更を打ち消す新しいコミットを作成したりする方法。
  • 特定のコミットだけを取り込む (Cherry-pick): あるブランチの特定のコミットだけを、別のブランチに適用する機能。
  • .gitignore の詳細: 無視ルールの詳しい書き方。
  • GUIクライアント: コマンドラインだけでなく、SourceTree, VS CodeのGit機能, GitHub DesktopのようなGUIツールを使うことで、Gitの操作をより視覚的に行うことができます。GUIから始めて、慣れてきたらコマンドラインに移行するのも良い方法です。

これらの高度なトピックを学ぶことで、さらに複雑な開発ワークフローに対応したり、Gitの可能性を最大限に引き出したりすることができるようになります。

14. まとめ：Gitの第一歩を踏み出そう！

この記事では、Gitがなぜ必要か、どうインストール・設定するか、そしてGitを使ったバージョン管理の最も基本的なコマンドとワークフローについて詳細に解説しました。

あなたがこれからGitで最初に行うであろう重要なコマンドは、

  • git init: 新しいリポジトリを作成する
  • git status: 現在の状態を確認する
  • git add <ファイル名> または git add .: 変更をステージングする
  • git commit -m "コミットメッセージ": ステージングした変更をコミットする

この4つのコマンド、そして git log で履歴を確認する方法、git restore で簡単な間違いを直す方法をしっかりと理解し、実践することが、Git習得の第一歩です。

さらに、リモートリポジトリとの連携 (git clone, git push, git pull) や、ブランチの概念 (git branch, git switch, git merge) は、Gitを使いこなす上で非常に重要です。まずは基本的なサイクル (add -> commit -> push -> pull) を何度も繰り返して体に覚えさせましょう。そして、新しい機能開発やバグ修正に取りかかる前に、新しいブランチを作成する習慣をつけましょう。

Gitは強力なツールですが、一度にすべてを学ぶ必要はありません。まずはこの記事で紹介した基本的な部分から始め、少しずつステップアップしていくのがおすすめです。

焦らず、まずは小さなプロジェクトでGitを使ってみてください。HTMLファイル一つからでも構いません。変更を加えては add して commit し、log で履歴を確認する、というサイクルを繰り返してみましょう。

Gitを使いこなせるようになれば、あなたの開発スタイルは間違いなく変わります。より安全に、より効率的に、そしてより自信を持ってプロジェクトを進められるようになるでしょう。

さあ、Gitの第一歩を踏み出しましょう！あなたの素晴らしいプロジェクトの旅を、Gitが力強くサポートしてくれるはずです。

もしこの記事で分からない点があったり、実際に使っていてつまずいたりした場合は、遠慮なくインターネット検索を活用してください。「Git [コマンド名] 使い方」や「Git [エラーメッセージ] 対処法」などで検索すれば、多くの情報が見つかるはずです。Gitのコミュニティは非常に大きく、多くのリソースが公開されています。

あなたのGit学習が成功することを願っています！

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール