GitとGitHubの基本をやさしく理解する｜repository・commit・branch・push・pullとは

GitやGitHubを学び始めると、repository、commit、branch、push、pullといった用語が次々に登場します。

一つひとつの意味を暗記しようとすると難しく感じますが、これらはすべて、ファイルの変更履歴を安全に管理し、必要に応じて他の場所や他の人と共有するための仕組みです。

この記事では、GitとGitHubの役割の違いを確認したうえで、主要な用語と基本的な作業の流れを初学者向けに整理します。

まず知っておきたいGitとGitHubの違い

GitとGitHubは同じものではありません。

Gitは、自分のパソコン上で動く履歴管理の仕組みです。GitHubは、そのGitで管理しているプロジェクトをインターネット上に保存し、共有しやすくするサービスです。

たとえば、機械設計の変更履歴に置き換えると、Gitは「図面や計算書の変更履歴を管理する仕組み」、GitHubは「その履歴を含む設計資料を保管・共有するサーバー」に近い存在です。

ただし、GitHubは単なる保管場所ではありません。変更内容の確認、レビュー、課題管理、自動テストなど、共同作業や開発を支援する機能も備えています。

全体像を先に理解しよう

Gitを使った基本的な流れは、次のようになります。

flowchart LR
    A[作業フォルダ<br>ファイルを編集] -->|git add| B[ステージング領域<br>記録対象を選ぶ]
    B -->|git commit| C[ローカルリポジトリ<br>履歴として記録]
    C -->|git push| D[GitHub<br>リモートリポジトリ]
    D -->|git pull| C

重要なのは、ファイルを編集しただけではGitの履歴にならず、commitしただけではGitHubへ送られないことです。

大まかには、次の4段階に分かれます。

1. ファイルを編集する
2. git addで、次に記録する変更を選ぶ
3. git commitで、自分のパソコンに履歴を記録する
4. git pushで、その履歴をGitHubへ送る

この位置関係を理解すると、それぞれの用語がつながって見えるようになります。

repositoryとは

repositoryは、日本語では「リポジトリ」と呼ばれます。

リポジトリとは、プロジェクトのファイルと、その変更履歴をまとめて管理する場所です。単なるフォルダではなく、過去にどのような変更が行われたかという履歴も含んでいます。

リポジトリには、大きく分けて2種類あります。

ローカルリポジトリ

自分のパソコンにあるリポジトリです。

ファイルを編集したり、変更をコミットしたりする作業は、基本的にローカルリポジトリで行います。Gitはローカルだけでも使えるため、インターネットに接続していなくてもコミットや履歴確認ができます。

リモートリポジトリ

ネットワーク上にあるリポジトリです。

GitHub上のリポジトリは、代表的なリモートリポジトリです。複数のパソコンで同じプロジェクトを扱ったり、ほかの人と共同作業したりするときに利用します。

つまり、同じプロジェクトについて、次の二つが存在することがあります。

• 自分のパソコンにあるローカルリポジトリ
• GitHubにあるリモートリポジトリ

pushとpullは、この二つの間で変更履歴をやり取りする操作です。

commitとは

commitは、選択した変更を一つの履歴としてローカルリポジトリに記録する操作です。

コミットには、記録した時点のファイルの状態だけでなく、作成者、日時、変更内容を説明するメッセージなどが含まれます。各コミットには識別用のIDも付けられます。

たとえば、次のような変更を行ったとします。

• 計算式の誤りを修正した
• 入力欄を追加した
• 表示単位をMPaに変更した

これらを一度にまとめず、意味のある単位でコミットしておけば、後から「どの変更で何が変わったのか」を追いやすくなります。

git add src/calculation.py
git commit -m "圧力損失の計算式を修正"

ここで注意したいのは、commitは通常の上書き保存とは異なることです。

コミットした時点では、履歴はまだ自分のパソコンにあります。GitHubへ反映するには、さらにpushが必要です。

良いコミットの考え方

コミットは、できるだけ「一つの目的につき一つ」にすると管理しやすくなります。

たとえば、機能追加と無関係なデザイン変更を一つのコミットに混ぜるより、別々に記録した方が、確認や取り消しが簡単です。

コミットメッセージには、変更内容が後から分かる文章を書きます。

悪い例：修正
良い例：流量入力欄に上限チェックを追加

branchとは

branchは、同じプロジェクトの履歴から分岐して、別の変更を進めるための仕組みです。日本語では「ブランチ」と呼ばれます。

通常、中心となるブランチにはmainという名前が使われます。新しい機能を作るときは、mainから作業用ブランチを分岐させることができます。

gitGraph
    commit id: "基本版"
    commit id: "修正版"
    branch feature-calculator
    checkout feature-calculator
    commit id: "入力欄追加"
    commit id: "計算処理追加"
    checkout main
    commit id: "文書修正"
    merge feature-calculator

たとえば、公開中のmainブランチを安定した状態に保ちながら、新しい重量計算機能をfeature/weight-calculatorブランチで開発できます。

git switch -c feature/weight-calculator

作業が完了したら、そのブランチの変更をmainへ統合します。この統合操作をmergeと呼びます。

ブランチは、プロジェクトフォルダ全体を単純に複製したものではありません。Git内部では、コミットの流れを指し示す軽量な仕組みとして管理されています。そのため、目的ごとにブランチを作っても、通常は大きな負担にはなりません。

pushとは

pushは、ローカルリポジトリにあるコミットを、GitHubなどのリモートリポジトリへ送る操作です。

git push origin main

この例では、次の意味になります。

• origin：リモートリポジトリに付けられた一般的な名前
• main：送信するブランチ名

pushで送られるのは、原則としてコミット済みの履歴です。ファイルを編集しただけの変更や、git addしただけでまだコミットしていない変更は送られません。

つまり、次の理解が重要です。

ファイルを保存しただけ → GitHubには送られない
commitしただけ          → GitHubには送られない
commitしてpushする       → GitHubへ履歴が送られる

なお、GitHub側に自分が持っていない新しい変更がある場合、pushが拒否されることがあります。その場合は、先にpullなどで変更を取り込み、内容を整理してから再度pushします。

pullとは

pullは、GitHubなどのリモートリポジトリにある新しい変更を取得し、現在のローカルブランチへ取り込む操作です。

git pull origin main

複数のパソコンで作業している場合や、共同開発者がGitHubへ変更を送った場合は、自分のローカルリポジトリが古い状態になることがあります。pullを実行すると、リモート側の新しい履歴を自分の環境へ反映できます。

一般的な設定では、git pullは内部的に次の二つの処理を行います。

1. fetch：リモートの新しい履歴を取得する
2. merge：取得した履歴を現在のブランチへ統合する

設定によっては、mergeではなくrebaseが使われる場合もあります。初学者の段階では、まず「pullはリモートの変更を取得し、自分のブランチへ取り込む操作」と理解すれば十分です。

pushとpullの方向を整理する

pushとpullは、変更履歴を動かす方向が反対です。

英単語のイメージで考えると覚えやすくなります。

• push：自分から向こうへ押し出す
• pull：向こうから自分へ引き寄せる

ただし、送受信の対象は単なるファイルではなく、基本的にはGitが管理するコミットとその履歴です。

基本的な作業の流れ

すでにローカルリポジトリとGitHubの接続が済んでいる場合、日常的な作業は次のようになります。

1. 作業前に状態を確認する

git status

現在のブランチ、変更されたファイル、まだ追跡されていないファイルなどを確認できます。

2. 必要に応じてGitHubの変更を取り込む

git pull origin main

ほかの環境で変更されている可能性がある場合は、作業前に取得しておきます。

3. 作業用ブランチを作る

git switch -c feature/input-validation

新しい機能や修正を、mainから分離して進めます。

4. ファイルを編集する

プログラム、設定ファイル、文書などを編集し、通常どおり保存します。

5. 変更内容を確認する

git status
git diff

git statusで変更されたファイルを確認し、git diffで具体的な差分を確認します。

6. コミット対象を選ぶ

git add src/validation.py

すべての変更を対象にする場合は、次のように書けます。

git add .

ただし、関係のない変更や秘密情報まで含めないように、git statusで確認してから実行する習慣が大切です。

7. 履歴として記録する

git commit -m "入力値の範囲チェックを追加"

8. GitHubへ送る

初めてリモートへ送るブランチでは、次のように実行します。

git push -u origin feature/input-validation

-uを指定すると、ローカルブランチとリモートブランチの対応関係が設定されます。次回からは、単に次のコマンドで送れる場合があります。

git push

最初に覚えたい関連用語

主要な5用語と一緒に、次の用語も覚えておくと操作の流れを理解しやすくなります。

GitHub上の既存リポジトリから作業を始める場合は、次のようにcloneします。

git clone https://github.com/example/sample-project.git

これにより、現在のファイルだけでなく、それまでのコミット履歴やブランチ情報も取得されます。

初学者が混同しやすいポイント

commitとpushは同じではない

commitはローカルへの記録、pushはリモートへの送信です。

コミットしてもpushしなければ、その履歴はGitHubには反映されません。反対に、コミットしていない変更はpushしても送られません。

repositoryはGitHub上だけにあるものではない

自分のパソコンにもローカルリポジトリがあります。GitはGitHubがなくても利用できます。

branchは単なるバックアップではない

ブランチは変更履歴を分岐させる仕組みです。試作、機能追加、不具合修正などを本流から分離して進めるために使います。

pullすると必ず安全に上書きされるわけではない

同じ箇所をローカルとリモートの両方で変更していると、Gitが自動判断できず、conflictと呼ばれる競合が発生することがあります。その場合は、人が内容を確認して、どの変更を残すか決める必要があります。

GitHubへ秘密情報を送らない

APIキー、パスワード、秘密鍵、個人情報などはコミットしないようにします。一度公開リポジトリへpushすると、後からファイルを削除しても過去の履歴に残る場合があります。

除外したいファイルは、.gitignoreに登録します。

.env
.venv/
__pycache__/

Gitはテキストファイルの管理を得意とする

プログラム、Markdown、JSON、CSVなどのテキストファイルは、変更箇所を比較しやすいためGitと相性が良い形式です。

一方、CADデータ、画像、動画などのバイナリファイルは、差分の確認や統合が難しく、容量も大きくなりやすいという特徴があります。これらを扱う場合は、運用方法やGit LFSなどを別途検討します。

5つの用語を一文で整理する

最後に、この記事の中心となる用語を簡潔にまとめます。

最も基本的な流れは、次の一行に集約できます。

編集 → add → commit → push

リモート側の変更を受け取るときは、pullを使います。そして、安定した本流と作業中の変更を分けたいときに、branchを使います。

最初からすべてのコマンドを暗記する必要はありません。まずは、今の変更が作業フォルダ、ステージング領域、ローカルリポジトリ、GitHubのどこにあるのかを意識することが大切です。この位置関係が分かれば、Gitの操作は単なるコマンドの暗記ではなく、履歴を段階的に管理する作業として理解できるようになります。