GitHubを使いこなすための初心者向けチュートリアル（Mac・Windows対応）

Web開発•2025/2/6

GitHub Git

はじめに

皆さんはソースコードを管理するとき、どのようにファイルの変更履歴を残していますか。

テキストエディタでファイルを修正したり、別名で保存することを繰り返していると、いつの間にかフォルダが乱雑になってしまいがちです。

複数人での共同作業となると、どのファイルが最新なのか混乱することもあるでしょう。

こうした課題をスマートに解決できるのがGitHubです。

GitHubはプログラミング初心者にも扱いやすいバージョン管理サービスで、履歴をわかりやすく残せるだけでなく、共同開発を効率的に進めるための仕組みも充実しています。

この記事では、MacとWindowsそれぞれの環境でGitHubを始めるためのステップや、ブランチ・プルリクエストなどの使い方を丁寧に解説します。

プログラミング未経験の方でも理解しやすいように、専門用語はなるべく噛み砕いて説明していきますので、一緒に学んでいきましょう。

この記事を読むとわかること

GitとGitHubの関係と、バージョン管理の基本的な考え方
Mac・Windows両方でのGitの導入手順と初期設定
リモートリポジトリとローカルリポジトリの違い、連携の流れ
ブランチやプルリクエストを使った共同開発のイメージ
実務に役立つコミットメッセージやレビューの進め方
GitHub上でのイシュー管理やタスク運用のポイント
コンフリクトが発生したときの解消の基本
チーム開発時に押さえておきたい運用上の注意点

ここでは、単なる解説だけでなく、「実際の開発現場ではどう使うか」という視点も取り入れています。

コード管理をシンプルにしつつ、チームメンバーとスムーズに連携できるようになるため、ぜひ最後まで読んでみてください。

GitとGitHubの基本概念

バージョン管理の重要性

プログラミングを続ける中で、ファイルの変更履歴が増えていくと「どこでバグを埋め込んだのか追いにくい」という状況になりがちです。

バージョン管理を活用すれば、過去の状態へスムーズに戻すことができますし、誰がいつどんな変更をしたのか明確になります。

これによって、トラブルシューティングの効率が大きく向上します。

GitとGitHubの違い

Git はローカルで動作するバージョン管理システムです。

一方、GitHub はGitリポジトリをネット上でホストし、各メンバーが変更点をやり取りできるサービスです。

Gitはあくまでもツールであり、GitHubはその運用をサポートするプラットフォームと考えるとわかりやすいでしょう。

実務におけるGitHubのメリット

リモートリポジトリに全員がアクセスできる
プルリクエストによるレビュー機能で品質を高めやすい
イシュー機能でバグやタスク管理を一元化できる

これらの仕組みによって、個人開発だけでなくチーム開発でも作業を整理しやすくなります。

Gitを導入するための準備

Gitのインストール

Macの場合

Macに標準搭載されている場合もありますが、環境によってはXcode Command Line Toolsの導入が必要になることがあります。

まずはターミナルで以下を試してみてください。

git --version

バージョンが表示されるならそのまま使えます。

出ない場合は、Command Line Toolsのインストールを求められるので、画面の案内に沿って進めましょう。

Windowsの場合

Windowsでは公式サイトからインストーラーをダウンロードしてインストールします。

Git公式サイトにアクセス
Windows版インストーラーを取得
セットアップウィザードの案内に従ってインストールを進める

インストール後、コマンドプロンプトかPowerShellで git --version と入力し、バージョン情報が返ってくれば問題なく導入完了です。

Gitの初期設定

Gitを初めて使う場合には、ユーザー名とメールアドレスを設定しておくと、コミット履歴に誰が変更を加えたか記録されます。

git config --global user.name "YourName"
git config --global user.email "YourEmail@example.com"

ここで設定した名前とメールアドレスが、今後の履歴表示に反映されます。

GitHubのアカウント作成とリポジトリ

アカウント登録の流れ

GitHubを使うには、まず無料のアカウントを作ります。

ブラウザでGitHub公式サイトにアクセス
「Sign up」でユーザー名やメールアドレス、パスワードを設定
メール認証を行ってアカウント作成完了

無料プランでもプライベートリポジトリを作れるため、最初から気軽に試せます。

リポジトリの作成

リポジトリは、ソースコードや関連ファイルをまとめて管理する単位です。

GitHubサイトでログイン後、右上の「+」をクリックして「New repository」を選択
リポジトリ名を入力（Public/Privateを選べます）
「Create repository」をクリック

この手順だけで、GitHub側のリモートリポジトリが用意できます。

ローカルとリモートの連携

ローカルリポジトリの初期化

すでにプロジェクトがある場合、以下のコマンドでそのフォルダをGit管理下に置きます。

cd プロジェクトのフォルダ
git init

すると、隠しフォルダ「.git」が生成され、そこに履歴情報が保存されていきます。

リモートリポジトリの登録

ローカルとリモートを連携させるには、以下のように remote add します。

git remote add origin https://github.com/ユーザー名/リポジトリ名.git

origin は慣習的に使われるリモート名ですが、プロジェクトによっては別の名前を使うケースもあります。

初回プッシュ

GitHub上のリポジトリと同期を取るため、プッシュを実行します。

git push -u origin main

-u オプションを付けることで、以降は git push だけで同じブランチにプッシュできます。

ブランチの考え方と基本操作

ブランチとは

ブランチは、開発を並行して進めるために使われる機能です。

メインブランチ（mainなど）から枝分かれして、安定版とは別に新機能を試す、バグ修正を行う、といった運用ができます。

新しいブランチの作成

新機能を作る前に、mainからブランチを切ると安全です。

git checkout main
git branch feature/new-login
git checkout feature/new-login

この feature/new-login ブランチ上で作業すれば、mainの安定したコードに影響を与えません。

ブランチを切り替える

ブランチを行き来するには git checkout コマンドを使います。

git checkout main

これでmainブランチに切り替わり、その状態のファイルがフォルダ内に展開されます。

コミットとプッシュの流れ

コミットの仕組み

コミットは「ここまでの変更をひとかたまりとして保存する」操作です。

例として、ファイルを編集した後に以下を実行します。

git add .
git commit -m "新規ログインフォームの追加"

git add . は、作業フォルダ内で変更されたファイルをすべて追加対象にするという意味です。

コミットすることで、改修した内容が履歴として確定されます。

プッシュでリモートに反映

コミットをローカルでしただけでは、まだGitHub上には反映されません。

そこで、プッシュでGitHub上のリポジトリに変更を送ります。

git push origin feature/new-login

これにより、リモートにも同じ変更履歴が登録され、他の人が取り込める状態になります。

チーム開発でのプルリクエスト

プルリクエストの概要

プルリクエスト（PR）は、作業ブランチの内容をメインブランチに取り込んでもらうように提案するための仕組みです。

GitHubの画面上から、以下のように操作します。

リポジトリのページにアクセス
「Pull requests」をクリック
「New pull request」でブランチを選択
タイトルや詳細を入力して作成

これで、メンバーにレビューを依頼できる形になります。

レビューとマージ

プルリクエストを作ると、差分の確認画面が表示されるので、レビュー担当者はコメントをつけながらコードのチェックを行います。

問題がなければ「Merge pull request」ボタンからマージ（ブランチの変更をmainに統合）できます。

もし修正点があれば、修正した後に改めて同じブランチをプッシュすると、プルリクエスト画面に差分が自動的に反映されます。

コンフリクトの解消

コンフリクトとは

同じファイルの同じ行を、異なるブランチで別々に変更した場合に発生するのがコンフリクトです。

マージ時にGitがどちらの変更を優先すべきか判断できないため、手動で修正を促されます。

コンフリクト解消の流れ

コンフリクトを起こしているブランチをローカルに持ってくる
対象ファイルを開き、 <<<<<<< HEAD や ======= などの境界行を見つける
必要な変更を採用して、不要な記号を削除
修正したファイルをコミットし直す

こうすることで、マージ可能な状態になります。

実務でのヒント

コンフリクト箇所を正確に把握するために、ファイル比較ツールを使うと便利
エディタによってはコンフリクト解消機能が標準搭載されている
なるべくこまめにプルしておくと、コンフリクトの発生頻度を抑えられる

実務で役立つコミットメッセージの書き方

ポイントは「何をしたか」を明確にする

コミットメッセージは、履歴を見返したときに変更内容を素早く理解するための指標です。

曖昧なメッセージだと後々困る場合が多いので、以下のような書き方を意識すると良いでしょう。

# 良い例
"ユーザー登録機能に入力チェックを追加"

# 悪い例
"修正しました"

タイトルと詳細を分ける

大規模プロジェクトの場合、1行のコミットメッセージでは説明しきれないこともあります。

下記のように、1行目で結論を、2行目以降で詳細を記述するスタイルをとるチームも多いです。

git commit -m "ユーザー登録機能に入力チェックを追加

- フォームの名前欄を必須に変更
- メールアドレスの形式チェックロジック実装
"

GitHubのイシューとタスク管理

イシューとは

イシューは、プロジェクト内で発生するタスクやバグ報告を管理する機能です。

バグの内容
要望や改善提案
開発すべき機能の詳細

これらをチケットの形でまとめ、担当者をアサインしたり、進捗を共有できます。

実務での運用

バグを見つけた人がイシューを立てる
他のメンバーがイシューを確認し、必要なら詳細を追加
対応するブランチを作成し、解決したらプルリクエストを出す
プルリクエストがマージされたら、イシューをクローズする

こうしたフローを回すことで、チーム全体のタスク管理がスムーズになります。

ブランチ運用パターン

シンプル運用（main + featureブランチ）

最初は、mainブランチと必要に応じて作るfeatureブランチの2種類だけでも十分です。

main：常に動作が安定しているコード
feature/xxx：特定の機能や修正を行う作業用

この運用であれば、初心者でも混乱しにくく、コンフリクトも起きづらいです。

Git Flowに近い運用

規模が大きくなると、以下のようなブランチを追加で作るケースもあります。

develop：日々の開発が集約されるブランチ
release：リリース前のテストや調整を行う
hotfix：本番で見つかった重大バグを即座に修正

ただし、あまり多くのブランチを設けると初心者には覚えることが増えるので、チームの慣れやプロジェクト規模に合わせて検討しましょう。

ローカル履歴の確認とやり直し

履歴を見る

過去の履歴は git log で確認できます。

コミットハッシュやメッセージ、日時、作者などの情報が一覧表示されるので、どの段階でどんな変更をしたか追えるようになっています。

git log --oneline

のようにオプションを付けると、一行表示で簡潔に確認できます。

直前のコミットを取り消す

間違ったファイルをコミットに含めてしまった場合など、直前のコミットを取り消したい場合は以下のコマンドを使います。

git reset --soft HEAD~

このコマンドで取り消したコミットは、ローカル作業に戻った状態になります。

リモートにプッシュしていない段階であれば、これで編集し直しが可能です。

MacとWindowsで意識するポイント

改行コード

MacやLinuxはLF、WindowsはCRLFがデフォルトで異なります。

Gitの設定で core.autocrlf を有効にすると、自動的に変換してくれます。

この設定を使わない場合は、混在した改行コードによって思わぬ差分が発生するので注意しましょう。

ファイル名の大文字・小文字

MacやLinuxでは大文字小文字が区別されますが、Windowsの設定によっては区別されない場合があります。

同じ名前で大文字小文字だけ違うファイルが混在するとトラブルが起こりやすいので、プロジェクト内でファイル命名規則を統一しておくと安心です。

共同開発を円滑にするコツ

コミュニケーションツールとの連携

GitHubに慣れてくると、SlackやMicrosoft TeamsなどのチャットツールとGitHubを連携させるケースも増えます。

プルリクエストが作成されたら通知が届くように設定しておけば、レビュー依頼を見逃す可能性が減り、チームの反応速度も上がります。

レビューの質を高める

プルリクエストのレビューは、単に「動くかどうか」だけでなく、コードの可読性や保守性をチェックする大事なプロセスです。

具体的な指摘や提案を行う
感謝やポジティブなコメントでモチベーションを維持する

こういった姿勢を大事にすると、チーム全体のスキルアップにもつながります。

コミットの粒度

コミットをある程度細かく分けることで、問題が起きた際にどこから手を入れればいいか特定しやすくなります。

一方であまりにも細切れすぎると、履歴が煩雑になるので「機能やバグ修正単位」でまとめる意識が必要です。

運用を助ける便利機能

.gitignore

プロジェクトにはソースコードとして管理しなくて良いファイルが含まれる場合も多いです。

IDEの設定ファイル
コンパイル後のバイナリ
キャッシュやログファイル

これらを**.gitignore**に指定しておくと、Gitは追跡しなくなります。

READMEファイル

リポジトリを初めて訪れた人向けに、README でプロジェクトの概要や導入手順などをまとめておくと親切です。

長期的にメンテナンスするオープンソースプロジェクトでは特に重要で、参加者が迷わないように情報を整理しておきましょう。

タグとリリース

開発がある程度進んで安定版ができたら、タグを打っておくとバージョンごとにコードを簡単に参照できます。


git tag v1.0.0
git push origin v1.0.0

これにより、プロジェクトの「どの時点が1.0.0だったか」を後から振り返るのが容易になります。

まとめ

ここまで、GitとGitHubの基本からブランチ運用、プルリクエストのレビューやコンフリクト解決まで、初心者の方がつまずきやすいポイントを中心に説明してきました。

バージョン管理を導入するだけで、ファイル管理が格段にスムーズになる
Mac・Windowsそれぞれのインストールや設定ポイントを押さえておくと作業環境のトラブルが減る
ブランチ運用やプルリクエストを活用すると、複数人での開発がわかりやすくなる
コンフリクトやコミットメッセージの書き方など、細部を意識することでプロジェクト全体の品質が高まる
イシュー管理やREADME、.gitignoreなども適切に使えば、より快適な開発体制を築ける

GitHubは慣れてしまえばとても便利です。

最初はコマンドが多くて戸惑うかもしれませんが、小さなプロジェクトから始めて徐々に慣れていくのがおすすめです。

ブランチを切り替えて試行錯誤したり、イシューでタスクを管理してみたりするうちに「GitHubなしでは開発しにくい」と感じるようになるでしょう。

プログラミングを始めたばかりの方も、ぜひこの機会にGitHubを使いこなしてみてください。

ブランチやプルリクエストを使い始めると、最初は少し面倒に感じることもあるかもしれません。
しかし、後から「どこでバグが紛れ込んだのか」「誰がこの変更を提案したのか」を追いかけるときに、GitHubが大きな力を発揮してくれます。
実際のプロジェクト運用をイメージしながら、少しずつ活用範囲を広げてみましょう。