【2026年最新版】Git入門完全ガイド | 初心者でも3日でマスターできる使い方徹底解説

Gitとは何か?プログラミング未経験者でもわかる基礎知識

Gitの定義を初心者向けに解説

Gitとは、プログラミングで作成したファイルの変更履歴を記録・管理するためのツールです。「バージョン管理システム」や「ソースコード管理システム」とも呼ばれます。

プログラミング初心者の方に例えるなら、Gitは「タイムマシン付きの超高機能なファイル保存システム」です。普通のファイル保存では「上書き保存」しかできませんが、Gitを使えば過去のあらゆる時点に戻ることができます。

2005年にLinuxの生みの親であるリーナス・トーバルズによって開発されたGitは、現在では世界中のプログラマーが使用する標準ツールとなっています。GitHub、Google、Microsoft、Facebookなど、名だたる企業もGitを使用しています。

プログラミング初心者がGitを学ぶべき5つの理由

理由1: コードの安全な管理ができる

プログラミングを始めたばかりの頃は、コードを書いている途中で「あれ?さっきまで動いていたのに壊れた」という経験をすることが多いでしょう。Gitを使えば、動いていた時点のコードに簡単に戻れます。

例えば、新機能を追加しようとして既存のコードを壊してしまった場合、Gitがあれば数秒で元の状態に戻せます。これは初心者にとって非常に心強い機能です。

理由2: 就職・転職活動で必須のスキル

2025年現在、IT業界でGitを使わない企業はほとんどありません。プログラミングスクールの卒業生も、企業への就職時にGitの知識を求められます。履歴書やポートフォリオでGitHubのアカウントを提示することは、もはや標準となっています。

実際の求人情報を見ても、「Git/GitHubの使用経験」は未経験者向けの求人でも記載されていることが多く、早めに習得しておくことで就職活動を有利に進められます。

理由3: チーム開発・共同作業が可能になる

プログラミング学習が進むと、友人や仲間と一緒にアプリケーションを作る機会が出てきます。その際、Gitがないと「誰がどのファイルを編集しているか」「最新版はどれか」といった管理が非常に困難です。

Gitを使えば、5人でも10人でも、同時に同じプロジェクトで作業できます。各自が並行して開発し、後で統合することが可能です。

理由4: オープンソースプロジェクトへの参加

世界中の優れたプログラマーが公開しているオープンソースプロジェクトは、ほぼすべてGitで管理されています。Gitを学ぶことで、これらのプロジェクトのコードを読んだり、貢献したりできるようになります。

実際に有名なプロジェクトにコントリビュート(貢献)した経験は、就職活動や転職活動で大きなアピールポイントになります。

理由5: 自分の成長を可視化できる

Gitを使って毎日コミット(変更の記録)を続けると、自分がどれだけプログラミングスキルを積み上げてきたかを視覚的に確認できます。GitHubの「コントリビューショングラフ」は、あなたの努力の証となります。

バージョン管理システムとは?初心者にもわかる具体例

バージョン管理システムを理解するために、日常生活の例で考えてみましょう。

例1: 作文の添削

学生時代、作文を書いて先生に添削してもらった経験はありませんか?「作文_最初.docx」「作文_修正1.docx」「作文_修正2.docx」「作文_最終版.docx」「作文_最終版_本当の最終.docx」のように、ファイルがどんどん増えていった経験があるでしょう。

Gitを使えば、ファイル名を変えることなく、すべての変更履歴を一つのファイルで管理できます。いつでも過去のバージョンを見られ、誰がどの部分を変更したかも一目瞭然です。

例2: ゲームのセーブポイント

RPGゲームをプレイしている際、重要な場面の前にセーブしますよね。「このボス戦の前にセーブしておこう」「この選択肢の前にセーブしておこう」というように。

Gitのコミットは、まさにこのセーブポイントです。プログラミングの重要な場面で「セーブ」しておけば、後で問題が起きても安心です。しかもGitでは、複数のセーブデータ(ブランチ)を同時に管理できます。

Gitの仕組みと基本概念を初心者向けに完全解説

Gitを使いこなすには、いくつかの基本概念を理解する必要があります。専門用語が多く最初は戸惑うかもしれませんが、一つずつ丁寧に説明していきます。

リポジトリ(Repository)とは?具体的に解説

リポジトリは、プロジェクトのすべてのファイルと、その変更履歴を保存する「倉庫」のようなものです。英語の「repository」は「貯蔵庫」という意味です。

ローカルリポジトリ

あなたのパソコン内に作成されるリポジトリです。ここで実際にコードを書いたり、変更を記録したりします。インターネット接続がなくても作業できるのが特徴です。

イメージとしては、あなたの机の上にある作業スペースです。ここで自由に試行錯誤できます。

リモートリポジトリ

インターネット上のサーバーに保存されるリポジトリです。GitHub、GitLab、Bitbucketなどのサービスでホスティング(保管)されます。

イメージとしては、クラウド上の共有フォルダです。チームメンバー全員がアクセスでき、最新のコードを共有できます。

ローカルとリモートの関係

基本的な流れは以下の通りです:

1. リモートリポジトリからコードをダウンロード(clone)
2. ローカルリポジトリで作業
3. 変更をローカルで記録(commit)
4. ローカルの変更をリモートにアップロード(push)

この仕組みにより、オフラインでも作業でき、完成したタイミングでオンラインに共有できます。

コミット(Commit)の概念を初心者向けに詳しく

コミットは、ファイルの変更を記録する操作です。「この時点でのファイルの状態を保存する」という意味です。

コミットの特徴

• 各コミットには一意のID(ハッシュ値)が付けられます
• コミットメッセージで「何を変更したか」を説明します
• 誰が、いつ、何を変更したかがすべて記録されます
• 過去のどのコミットにも戻ることができます

コミットの粒度(大きさ)

初心者が迷うのが「どのタイミングでコミットすべきか」です。基本的な考え方は:

• 一つの機能や修正が完成したらコミット
• 「動く状態」でコミットする
• 「ログイン機能を追加」「パスワード検証を実装」など、意味のある単位で区切る
• 「とりあえず保存」のような曖昧なコミットは避ける

例えば、ログイン機能を作る場合:

• コミット1: ログイン画面のHTMLを作成
• コミット2: ログイン処理のJavaScriptを実装
• コミット3: エラーメッセージ表示機能を追加

このように、段階的にコミットしていきます。

ステージングエリア(Staging Area)とは

Gitには、「作業ディレクトリ」「ステージングエリア」「リポジトリ」という3つの領域があります。これが初心者にとって最も理解しにくい部分です。

作業ディレクトリ(Working Directory)

あなたが実際にファイルを編集している場所です。普通のフォルダと同じです。

ステージングエリア(Staging Area / Index)

コミットする準備をする場所です。「次のコミットに含めたい変更」を選択して置いておくスペースです。

リポジトリ(Repository)

コミットが永久保存される場所です。履歴として記録されます。

なぜステージングエリアが必要?

例えば、あなたが5個のファイルを編集したとします。しかし、そのうち3個だけをコミットしたい場合があります。ステージングエリアを使えば、コミットに含めるファイルを選択できます。

流れはこうです:

1. ファイルを編集(作業ディレクトリ)
2. git addでステージングに追加
3. git commitでリポジトリに記録

この仕組みにより、変更を細かくコントロールできます。

ブランチ(Branch)を初心者向けに徹底解説

ブランチは、開発の流れを分岐させる機能です。「枝」という意味で、メインの幹から新しい枝を生やすイメージです。

ブランチの具体的な使い方

mainブランチ(幹)から新しいブランチ(枝)を作り、そこで新機能を開発します。開発が完了したら、mainブランチに統合(merge)します。

実際のシナリオ

あなたがウェブサイトを運営しているとします:

• mainブランチ: 公開中の安定版
• feature/new-design: 新しいデザインを実験
• feature/contact-form: お問い合わせフォームを追加
• bugfix/login-error: ログインのバグを修正

各ブランチで独立して作業し、完成したものから順にmainブランチに統合していきます。

ブランチのメリット

1. メインのコードを壊さずに実験できる
2. 複数の機能を並行開発できる
3. 問題があれば、そのブランチだけ削除すればOK
4. チームメンバーがそれぞれ独立して作業できる

マージ(Merge)とは?初心者向け詳細解説

マージは、あるブランチの変更を別のブランチに統合する操作です。

マージの基本的な流れ

1. feature/new-featureブランチで新機能を開発
2. 開発が完了
3. mainブランチに切り替え
4. feature/new-featureをmainにマージ
5. 新機能がmainに統合される

マージの種類

Gitには複数のマージ方法がありますが、初心者はまず「通常のマージ」を理解すればOKです。

• Fast-forward merge: 単純に進めるだけのマージ
• 3-way merge: 双方に変更がある場合のマージ

Git初心者のための環境構築完全ガイド

ここからは、実際にGitを使い始めるための手順を説明します。パソコン操作に不慣れな方でも大丈夫です。

Gitのインストール方法を画面付きで解説

Windows環境でのインストール

1. ブラウザで「git-scm.com」と検索
2. 公式サイトにアクセス
3. 「Download for Windows」ボタンをクリック
4. ダウンロードされたインストーラーを実行
5. インストールウィザードが起動したら「Next」を連打
6. 「Install」をクリック
7. インストール完了

インストール時の設定項目は、初心者はデフォルト(初期設定)のままでOKです。特に変更する必要はありません。

確認方法

インストールが完了したら、コマンドプロンプト(黒い画面)を開いて以下を入力:

git --version

「git version 2.x.x」のように表示されればインストール成功です。

Mac環境でのインストール

Macでは、Gitが最初から入っている場合もあります。

1. Launchpadから「ターミナル」を開く
2. git --versionと入力してEnter
3. Gitがインストールされていない場合、自動的にインストール画面が表示される
4. 「インストール」をクリック
5. Apple IDのパスワードを入力
6. インストール完了

Homebrewを使う方法(推奨)

より新しいバージョンのGitを使いたい場合:

1. Homebrewをインストール(brewのウェブサイトから)
2. ターミナルでbrew install gitを実行
3. インストール完了

Linux環境でのインストール

Linuxディストリビューションによって方法が異なります。

Ubuntu/Debianの場合:

sudo apt-get update
sudo apt-get install git

Fedora/CentOSの場合:

sudo dnf install git

Arch Linuxの場合:

sudo pacman -S git

Git初期設定を初心者向けに詳しく解説

Gitをインストールしたら、最初に自分の名前とメールアドレスを設定します。これらの情報は、あなたがコミットする際に記録され、「誰が変更したか」を識別するために使われます。

ユーザー名の設定

コマンドプロンプトまたはターミナルで以下を実行:

git config --global user.name "Yamada Taro"

ここでの名前は本名である必要はありません。GitHubで使う予定のユーザー名にしておくと良いでしょう。

メールアドレスの設定

git config --global user.email "yamada@example.com"

GitHubを使う予定の場合、GitHubに登録するメールアドレスと同じものを設定してください。

設定の確認

正しく設定できたか確認しましょう:

git config --global --list

設定した名前とメールアドレスが表示されればOKです。

その他の便利な初期設定

以下の設定も初心者におすすめです:

# デフォルトブランチ名をmainに設定
git config --global init.defaultBranch main

# エディタを設定(VS Codeの場合)
git config --global core.editor "code --wait"

# 改行コードの自動変換(Windowsの場合)
git config --global core.autocrlf true

# 改行コードの自動変換(Mac/Linuxの場合)
git config --global core.autocrlf input

コマンドラインの基本操作を初心者向けに

Gitはコマンドライン(黒い画面に文字を入力する方式)で操作します。GUI(グラフィカルなアプリ)もありますが、まずはコマンドラインに慣れることをおすすめします。

コマンドプロンプト/ターミナルの開き方

Windows:

• スタートメニューで「cmd」と検索
• 「コマンドプロンプト」をクリック

Mac:

• Launchpadで「ターミナル」を検索
• クリックして開く

基本的なコマンド

Gitコマンドの前に、ファイル操作の基本コマンドを知っておきましょう:

# 現在のディレクトリを表示
pwd

# ディレクトリ内のファイル一覧
ls (Mac/Linux)
dir (Windows)

# ディレクトリの移動
cd フォルダ名

# 一つ上のディレクトリに移動
cd ..

# ホームディレクトリに移動
cd ~

# 新しいフォルダを作成
mkdir フォルダ名

これらの基本コマンドができれば、Gitを使う準備は完了です。

プログラミング初心者が絶対覚えるべきGitコマンド15選

Gitには100以上のコマンドがありますが、初心者が日常的に使うのは15個程度です。一つずつ丁寧に解説します。

1. git init – 新規リポジトリの作成方法

git initは、現在のフォルダをGitリポジトリに変換するコマンドです。これが全ての始まりです。

使い方

mkdir my-project
cd my-project
git init

これでmy-projectフォルダがGitで管理されるようになります。

何が起きているか

.gitという隠しフォルダが作成されます。このフォルダにすべての履歴情報が保存されます。通常、この中身を直接触ることはありません。

初心者の注意点

• 既にGitで管理されているフォルダ内でgit initする必要はありません
• ホームディレクトリ全体でgit initしないように注意

2. git clone – リモートリポジトリのダウンロード

git cloneは、インターネット上にあるGitリポジトリを自分のパソコンにコピーするコマンドです。

基本的な使い方

git clone https://github.com/ユーザー名/リポジトリ名.git

具体例

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

これでReactのソースコードがダウンロードされます。

clone後の構造

クローンすると、リポジトリ名のフォルダが作成され、その中にすべてのファイルがダウンロードされます。

react/
  ├── .git/
  ├── src/
  ├── README.md
  └── ...

初心者の注意点

• クローンには時間がかかる場合があります(リポジトリのサイズによる)
• クローンすると、リモートリポジトリとの接続情報も自動設定されます

3. git status – 現在の状態を確認する

git statusは、現在のリポジトリの状態を表示する、最も頻繁に使うコマンドです。

使い方

git status

表示される情報

• 現在いるブランチ名
• コミットされていない変更
• ステージングエリアにあるファイル
• 追跡されていない新規ファイル

実際の出力例

On branch main
Changes not staged for commit:
  modified:   index.html

Untracked files:
  style.css

これは「index.htmlが変更されているけどステージングされていない」「style.cssは新規ファイルで追跡されていない」という意味です。

初心者へのアドバイス

困ったらgit statusを実行する癖をつけましょう。現在の状況が常に確認できます。

4. git add – ステージングエリアに追加

git addは、変更をステージングエリアに追加するコマンドです。「次のコミットに含める準備」をします。

基本的な使い方

# 特定のファイルを追加
git add ファイル名

# すべての変更を追加
git add .

# 複数のファイルを指定
git add file1.txt file2.txt file3.txt

# パターンマッチングで追加
git add *.js

具体例

# index.htmlだけをステージング
git add index.html

# すべてのJavaScriptファイルをステージング
git add *.js

# 現在のディレクトリ以下すべてをステージング
git add .

初心者の注意点

• git add .は便利ですが、意図しないファイルまで追加される可能性があります
• 追加前にgit statusで確認する習慣を
• git addしてもまだコミットされていません(次のステップが必要)

5. git commit – 変更を記録する

git commitは、ステージングエリアの内容をリポジトリに記録するコマンドです。これで初めて履歴が残ります。

基本的な使い方

git commit -m "コミットメッセージ"

良いコミットメッセージの書き方

# 良い例
git commit -m "ユーザーログイン機能を追加"
git commit -m "パスワード検証のバグを修正"
git commit -m "トップページのデザインを更新"

# 悪い例
git commit -m "修正"
git commit -m "変更"
git commit -m "aaa"

コミットメッセージのルール

1. 何をしたかを動詞で始める
2. 50文字以内が理想
3. 日本語でもOK(チームのルールに従う)
4. 現在形で書く「追加した」より「追加」

複数行のメッセージ

git commit -m "ログイン機能を追加

- メールアドレスでのログイン対応
- パスワードの暗号化実装
- ログイン状態の保持機能"

便利なオプション

# addとcommitを同時に(既存ファイルのみ)
git commit -am "メッセージ"

# 直前のコミットメッセージを修正
git commit --amend -m "新しいメッセージ"

6. git log – コミット履歴の確認

git logは、過去のコミット履歴を表示するコマンドです。

基本的な使い方

git log

様々な表示オプション

# 1行表示(見やすい)
git log --oneline

# グラフ表示
git log --graph --oneline --all

# 最近の3件だけ表示
git log -3

# 特定の作者のコミットだけ
git log --author="Yamada"

# 日付範囲を指定
git log --since="2025-01-01" --until="2025-01-31"

出力の見方

commit a1b2c3d4e5f6... (←コミットID)
Author: Yamada Taro <yamada@example.com>
Date:   Mon Jan 15 10:30:00 2025 +0900

    ログイン機能を追加

7. git diff – 変更内容の確認

git diffは、ファイルの変更内容を詳しく表示するコマンドです。

使い方

# ワーキングディレクトリの変更を表示
git diff

# ステージング済みの変更を表示
git diff --staged

# 特定のファイルの変更のみ
git diff ファイル名

# コミット間の差分
git diff コミットID1 コミットID2

出力の見方

- 削除された行(赤)
+ 追加された行(緑)

8. git branch – ブランチの操作

git branchは、ブランチの作成・一覧表示・削除を行うコマンドです。

基本的な使い方

# ブランチ一覧を表示
git branch

# 新しいブランチを作成
git branch 新ブランチ名

# ブランチを削除
git branch -d ブランチ名

# 強制削除(マージされていなくても)
git branch -D ブランチ名

# リモートブランチも含めて表示
git branch -a

ブランチ名のベストプラクティス

# 良い例
feature/user-login
feature/payment-system
bugfix/login-error
hotfix/critical-bug

# 悪い例
test
new
branch1

9. git checkout / git switch – ブランチの切り替え

ブランチを切り替えるコマンドです。新しいGitではgit switchが推奨されています。

従来の方法(git checkout)

# ブランチを切り替え
git checkout ブランチ名

# ブランチを作成して切り替え
git checkout -b 新ブランチ名

新しい方法(git switch) – 推奨

# ブランチを切り替え
git switch ブランチ名

# ブランチを作成して切り替え
git switch -c 新ブランチ名

# 直前のブランチに戻る
git switch -

初心者の注意点

• ブランチ切り替え前に変更をコミットするかstashする
• 切り替え後、ファイルの内容が変わることを理解する

10. git merge – ブランチの統合

git mergeは、あるブランチの変更を現在のブランチに統合するコマンドです。

基本的な流れ

# mainブランチに切り替え
git switch main

# feature/new-featureをmainにマージ
git merge feature/new-feature

マージの種類

Fast-forward merge: スムーズに統合される場合

git merge feature/login
Updating a1b2c3d..e4f5g6h
Fast-forward

3-way merge: コミット履歴が合流する場合

git merge feature/payment
Merge made by the 'recursive' strategy.

マージ後の確認

git log --graph --oneline

11. git pull – リモートの変更を取得

git pullは、リモートリポジトリの最新の変更をローカルに取り込むコマンドです。

基本的な使い方

# 現在のブランチの最新を取得
git pull

# 特定のリモートとブランチを指定
git pull origin main

pullの内部動作

git pullは実際には2つの操作を同時に実行しています:

1. git fetch: リモートの情報を取得
2. git merge: ローカルブランチに統合

初心者の注意点

• 作業開始前に必ずgit pullする習慣を
• コンフリクトが発生する可能性がある
• 未コミットの変更がある場合、先にコミットかstash

12. git push – ローカルの変更をリモートに送信

git pushは、ローカルリポジトリのコミットをリモートリポジトリにアップロードするコマンドです。

基本的な使い方

# 現在のブランチをpush
git push

# 初回push時(ブランチの紐付け)
git push -u origin main

# 特定のブランチをpush
git push origin ブランチ名

# すべてのブランチをpush
git push --all

初回pushの詳細

最初のpushでは-uオプション(upstream設定)が必要です:

git push -u origin main

これにより、次回から単にgit pushだけでpushできるようになります。

pushが失敗する場合

! [rejected] main -> main (fetch first)

このエラーは、リモートに新しいコミットがある場合に発生します。

解決方法:

git pull
git push

強制push(危険)

git push -f
# または
git push --force

⚠️ 注意: 強制pushは他の人の作業を消す可能性があります。初心者は使用を避けてください。

13. git stash – 一時的な変更の退避

git stashは、コミットせずに変更を一時保存するコマンドです。急にブランチを切り替える必要がある時に便利です。

基本的な使い方

# 変更を退避
git stash

# 退避した変更を復元
git stash pop

# 退避リストを確認
git stash list

# 特定のstashを復元
git stash apply stash@{0}

# stashを削除
git stash drop

実際のシナリオ

# 作業中に緊急のバグ修正依頼が来た
git stash save "作業中のログイン機能"

# 別ブランチでバグ修正
git switch hotfix/urgent-bug
# バグ修正作業...
git commit -m "緊急バグ修正"

# 元の作業に戻る
git switch feature/login
git stash pop

メッセージ付きstash

git stash save "ログイン機能の途中"

14. git reset – コミットの取り消し

git resetは、コミットを取り消すコマンドです。3つのモードがあり、初心者は慎重に使う必要があります。

3つのモード

# コミットだけ取り消し、変更は保持
git reset --soft HEAD^

# コミットとステージングを取り消し、変更は保持
git reset --mixed HEAD^
# または単に
git reset HEAD^

# すべて取り消し(変更も削除)⚠️危険
git reset --hard HEAD^

HEAD^の意味

• HEAD^: 直前のコミット
• HEAD~2: 2つ前のコミット
• HEAD~3: 3つ前のコミット

初心者の安全な使い方

# 直前のコミットをやり直したい
git reset --soft HEAD^
# ファイルを修正
git add .
git commit -m "正しいメッセージ"

注意点

⚠️ pushした後のコミットはresetしないでください。他の人に迷惑がかかります。

15. git remote – リモートリポジトリの管理

git remoteは、リモートリポジトリの接続情報を管理するコマンドです。

基本的な使い方

# リモート一覧を表示
git remote

# 詳細表示(URLも表示)
git remote -v

# リモートを追加
git remote add origin https://github.com/user/repo.git

# リモートを削除
git remote remove origin

# リモート名を変更
git remote rename old-name new-name

# リモートのURLを変更
git remote set-url origin 新しいURL

originとは

originは、リモートリポジトリのデフォルト名です。別の名前でも構いませんが、慣習的にoriginが使われます。

複数のリモート

git remote add origin https://github.com/user/repo.git
git remote add upstream https://github.com/original/repo.git

オープンソースプロジェクトでは、origin(自分のfork)とupstream(本家)を使い分けます。

Gitの実践的なワークフローを初心者向けに完全解説

ここからは、実際のプロジェクトでGitをどう使うかを学びます。

個人開発での基本ワークフロー

ステップ1: プロジェクトの開始

# プロジェクトフォルダを作成
mkdir my-website
cd my-website

# Gitリポジトリを初期化
git init

# 最初のファイルを作成
echo "# My Website" > README.md

# 最初のコミット
git add README.md
git commit -m "初回コミット: プロジェクトの開始"

ステップ2: 開発サイクル

# 1. 機能を開発
# index.htmlを作成・編集...

# 2. 状態確認
git status

# 3. ステージング
git add index.html

# 4. コミット
git commit -m "トップページのHTMLを作成"

# 5. 続けて開発
# style.cssを作成...
git add style.css
git commit -m "スタイルシートを追加"

ステップ3: GitHubへのアップロード

# GitHubでリポジトリを作成(ブラウザで)

# リモートを追加
git remote add origin https://github.com/username/my-website.git

# pushする
git push -u origin main

日々の開発フロー

# 1. 作業開始
git pull  # 最新を取得(複数デバイスで作業する場合)

# 2. コーディング
# ...

# 3. コミット
git add .
git commit -m "○○機能を追加"

# 4. push
git push

# 5. 繰り返し

チーム開発での基本ワークフロー

初回セットアップ

# 1. リポジトリをクローン
git clone https://github.com/team/project.git
cd project

# 2. 最新の状態を確認
git pull

# 3. 準備完了

機能開発のフロー

# 1. 最新の状態に更新
git switch main
git pull

# 2. 新しいブランチを作成
git switch -c feature/user-profile

# 3. 開発
# コードを書く...
git add .
git commit -m "ユーザープロフィール機能を実装"

# 4. 追加の開発
# さらにコードを書く...
git add .
git commit -m "プロフィール編集機能を追加"

# 5. リモートにpush
git push -u origin feature/user-profile

# 6. GitHubでプルリクエストを作成

# 7. レビュー後、マージされる

# 8. ローカルのmainを更新
git switch main
git pull

# 9. 開発ブランチを削除
git branch -d feature/user-profile

毎日の作業開始時

# 必ず最新の状態に
git switch main
git pull

# 新しい作業を開始
git switch -c feature/new-feature

Git Flow – プロフェッショナルなブランチ戦略

Git Flowは、大規模プロジェクトで使われるブランチ管理の方法論です。

ブランチの種類

1. mainブランチ: 本番環境にデプロイされる安定版
2. developブランチ: 開発中の最新版
3. featureブランチ: 新機能開発用
4. releaseブランチ: リリース準備用
5. hotfixブランチ: 緊急バグ修正用

実際の流れ

# developから新機能ブランチを作成
git switch develop
git switch -c feature/payment-system

# 開発
git commit -m "決済システムを実装"

# developにマージ
git switch develop
git merge feature/payment-system

# リリース準備
git switch -c release/v1.0.0
# 最終調整...
git commit -m "バージョン番号を1.0.0に更新"

# mainにマージ(本番リリース)
git switch main
git merge release/v1.0.0
git tag v1.0.0

# developにもマージ(変更を反映)
git switch develop
git merge release/v1.0.0

GitHub Flow – シンプルなワークフロー

GitHub Flowは、より簡単なブランチ戦略です。初心者におすすめです。

原則

1. mainブランチは常にデプロイ可能
2. 新しい作業は必ずブランチを切る
3. 定期的にpushする
4. プルリクエストでレビュー
5. レビュー承認後にmainにマージ
6. マージ後すぐにデプロイ

実際の流れ

# mainから作業ブランチを作成
git switch main
git pull
git switch -c add-contact-form

# 開発とコミット
git add .
git commit -m "お問い合わせフォームを追加"
git push -u origin add-contact-form

# GitHubでプルリクエストを作成
# → レビュー → 承認 → マージ

# ローカルを更新
git switch main
git pull
git branch -d add-contact-form

Gitでよくあるエラーと解決方法を完全網羅

初心者が必ず遭遇するエラーとその解決方法を詳しく解説します。

コンフリクト(衝突)の解決方法

コンフリクトは、同じファイルの同じ場所を複数人が編集した時に発生します。

コンフリクトの発生

git merge feature/new-design
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

コンフリクトマーカーの見方

ファイルを開くと以下のような表示があります:

<header>
<<<<<<< HEAD
  <h1>Welcome to My Site</h1>
=======
  <h1>ようこそ、私のサイトへ</h1>
>>>>>>> feature/new-design
</header>

• <<<<<<< HEAD: 現在のブランチの内容
• =======: 境界線
• >>>>>>> feature/new-design: マージしようとしているブランチの内容

解決手順

# 1. ファイルを開いて編集
# マーカーを削除し、正しい内容にする

<header>
  <h1>ようこそ、私のサイトへ</h1>
</header>

# 2. 解決したことを記録
git add index.html

# 3. マージコミットを作成
git commit -m "Merge feature/new-design: コンフリクトを解決"

複数ファイルのコンフリクト

# コンフリクトしているファイルを確認
git status

# 一つずつ解決
git add file1.html
git add file2.css
git commit -m "コンフリクトを解決"

コンフリクトを避けるコツ

1. こまめにpullする
2. 小さな単位でコミット
3. 同じファイルを同時に編集しない
4. 作業前にチームで調整

「detached HEAD」状態の解決

特定のコミットをcheckoutすると、この状態になります。

エラーメッセージ

You are in 'detached HEAD' state...

解決方法

# ブランチに戻る
git switch main

# または、現在の状態で新しいブランチを作成
git switch -c new-branch-name

pushが拒否される場合

エラーメッセージ

! [rejected] main -> main (fetch first)
error: failed to push some refs

原因と解決

リモートに新しいコミットがあるため。

# 1. リモートの変更を取得
git pull

# 2. コンフリクトがあれば解決

# 3. 再度push
git push

別の解決方法: rebase

git pull --rebase
git push

コミットメッセージを間違えた

直前のコミットのメッセージを修正

git commit --amend -m "正しいメッセージ"

pushした後は注意

push済みのコミットメッセージを変更すると、他の人に影響します。

# ローカルで修正
git commit --amend -m "新しいメッセージ"

# 強制push(チームに確認してから)
git push -f

間違ったファイルをコミットした

まだpushしていない場合

# 直前のコミットを取り消し(変更は保持)
git reset --soft HEAD^

# 不要なファイルをステージングから外す
git reset HEAD 不要なファイル

# 再コミット
git commit -m "正しいメッセージ"

特定のファイルだけ削除

git rm --cached 不要なファイル
git commit -m "不要なファイルを削除"

.gitignoreが効かない

既にGitで追跡されているファイルは、.gitignoreに追加しても無視されません。

解決方法

# キャッシュから削除(ファイル自体は残る)
git rm --cached ファイル名

# または、フォルダ全体
git rm -r --cached フォルダ名

# .gitignoreに追加
echo "node_modules/" >> .gitignore

# コミット
git add .gitignore
git commit -m ".gitignoreを更新"

ブランチが削除できない

エラーメッセージ

error: The branch 'feature-branch' is not fully merged.

原因: マージされていないブランチは保護される

解決方法

# マージしてから削除
git switch main
git merge feature-branch
git branch -d feature-branch

# または強制削除(変更を破棄)
git branch -D feature-branch

GitHubとの連携を初心者向けに完全ガイド

GitとGitHubは異なります。GitHubはGitリポジトリをホスティングするWebサービスです。

GitHubアカウントの作成手順

ステップ1: サインアップ

1. github.comにアクセス
2. 「Sign up」をクリック
3. メールアドレスを入力
4. パスワードを作成(強力なものを)
5. ユーザー名を決定(後から変更可能)
6. メール認証を完了

ユーザー名の選び方

• 就職活動で使うことを考慮
• 短くて覚えやすい
• プロフェッショナルな印象
• 既に使っている他のSNSと統一も検討

プロフィールの設定

1. プロフィール画像をアップロード
2. 自己紹介を記入
3. ウェブサイトやSNSリンクを追加
4. 所在地を記入(任意)

新しいリポジトリの作成方法

GitHubでの操作

1. 右上の「+」アイコンをクリック
2. 「New repository」を選択
3. リポジトリ名を入力(例: my-first-project)
4. 説明を記入(任意)
5. Public/Privateを選択
   • Public: 誰でも見られる
   • Private: 自分と招待した人だけ
6. 「Initialize this repository with a README」にチェック(任意)
7. .gitignoreテンプレートを選択(任意)
8. ライセンスを選択(任意)
9. 「Create repository」をクリック

ローカルと連携

# 新規プロジェクトの場合
git init
git add .
git commit -m "初回コミット"
git remote add origin https://github.com/username/repo-name.git
git branch -M main
git push -u origin main

# 既存のリポジトリをクローン
git clone https://github.com/username/repo-name.git

SSH接続の設定(セキュリティ向上)

HTTPS接続よりSSHの方が安全で便利です。

ステップ1: SSH鍵の生成

# SSH鍵を生成
ssh-keygen -t ed25519 -C "your.email@example.com"

# Enter押下(デフォルトの保存場所)
# パスフレーズを設定(推奨、空でもOK)

ステップ2: SSH鍵をGitHubに登録

# 公開鍵の内容を表示(Mac/Linux)
cat ~/.ssh/id_ed25519.pub

# Windowsの場合
type %USERPROFILE%\.ssh\id_ed25519.pub

1. 表示された内容をコピー
2. GitHubの Settings > SSH and GPG keys
3. 「New SSH key」をクリック
4. タイトルを入力(例: My Laptop)
5. 鍵の内容をペースト
6. 「Add SSH key」をクリック

ステップ3: 接続テスト

ssh -T git@github.com

成功すると:

Hi username! You've successfully authenticated...

SSH URLに変更

# HTTPSからSSHに変更
git remote set-url origin git@github.com:username/repo-name.git

# 確認
git remote -v

プルリクエスト(Pull Request)の作り方

プルリクエストは、あなたの変更をプロジェクトに取り込んでもらうためのリクエストです。

ステップ1: ブランチを作成してpush

git switch -c feature/new-feature
# 開発...
git add .
git commit -m "新機能を追加"
git push -u origin feature/new-feature

ステップ2: GitHubでプルリクエストを作成

1. GitHubのリポジトリページを開く
2. 「Compare & pull request」ボタンが表示されるのでクリック
3. タイトルを入力(コミットメッセージが自動入力される)
4. 説明を記入
   • 何を変更したか
   • なぜ変更したか
   • テスト方法
   • スクリーンショット(UI変更の場合)
5. レビュアーを指定(チームの場合)
6. 「Create pull request」をクリック

良いプルリクエストの書き方

## 変更内容
ユーザーログイン機能を実装しました。

## 変更理由
Issue #123 に対応するため

## 変更詳細
- メールアドレスとパスワードでのログイン
- ログイン状態の保持(セッション)
- ログアウト機能

## テスト方法
1. ログインページにアクセス
2. メールアドレスとパスワードを入力
3. 「ログイン」ボタンをクリック
4. ダッシュボードにリダイレクトされることを確認

## スクリーンショット
![ログイン画面](url)

## チェックリスト
- [x] テストを実行して通過
- [x] コードレビューの準備完了
- [x] ドキュメントを更新

Issueの活用方法

Issueは、バグ報告や機能リクエストを管理する機能です。

Issueの作成

1. リポジトリの「Issues」タブ
2. 「New issue」をクリック
3. タイトルを入力
4. 詳細を記入
5. ラベルを付ける(bug, enhancement, etc.)
6. 担当者を指定(任意)
7. 「Submit new issue」をクリック

良いIssueの書き方

## 問題の説明
ログインボタンをクリックしてもログインできません。

## 再現手順
1. ログインページにアクセス
2. メールアドレス: test@example.com
3. パスワード: password123
4. 「ログイン」ボタンをクリック
5. エラーメッセージが表示される

## 期待される動作
ログイン後、ダッシュボードに遷移する

## 実際の動作
「認証に失敗しました」とエラーが表示される

## 環境
- OS: Windows 11
- ブラウザ: Chrome 120
- バージョン: v1.0.0

## スクリーンショット
![エラー画面](url)

.gitignoreファイルの作成と活用方法

.gitignoreは、Gitで追跡しないファイルを指定するための設定ファイルです。

.gitignoreの基本

作成方法

# プロジェクトルートに作成
touch .gitignore

# または手動でファイル作成

基本的な書き方

# コメント

# 特定のファイルを無視
secret.txt
config.json

# 特定の拡張子を無視
*.log
*.tmp

# 特定のフォルダを無視
node_modules/
dist/
.cache/

# パターンマッチング
*.py[cod]
*$py.class

# 例外(無視しない)
!important.log

プログラミング言語別の.gitignore例

JavaScript/Node.js

# Dependencies
node_modules/
package-lock.json
yarn.lock

# Build
dist/
build/
.next/
out/

# Environment
.env
.env.local

# IDE
.vscode/
.idea/
*.swp
*.swo

# OS
.DS_Store
Thumbs.db

# Logs
logs/
*.log
npm-debug.log*

Python

# Byte-compiled
__pycache__/
*.py[cod]
*$py.class

# Virtual Environment
venv/
env/
ENV/

# Distribution
dist/
build/
*.egg-info/

# IDE
.vscode/
.idea/
*.swp

# Environment
.env

# Jupyter Notebook
.ipynb_checkpoints

Java

# Compiled
*.class
*.jar
*.war
*.ear

# Build
target/
build/
out/

# IDE
.idea/
*.iml
.eclipse/
.settings/

# OS
.DS_Store
Thumbs.db

# Log
*.log

PHP

# Vendor
vendor/
composer.lock

# Environment
.env

# Cache
cache/
*.cache

# IDE
.vscode/
.idea/
*.swp

# OS
.DS_Store
Thumbs.db

グローバル.gitignoreの設定

すべてのリポジトリで共通して無視したいファイル(IDEの設定ファイルなど)は、グローバルに設定できます。

# グローバル.gitignoreファイルを作成
touch ~/.gitignore_global

# 設定
git config --global core.excludesfile ~/.gitignore_global

~/.gitignore_globalの例

# IDE
.vscode/
.idea/
*.swp
*.swo
*~

# OS
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db

まとめ

gitは開発する上で、必須と言っても過言でないものであるとともに大きく開発に影響を与えるものになります。

皆さんもぜひgitを身につけましょう！

参考文献

https://git-scm.com/docs

＼ 最新情報をチェック ／