Knowledge Notebook
一覧に戻る
dev 2026年07月06日

初心者向けGit/GitHub入門：基本コマンドからGitHub連携までの手順

プログラミングの学習や実際の開発を始めると、必ずと言っていいほど「Git」や「GitHub」という言葉を耳にします。しかし、これから初めて触る人にとっては、「GitとGitHubはどう違うのか」「どのようにコードを管理してWeb上にアップロードするのか」が少し分かりづらく感じられるかもしれません。

かつての私もそうでしたが、最初のうちはコマンドの実行順序を丸暗記しようとしてしまい、ちょっとしたエラーで手が止まってしまうことが多々ありました。この記事では、Gitがどのようにファイルを管理しているのかという全体像を整理したうえで、自分のPC（ローカル環境）で作ったフォルダをGitHubにアップロードするまでの具体的な全手順と、普段の作業でよく使う基本コマンド、さらに中級者に向けて「他のブランチの特定のコミットだけを取り込む（git cherry-pick）機能」とコンフリクト対策について丁寧に解説します。

1. Gitの仕組みを直感的に理解する（イメージ図と4つのエリア）

まず、GitとGitHubの役割の違いを整理しておきましょう。Gitは自分のパソコン（ローカル環境）内でファイルの変更履歴を記録するための「ツール」です。一方で、GitHubはGitで記録した履歴データをインターネット上で共有・保存するための「Webサービス」です。

Gitでは、ファイルが登録されてからインターネット（GitHub等）にアップロードされるまでに、以下の「4つのエリア（段階）」を経由します。この仕組みをイメージできるようになると、実行するコマンドの意味がすっと理解できるようになります。

エリア名 役割 日常の例
1. ワークツリー（作業ディレクトリ） 実際にファイルをエディタで編集しているフォルダ 作業机（散らかっている状態）
2. ステージングエリア（インデックス） コミット（履歴の記録）をする準備のためにファイルを一時的に登録する場所 発送用のダンボール箱に荷物を詰めて封をする準備
3. ローカルリポジトリ 自分のPCの中に保存されている変更履歴の保管庫（`.git` フォルダ内） 自宅の倉庫にダンボール箱を収納する
4. リモートリポジトリ GitHubなどのクラウド上にある共有の保管庫 配送センターに荷物を送って預かってもらう

新しくファイルを作ったりコードを書き換えたりしても、Gitはいきなり履歴に保存しません。「このファイルのこの部分を記録したい」と選択してステージングし、「よし、これで区切りをつけよう」と決めてコミットすることで、初めてローカルリポジトリに保存されます。そして最終的にプッシュしてGitHubに送信します。この一連の流れがGit運用のベースです。

2. 実践！ローカルプロジェクトをGit管理してGitHubへ送信する全手順

それでは、具体的に自分のパソコンで新規に作成したプロジェクトフォルダを、Gitで初期化してGitHubにアップロード（Push）するまでの手順を追っていきましょう。

ステップ 1：プロジェクトフォルダの作成と移動

まずは開発作業を行うためのフォルダを作成します。ここでは例として、コマンドライン（MacのターミナルやWindowsのGit Bashなど）を使って `git-tutorial` という名前のフォルダを作成し、その中に移動します。

# フォルダの作成
mkdir git-tutorial

# 作成したフォルダへ移動
cd git-tutorial

ステップ 2：Gitリポジトリの初期化（git init）

作成したフォルダの直下にいる状態で、以下のコマンドを実行します。これにより、Gitでの履歴追跡がスタートします。

git init

このコマンドを実行すると、フォルダの中に非表示の `.git` という特別なディレクトリが生成されます。普段この中身を直接編集することはありませんが、ここがローカルリポジトリの実体です。

ステップ 3：ファイルの作成とステージング（git add）

履歴に記録するためのサンプルファイルを作ります。ここでは例として `README.md` というファイルを新規作成し、中に簡単な文字を書き込みます。

# テキストを書き込んだ README.md を作成
echo "# Gitの学習用リポジトリ" > README.md

ここで、現在の状態を確認する `git status` コマンドを実行してみましょう。

git status

実行結果には、赤文字で「Untracked files（まだGitが追跡していないファイル）」として `README.md` が表示されているはずです。このファイルをステージングエリアに登録（追加）するために、次のコマンドを実行します。

# 特定のファイルを登録する場合
git add README.md

# すべてのファイルや変更箇所を一括で登録する場合（実務ではこちらをよく使います）
git add .

再度 `git status` を実行すると、ファイル名が緑色の「Changes to be committed（コミットされる予定の変更）」に変わっていることが確認できます。

ステップ 4：変更履歴の記録（git commit）

ステージングしたファイルをローカルリポジトリに保存します。`-m` オプションを使い、どのような変更を行ったのかが一目で分かる「コミットメッセージ」を添えます。

git commit -m "first commit"

これで、あなたのPC内に最初のセーブポイントが作成されました。

ステップ 5：GitHubで新しいリモートリポジトリを作成

今度は、アップロード先となるGitHub側の用意をします。ブラウザでGitHubにサインインし、以下の手順を行います。

  1. トップ画面の右上にある「+」ボタンから「New repository」を選択します。
  2. 「Repository name」に `git-tutorial` などのリポジトリ名を入力します。
  3. 公開範囲（Public / Private）を設定します。
  4. 【重要】「Initialize this repository with」の項目にある「Add a README file」や「.gitignore」のチェックボックスは、すべてオフ（空の状態）にしておいてください。ローカルですでにファイルを作成しているため、ここでチェックを入れると衝突を起こして初期プッシュに失敗することがあります。
  5. 「Create repository」ボタンをクリックします。

作成後に表示される「Quick setup」ページのURL（`https://github.com/あなたのユーザー名/git-tutorial.git`）をコピーしておきます。

ステップ 6：ローカルとリモートリポジトリの紐付け

先ほどコピーしたURLをローカルのGitに登録します。この登録名（エイリアス）には通常 `origin` という名称が使われます。

git remote add origin https://github.com/あなたのユーザー名/git-tutorial.git

ステップ 7：ブランチ名の設定とプッシュの実行

近年のGitHubでは、デフォルトの主要ブランチ名が `main` と定義されています。古いGitの設定によってはローカルの初期ブランチ名が `master` になっている場合があるため、以下のコマンドで強制的に `main` に書き換えます。

git branch -M main

そして、ついにローカルのコミット履歴をGitHubへと送り出します。

git push -u origin main

`-u` オプションをつけて実行しておくと、次回以降は単に `git push` や `git pull` と入力するだけで、`origin` の `main` ブランチへ自動的にアプローチしてくれるようになります。無事に完了のメッセージが出れば、ブラウザでGitHubのページを開いた際、`README.md` ファイルがアップロードされていることが確認できるはずです。

3. 日々の開発で最もよく使う「基本コマンド」とベストプラクティス

一度初期設定が終われば、普段の作業で使うコマンドは限られてきます。日々の開発プロセスの中でよく使う代表的なコマンドを整理します。

# 現在の作業ツリーで変更が加わったファイルを一覧表示する
git status

# 具体的にどの行を書き換えたのか、差分を細かく確認する
git diff

# これまでのコミット履歴（セーブポイント）を一覧で確認する
git log

# 履歴を1つのコミットにつき1行でコンパクトに見やすくする
git log --oneline

# 既存のGitHubプロジェクトを自分のPCに丸ごとダウンロードする
git clone <リポジトリのURL>

# リモートリポジトリにある他の開発者の最新コミットを手元のPCに取り込む
git pull origin main

日々の開発で意識したいベストプラクティス

  • こまめにコミットを残す: 大きな機能をマージするのではなく、「ログイン画面のボタンを配置した」「エラー文言を修正した」といった小さい単位でコミットを刻むようにしましょう。こうすることで、後からバグが見つかった際の原因特定や、過去の時点への切り戻しが圧倒的にやりやすくなります。
  • プッシュを行う直前にプルする習慣をつける: 他のメンバーと共同で開発している場合、あなたがプッシュしようとする前に対象のリモートリポジトリが更新されている可能性があります。コンフリクトを未然に防ぐため、「作業を始める前」や「プッシュする直前」には `git pull` を実行して、手元を常に最新状態にしておくのが安心です。

4. ステップアップ！特定のコミットだけを取り込む（git cherry-pick）とコンフリクト対策

ここからは一歩進んだ実務レベルのコマンドについて解説します。チーム開発をしていると、別のブランチで実行された「特定のバグ修正コミットだけ」や「特定の機能追加コミットだけ」を、自分の作業中のブランチに持ってきたいという場面に遭遇します。

これを可能にするのが git cherry-pick（チェリーピック）コマンドです。サクランボをつまみ食いするように、美味しい（必要な）コミットだけを選ぶという意味から名付けられています。

基本的な使い方

まず、取り込みたいコミットの「コミットハッシュ（7桁以上の英数字）」を `git log` などで確認します。そして、取り込みたい先のブランチ（例：`main` ブランチ）に切り替えた状態でコマンドを実行します。

# 特定のコミット（例: a1b2c3d）を現在のブランチに取り込む
git cherry-pick a1b2c3d

これで、そのコミットが持っていた変更内容が、現在のブランチに新たなコミットとして複製されます。また、複数のコミットを同時に取り込むことや、範囲を指定することもできます。

# 複数のコミットを一度に取り込む
git cherry-pick a1b2c3d e5f6g7h

# コミットAからコミットBまでの範囲を取り込む（※コミットA自体は含まれません）
git cherry-pick <commit-A>..<commit-B>

競合（コンフリクト）が発生した場合の対処法

cherry-pickで取り込もうとした箇所が、現在のブランチのファイルと同じ行を書き換えていた場合、自動マージができずに「コンフリクト（競合）」が発生します。これはGit初心者にとって最も恐怖を感じるイベントの一つですが、落ち着いて対処すれば難しいことはありません。

コンフリクトが発生すると、コマンドラインにエラーが表示され、対象ファイルの中に以下のような「競合マーカー」が自動的に挿入されます。

<<<<<<< HEAD
自分が現在作業しているブランチのコード
=======
cherry-pick で持ってこようとしているコミットのコード
>>>>>>> a1b2c3d... コミットメッセージ

このマーカーを目印にして、ファイルを直接エディタで開き、どちらのコードを残すか（あるいは両方を組み合わせるか）判断して修正します。修正後は、以下の手順でGitに解決を知らせます。

  1. 競合マーカー（`<<<<<<<`, `=======`, `>>>>>>>`）をきれいに削除し、正しい状態にファイルを書き換えて保存します。
  2. 修正が終わったファイルをステージングに追加します。 
    git add 競合していたファイル名
  3. cherry-pickの処理を再開します。 
    git cherry-pick --continue

もし、コンフリクトが複雑すぎて一旦処理を取りやめ、元のまっさらな状態に戻したい場合は、以下のコマンドを実行すれば安全にキャンセルできます。

# cherry-pick を実行する前の状態に完全に戻す
git cherry-pick --abort

5. 初心者が遭遇しやすいエラーと具体的な解決方法

Gitの操作中に遭遇する、代表的な2つのエラーとその具体的な解消方法をまとめました。

エラー 1：認証エラー（Permission denied / Support for password authentication was removed）

GitHubへプッシュしようとした際、パスワード入力を求められ、正しく入力したはずなのに弾かれてしまうエラーです。現在、GitHubではセキュリティ向上のために一般的なパスワードによるHTTPS認証を廃止しています。以下のいずれかで対策します。

  • 解決策 A：パーソナルアクセストークン（PAT）を発行する
    GitHubの「Settings -> Developer settings -> Personal access tokens」から新しいトークンを発行します。プッシュ時にパスワードを求められたら、元のパスワードの代わりに発行されたトークン文字列（`ghp_...`）を入力します。
  • 解決策 B：SSH接続を設定する
    自分のパソコンでSSHキー（秘密鍵と公開鍵）を生成し、公開鍵をGitHubの「SSH and GPG keys」に登録します。登録後は、リモートのURLを `[email protected]:ユーザー名/リポジトリ名.git` という形式に変更することで、パスワード入力なしで安全に通信できます。

エラー 2：すでにリモートリポジトリが登録されている（fatal: remote origin already exists.）

`git remote add origin ...` を実行した際に出るエラーです。すでにローカルに `origin` という名前の宛先が設定されてしまっていることが原因です。登録先を変更したい場合は、以下のように対応します。

# 現在どのURLが登録されているか一覧表示して確認する
git remote -v

# 登録されている origin を削除する
git remote remove origin

# 改めて正しい宛先URLで登録する
git remote add origin <正しいURL>

まとめ

GitとGitHubの仕組みと、ローカルプロジェクトを登録する手順、配置した後の日々の運用、そして実務で直面するコンフリクトの解決法について紹介しました。

調べてみると分かりますが、バージョン管理という考え方は、プログラムを書くことだけにとどまりません。ビジネスでの文書作成やデザインデータの管理、日々のライフプランの更新など、「過去の履歴を消さずに、安全に変更を加えていく」というプロセスは、あらゆる日常の整理整頓に応用できます。私も、資料のフォルダに「最終版_2026_ver2.pdf」のような不細工な名前が増えなくなったのは、Git的な考え方を理解したことの最大の副産物でした。

初めのうちは、覚えるコマンドが多くて億劫になることもあると思いますが、まずは空のファイルを使った簡単な練習から手を動かしてみるのがおすすめです。手を動かすうちに、Gitの裏側にある「セーブデータを自在に操る楽しさ」が感じられるようになるはずです。