Zenn
🗂️

公式ドキュメントで学ぶ Git/GitHubの違い（cloneからcommit・push・PullRequestまで）

に公開
Git
GitHub
VS Code
初心者
クラウド
tech

本記事の目的

「Git ってなんとなく難しそう…」と感じている方へ
リポジトリとは何か、最低限の操作フローはどうなっているか――
その “イメージ” をつかむことをゴールにした入門記事です。

想定する読者

区分 対応 補足
個人開発の初心者 ✅ clone → add → commit → push を体験したい方
チーム開発に入門したメンバー ✅ Pull Request 前後の流れを知りたい方
運用担当（既に大規模リポジトリを管理中） ❌ 本記事では深い運用ノウハウは扱いません
Git をカスタマイズしたい個人開発者 ✅ .gitignore や .gitattributes の基礎も触れます

Git リポジトリとは？

Git リポジトリは 「プロジェクト一式 ＋ その変更履歴」をまとめて保管する場所 です。
履歴には いつ・誰が・どのように 変更したかが記録されるため、過去の状態へ自由に戻ったり、比較したりできます。

イメージ
プロジェクトフォルダーまるごとが “履歴の見えるフォルダー” になる。
中のファイルを編集すると、その変更がすべて履歴に記録される。

リポジトリの種類

種類 保存場所 主な用途
ローカルリポジトリ 自分の PC 内 個人の作業・履歴管理
リモートリポジトリ ネット上（GitHub など） 共有・バックアップ

代表的なリモートサービス：GitHub / GitLab / Bitbucket

リモートリポジトリの操作イメージ

GitHub などのリモートリポジトリは、
OneDrive・Google ドライブ・iCloud といったクラウドストレージを
“手動で同期 する” ような感覚に近いです。

観点 クラウドストレージ (OneDrive 等) GitHub (リモートリポジトリ)
同期方法 ほぼ自動・常に最新版 手動 push / pull
（CLI / GUI どちらでも可）
履歴管理 最新版が基本 全てのコミット履歴 を保持
コラボ機能 共有・同時編集 ブランチ / レビュー / CI など開発特化
Git 独自の機能
  • 変更履歴の完全保存
  • ブランチ による並行開発
  • Pull Request / Code Review
  • CI/CD（GitHub Actions など）
    単なるファイル共有と違い、「開発を安全かつ効率的に進める仕組み」 がそろっています。

以下にGit, GitHubイメージを示します。
「ローカルリポジトリ」と「GitHub リモート」の関係を示す概念図（矢印で push／pull の流れを表示）

Gitのインストールと設定

  1. ダウンロードリンク

https://git-scm.com/downloads

  1. インストール方法のリンク

https://git-scm.com/book/ja/v2/使い始める-Gitのインストール

  1. ユーザー情報の登録（初回のみ）
    下記コマンドを実行すると、PC 内のすべてのリポジトリで同じ名前とメールアドレスがコミット署名に使われます（--global オプション）。
    GitHub にプッシュする場合は “誰が変更したか” を正しく紐付けるため、GitHub アカウントと同じ user.name / user.email を設定してください。
Gitコマンド - 初期設定
git config --global user.name "あなたの名前"
git config --global user.email "あなたのメールアドレス"

https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

設定しないと VSCode でどのようなエラーが出る？

設定せずにコミットを行うと「Gitの"user.name"と"user.email"の構成を確認してください」と表示されます。
VS Code で Gitの"user.name"と"user.email"の構成を確認してください エラーが表示され、コミットが失敗しているエラー

GitHub へプッシュできない場合

  • 原因：
    GitHub アカウントの 「Keep my email addresses private（メールアドレス非公開）」 が有効で、自動生成の noreply メールアドレス と user.email が一致していない。

  • 対処：

    1. GitHub の Settings › Emails で表示される xxxx@users.noreply.github.com を設定する。
      また、コミット済みの場合は修正する必要があります。
    Gitコマンド - email設定
    git config --global user.email "xxxx@users.noreply.github.com"
    1. もしくはオプションをオフにして、公開メールアドレスと同じものを user.email に設定する。

Git操作

操作方法はローカル操作、クラウド操作に分けて説明します。

  • ローカル操作とは自分のPCのローカルリポジトリに影響します。
  • クラウド操作とはGitHubなどのリモートリポジトリクラウド上のデータに影響します。

また、Gitを使うにあたって、基本はVSCodeで行います。

なぜ VSCode で Git を扱うのか？

VSCodeは直感的で迷わないGitのGUIを提供しています。また、豊富な拡張機能が提供されているので個人に合わせた使い方ができます。
GUI では扱いにくい複雑な操作も(該当プロジェクトのパスで)ターミナルをすぐに開くことができます。
Git では差分が取れない文字コードでもVSCodeなら変更点を確認できる場合があります。(そのような文字コードはできるだけ使うのをやめた方がいいです。)

また、IDEにもGitをGUIで扱うこともできますが、個人的には自分の使い慣れたクライアントソフトを使うことがおすすめです。

例：
Windows 開発
コード編集Visual Studio 2022 + Git操作VSCode

Mac 開発
コード編集Xcode + Git操作VSCode


VSCodeのインストール

インストール方法のリンク
https://code.visualstudio.com/docs/setup/setup-overview

"VS Code で Git ソース管理を使用する" 公式リンク
https://code.visualstudio.com/docs/sourcecontrol/overview


VSCode以外のGitGUIアプリケーション

  1. Git GUI
    Gitインストール時に同梱されています。

https://git-scm.com/downloads/guis
2. Sourcetree

https://www.sourcetreeapp.com/

  1. GitKraken

https://www.gitkraken.com/

Git リポジトリの作成、または取得

Gitを使い始めるにはinitまたは、cloneする必要があります。
https://git-scm.com/book/ja/v2/Git-の基本-Git-リポジトリの取得

init(リポジトリの作成 - ローカル操作)

initとはローカルのファイル(ディレクトリ[LinuxやMacでよく使われる用語でファイルと同じ意味])の中で行う操作です。
この操作を行うとGitリポジトリの作成が行われ、必要な設定やファイルが追加されます。

以下のコマンド使用するとコマンド実行時のパスの中にリポジトリが作成されます。

Gitコマンド - init
git init

https://git-scm.com/docs/git-init/ja

以下にVSCodeの操作イメージを示します。
VSCodeのソース管理ビューで「初期化（Initialize Repository）」ボタンを押す画面

clone(リポジトリの取得 - ローカル操作)

リモートリポジトリを自分のPCにローカルリポジトリとしてダウンロードします

Gitコマンド - clone
git clone <URL>

https://git-scm.com/docs/git-clone/ja

GitHubからURL取得の画像を示します。
GitHubからURLを取得してコピーする

以下にVSCodeの操作イメージを示します。
VS Code のコマンドパレットで「Git: Clone」を実行し、URL を入力する画面

add（ステージに追加 – ローカル操作）

git add は 変更したファイルを “ステージ（staged）” 状態に置く コマンドです。
ステージに乗ったファイルだけが、次の git commit で履歴に保存されます。

コマンド例

Git コマンド - add
# 単一ファイルをステージ
git add src/main.cpp

# 変更されたファイルをまとめてステージ
git add .

# add した場合の取り消し
git restore --staged <file>

https://git-scm.com/docs/git-add/ja

以下にVSCodeの操作イメージを示します。
VSCodeの変更ビューでファイルに+ボタンを押してステージ（git add）した状態

commit（コミット – ローカル操作）

git commit は ステージされた変更（staged）を 1 つのスナップショットとして履歴に保存するコマンドです。
変更のないファイルは前回コミットの内容を参照するため、差分のみが効率的に記録されます。

スナップショットとは？
その時点で 変更されたファイルの内容 を丸ごと保存すること。
Git はスナップショット同士の差分を内部で計算し、最小コストで履歴を保持します。

基本構文

Git コマンド - commit
git commit -m "メッセージ"     # インラインでメッセージを付ける

https://git-scm.com/docs/git-commit

以下にVSCodeの操作イメージを示します。
VSCodeのソース管理パネルでコミットメッセージを入力し、「コミット」ボタンを押して変更履歴を保存（git commit）する画面

https://git-scm.com/book/ja/v2/使い始める-Gitの基本

https://git-scm.com/book/ja/v2/Git-の基本-変更内容のリポジトリへの記録

コミット履歴の閲覧

以下にVSCodeの操作イメージを示します。
Git Graph拡張機能をインストールして表示しています。
VSCodeの拡張機能「Git Graph」を使い、コミット履歴をグラフィカルに表示している画面

https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph

https://git-scm.com/book/ja/v2/Git-の基本-コミット履歴の閲覧

branch(ブランチ - ローカル操作)

ブランチは「特定コミットを指し続ける可動ポインタ」
（ファイルのショートカットのようなイメージ）

  1. まず main ブランチで作業中のコミット C があるとします。
  2. C の位置で git branch develop を実行すると、
    develop ポインタが C を指して誕生します。
  3. その後 main が D → E と先へ進んでも、
    develop は引き続き C から枝分かれして独自に進みます。
ブランチはいつ作成する？

ブランチを切るタイミングは 「新しい開発・修正に取り掛かる前」 が原則です。

チーム開発では develop ブランチの履歴が絶えず更新されます。
そこで、作業開始前に develop の最新コミットを基点とした作業ブランチ
（例：feature/login-ui や fix/err）を作成しておけば、

  • 自分の変更が他人に影響しない
  • 他人の変更に作業が阻害されない

という２つのメリットを得られます。

branchイメージ
(main) A──B──C──D──E        ← main
              \
               F──G         ← develop

https://git-scm.com/book/ja/v2/Git-のブランチ機能-ブランチとは

merge（マージコミット）

git merge は 指定したブランチの履歴を、現在のブランチへ統合するコマンドです。
処理の結果、2 つの履歴が 1 本にまとまり、マージコミット が 1 つ生成されます。

このマージコミットにより、分岐していた 2 つの履歴が 1 本にまとめられます。

マージはいつ行う？

開発・修正用ブランチ（例: feature/login-ui や fix/err）での作業が完了し、
テストやコードレビュー（プルリクエスト）も通過したら、派生元の develop ブランチへマージ します。

マージが済んだ作業ブランチは、通常 削除 して役目を終えます。
もし同じブランチで追加作業を続ける場合は、いったん develop を取り込んで（git merge develop または git rebase develop）
最新状態に追従してから作業を再開しましょう。

または、プルリクエスト を出す 直前 に、派生元である develop ブランチを自分の作業ブランチへ取り込み（merge または rebase）、
最新状態でビルド・テストを通してから PR を作成するという手順も有効です。
このようにすることで、レビュー後に想定外のコンフリクトや CI（Continuous Integration） エラーが発生しにくくなります。

mergeイメージ
main:    A──B──C──D             ← main
                   \
develop:            E──F        ← develop


main:    A──B──C──D──────G      ← main (G がマージコミット)
                　　\    /
                  　 E──F

基本構文

Git コマンド - merge
# 例: feature ブランチを現在の main に取り込む
git merge feature

https://git-scm.com/docs/git-merge

https://git-scm.com/book/ja/v2/Git-のブランチ機能-ブランチとマージの基本

https://github.com/skills/resolve-merge-conflicts

tagをつける(タグ - ローカル操作)

タグは “特定のコミットに名札を付ける” 機能。
リリースやマイルストーンなど ここが大事 をひと目で分かるように残せます。

種類 特徴 コマンド例
軽量タグ (light-weight) ポインタでメッセージや署名なし git tag v1.0
注釈付きタグ (annotated) 作成者・日時・メッセージ・署名を保存。リリース用はコレ git tag -a v1.0 -m "初回リリース"
Git コマンド - tag
# 過去のコミットに軽量タグ
git tag bugfix-2025 3a5c9e2

# 最新コミットに注釈付きタグ
git tag -a v1.0 -m "初回リリース"

https://git-scm.com/book/ja/v2/Git-の基本-タグ

push（プッシュ – クラウド操作）

push は ローカルで commit した履歴をリモートリポジトリへ送信するコマンドです。
これにより、チームメンバーが git pull であなたの変更を取り込めるようになります。

Git コマンド - push
git push origin main            # main ブランチを送信
git push -u origin feature-x    # 初回だけ -u で upstream を登録

https://git-scm.com/docs/git-push

以下にVSCodeの操作イメージを示します。
VSCodeのステータスバーにある「変更の同期」ボタンをクリックして、ローカルのコミットをリモートへpushする操作画面

fetch

fetchは「リモートリポジトリの最新履歴を取得し、リモート追跡ブランチだけを更新する」コマンドです。
作業ツリー（ワークツリー）と現在のブランチは一切書き換えないため、ローカルコードはそのまま。あとで内容を確認し、必要なら自分で merge や rebase を実行します。

Gitコマンド - fetch
git fetch [remote]

https://git-scm.com/docs/git-fetch

pull（プル – クラウド操作）

pull は リモートリポジトリの最新コミットを取得してローカルブランチへ統合するコマンドです。
内部的には fetch（履歴取得）＋merge（作業ツリーへ反映）の 2 ステップを一度に実行します。

"Git コマンド - pull"
git pull origin main             # origin/main を取り込み

https://git-scm.com/docs/git-pull

以下にVSCodeの操作イメージを示します。
VSCodeのステータスバーにある「変更の同期」ボタンを使い、リモートリポジトリの最新の変更をpullしてローカルに反映させる操作画面

https://git-scm.com/book/ja/v2/Git-のブランチ機能-リモートブランチ#:~:text=になります。-,プル,-git fetch コマンド

pull request（プルリクエスト – クラウド操作）

Pull Request（PR） は「リモートリポジトリ上で行う、変更内容のレビュー申請」です。
ブランチで実装したコミットをメインブランチへ統合してもらう前に、差分を提示し、レビュー・テスト・議論を行うためのワークフローを提供します。

pull requestの語源とは - pullとは逆？

「プルリクエスト」という名前は、もともとの Git の分散型ワークフローに由来しています。
※【】はfork後を想定しています。

  1. 変更を作った人（あなた）は、自分のローカル → clone元【または、自分の公開リポジトリ】 へpush して作業を終えます。
  2. その時点では、clone元のリポジトリのmainブランチ【または、メイン開発者のリポジトリ】には何も届いていません。
  3. そこで「あなたのリポジトリから pull（取り込んで）ください」という “お願い” を送る――これが pull request です。

つまり 「プッシュした変更を取り込んでほしい」という依頼＝Pull してくださいリクエスト。
GitHub では中央のリポジトリ（origin）に対してボタン 1 つで送る形になったため「自分→中央に push したあと pull request を出す」という順序がやや逆転して見えますが、語源は “相手に pull を頼む” という発想のまま残っています。


以下にforkなしのイメージを示します。
forkを使わない場合のPull Requestの概念図。同一リモートリポジトリ内で、あるブランチからmainブランチへのマージを依頼している様子。

以下にfork後のイメージを示します。
forkを使った場合のPull Requestの概念図。開発者が自身のforkリポジトリに変更をpushし、そこから本家（upstream）のリポジトリへ取り込みを依頼している様子。

https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

fork（フォーク - クラウド操作）

fork（フォーク） とは、GitHub上の公開リポジトリを
自分のGitHubアカウントに“複製” して独立した開発スペースを作る機能です。
オリジナル（upstream）には書き込み権限がなくても、fork なら自由に push・PR が行えます。
fork後(自分のGitHubアカウントから)cloneして作業を行います。

fork のメリット

目的 fork を使う理由
OSS への貢献 本家に直接 push せず、自分の fork で安全に開発→Pull Request
実験的な改造 元コードを崩しても upstream に影響なし
学習用コピー 公開リポジトリを fork してローカルで好きに試せる

基本フロー（GitHub）

  1. GitHub で対象リポジトリを開き、右上の Fork ボタンをクリック
  2. 自分のアカウント（yourname/sample-app）に fork が作成される
  3. git clone https://github.com/yourname/sample-app.git でローカルに取得
  4. ブランチを切って開発 → 自分の fork に push
  5. GitHub 上で Pull Request を作成し、
    base(fork元): upstream/main ← compare: yourname/feature-xyz を指定
  6. レビューが通れば upstream にマージされる

fork と clone の違い

比較項目 fork clone
何が作られる？ GitHub 上の新リポジトリ ローカル PC 上のコピー
権限 自分の fork なので 書き込み可 ローカルは常に書き込み可
目的 OSS への貢献・安全な開発スペース 開発作業を手元で行う
典型操作 Web で Fork → git clone → PR git clone → ブランチ開発

💡 ポイント

  • fork はあくまで “GitHub 上での複製” であり、Git の概念（コミット・ブランチ）はそのまま持ち越されます。
  • 自分の fork を最新に保つには git remote add upstream … で元リポジトリを登録し、git pull upstream main (git fetch upstream → git merge or rebase) を行います。

https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo

Git カスタマイズ

追跡除外（ignore の設定）

Git で「履歴に入れたくないファイル」は .gitignore で指定します。
ビルド成果物・ログ・一時ファイル・OS が自動生成するメタデータなどを除外しておくと、リポジトリがクリーンに保てます。

.gitignore の 3 つの置き場所

優先度 ファイル 適用範囲 用途例
1 .git/info/exclude そのリポジトリだけ（ローカル限定・Git 管理外） 個人の IDE 設定、デバッグ用メモ
2 プロジェクト直下の .gitignore リポジトリ全体（共有） ビルド成果物、環境依存ファイル
3 グローバル ignore
~/.config/git/ignore など		 自分の PC 全リポジトリ共通 OS が生成する .DS_Store や Thumbs.db

.gitignore は 上から下へ、より近い階層が優先。
ローカル専用の除外は .git/info/exclude に書くと共有されないので便利です。

よく使うパターン例

.gitignore
# ビルド成果物
/dist/
/build/

# OS / エディタ
.DS_Store
Thumbs.db
*.swp

# Node.js
node_modules/
.env

# Python
__pycache__/
*.py[cod]

バイナリを “テキスト化” して差分を取る方法

Git が MS-DOS の .TXT をバイナリ判定してしまう問題と対処法

TL;DR
MS-DOS 由来の .TXT には 0x1A (Ctrl-Z) や NUL 文字が入りやすく、
Git はそれを見て「バイナリ」と誤判定する。
.gitattributes に text diff を付けるか、
textconv フィルタで制御コードを除去すれば、行差分を正しく表示できる。

なぜ Git はテキストをバイナリと誤判定するのか？

Git の自動判定ロジックは 「ファイルに NUL 文字があるか」 で決めています。
古い MS-DOS のテキストは

  • 行末が CR+LF
  • 末尾に 0x1A (Ctrl-Z) が混入
  • まれに NUL (0x00) も入る

このような制御のため Git は Binary files differ と判断してしまう。

解決策 .gitattributes に「これはテキスト」と明示する

.gitattributes
# すべての .TXT を強制的にテキスト扱い
*.TXT text diff

https://git-scm.com/book/ja/v2/Git-のカスタマイズ-Git-の属性

Git で diff が表示できない文字コード とその対策

Git は ASCII 互換（UTF-8 / ISO-8859-1 など）のテキスト を想定しているため、
UTF-16 や Shift-JIS のファイルは標準設定では「バイナリ扱い」になります。
git diff や GitHub／GitLab の Web UI で内容が見えず
Binary files differ とだけ表示されるのはこのためです。

https://git-scm.com/docs/gitattributes/2.21.0

なぜ UTF-16 が「バイナリ」判定されるのか？

  • Git は NUL 文字 (0x00) を含むファイルをバイナリと見なす
  • UTF-16 は 2 バイト単位で文字を表すため、偶数バイト側に 0x00 が頻出
  • 結果として diff / blame / grep などテキスト系サブコマンドがスキップされる

解決策 3 パターン

方法 使いどころ メリット 注意点
① working-tree-encoding 属性 チーム全員が 最新版 Git を使用 (推奨) add 時に UTF-16 → UTF-8 へ再エンコード → 以降は普通のテキスト扱い JGit・libgit2・古い Git は未対応
② --text / -a オプション その場で一回だけ見たい 追加設定ゼロで即表示 毎回オプションが必要
文字化けの可能性
③ textconv フィルター 混在環境・大規模リポジトリ diff 時だけ UTF-16 → UTF-8 に変換 .gitattributes と gitconfig の両方設定

UTF-16 ↔ UTF-8 の往復変換は“理論上ロスレス”──でも絶対保証ではない

Unicode なので文字そのものは失われませんが、BOM（Byte Order Mark）・改行コード・正規化形式など
“付随情報” がずれると Git や iconv が化けたと判定してしまうケースがあります。

  • UTF-16 LE (BOM なし) → UTF-8 → UTF-16 LE (今度は BOM 付き)…など微妙な差
  • Windows CRLF ↔ Unix LF が混在し、diff が毎回真っ赤
  • macOS の NFD と Linux/Windows の NFC の正規化差

現実的な対策：テキスト比較は VS Code など高機能エディタで行う

理由 具体的メリット
エンコーディング自動判定が高精度 BOM の有無・UTF-16LE/BE を自動検知し、文字化けを最小化
エンコーディング強制切替が GUI で容易 ステータスバーやコマンドパレットから即変更＆再読み込み
改行コード／BOM の可視化プラグインが豊富 「ここだけ CRLF」「ここに BOM」が目で分かる
差分ビューが柔軟 サイドバイサイド／インライン切替、ホワイトスペース無視などオプション豊富
Git 拡張と統合 ファイル単位で Revert／Stage が出来るため誤コミットを防止

💡 実務 tip

  1. まず VS Code（または IntelliJ, Sublime など）の 差分ビューで
    「本当に往復で同一か」「BOM や改行が変わっていないか」を確認。
  2. 問題なければ git add。不一致なら VS Code 上で改行/BOM を修正して再チェック。
  3. 可能なら CI で iconv round-trip テストを回し、“化けコミット” をブロック。

まとめ

  • UTF-16 ↔ UTF-8 自体は文字損失なし → 理論上 ロスレス
  • しかし BOM／改行／正規化差で「同一に見えて違う」状態が起こりうる
  • Git だけに頼らず VS Code など GUI で差分を確認するのが安全
  • 最終防衛線として CI で round-trip 検査 を置くと安心

Gitログの表示

よくわからなくなったらエラーログをコピーしてchatGPTなどに聞いてみましょう。

Gitコマンド - ログ表示
git log --oneline --graph --decorate

https://git-scm.com/book/ja/v2/Git-の基本-コミット履歴の閲覧

https://git-scm.com/book/ja/v2/Git-の基本-作業のやり直し

Gitの使用用途

VS Code（Microsoft）

VS Code は Microsoft が開発・公開している大規模なオープンソースソフトウェアです。世界中の開発者が毎日数百件の Pull Request を送り、Fork → PR → CI → Merge という GitHub のワークフローをフル活用しながら機能追加やバグ修正を行っています。
https://github.com/microsoft/vscode

ホワイトハウス

アメリカ連邦政府は公式文書や Web サイトのソースコードを GitHub 上で公開しています。コミット履歴をそのまま公開することで透明性を高め、市民が Issue 経由でフィードバックを送れる仕組みも整えています。このように行政分野でも「ガバメント as Code」として Git が活用されています。
https://github.com/whitehouse

Zenn（技術ブログ）

技術系ブログサービス Zenn の CLI を利用すると、記事や本の Markdown 原稿をローカルで編集し、そのまま GitHub でバージョン管理できます。誤字修正や加筆をコミット単位で追跡できるため、原稿の変更履歴が一目で分かります。ブログ執筆のような個人ユースでも Git は十分に役立つことが分かる事例です。
https://zenn.dev/zenn/articles/zenn-cli-guide

Discussion