いまさら聞けない「GitHub」って？Gitとの違いから基本操作を初心者向けにやさしく解説！

この記事でわかること
・ GitとGitHubの違い
・ バージョン管理がなぜ必要なのか
・GitHubにおけるレポジトリの基本的な使い方

社内や取引先とのやり取りで、ふいに出てくる「GitHubに置いておきますね」という一言。

GitHubは開発現場ではいまや欠くことのできない存在ですが、名前は聞いたことがあっても「どこに？」「何を？」「どうやって置くの？」と分からないまま、画面の前で手が止まってしまった経験がある方も多いのではないでしょうか。

この記事では、GitとGitHubの違いをやさしく整理しながら、実際にGitHubを触っていきます。
コマンド操作に不安がある方でも読み進められるよう、画面操作を中心に解説していますので、手を動かしながら一緒に進めていきましょう。

「なんとなく分かった」から「ちょっと使える」状態を目指して、気軽に読み進めてくださいね。

GitとGitHubの違い

Git（ギット）やGitHub（ギットハブ）、GitHub Desktop（ギット デスクトップ）など、「Git」という名前が付くサービスやツールは複数あります。
この名称の似ている点が、Git周りを分かりにくく感じさせる原因の一つかもしれません。

名前は似ていても、それぞれの役割は明確に分かれています。
ここではGitとGitHubの役割の違いを整理していきましょう。

Gitとは何か

まずはGitについてです。
Gitは、ファイルの変更履歴を管理するための「バージョン管理ツール」です。

バージョン管理とは、ファイルが「いつ・どのように変更されたか」を履歴として残し、必要に応じて過去の状態を確認・復元できるようにする仕組みを指します。

Gitが管理しているのは、主に次のような情報です。

これらの情報をバージョンとして記録することで、以下のような操作が可能になります。

なお、Git自体はバージョン管理を行うための仕組み（ツール）であり、ファイルを共有したり、ブラウザで閲覧したりするための画面機能は持っていません。

GitHubとは何か

一方でGitHubはどうなのでしょう。
GitHubは、Gitで管理しているファイルや履歴を、インターネット上で保管・共有できます。
ブラウザ上で操作できるため、専門的な知識がなくても扱いやすいのが特徴です。

つまりGitHubは、Gitを「実際の業務で使いやすくしてくれる場所」という存在なのです。

GitとGitHubの関係

実務では、Gitで管理した履歴を、GitHubに置いて使います。
ですが、多くの人が「Gitを使っている」というよりも、「GitHubを使っている」感覚で利用しているのではないでしょうか。

それは、日常的な作業の多くがGitHubの画面上で完結するためです。
ファイルの確認や編集、変更履歴の把握、共有といった操作はGitの仕組みを意識しなくても、GitHubを通じて行えます。

「Gitは裏側で動いている仕組み」「GitHubは日常的に操作するためのサービス」と考えておいて大丈夫です。

Git：履歴を管理する「中身・仕組み」
GitHub：それを置いて、見て、共有する「場所・サービス」

バージョン管理と必要性

GitHubを理解するうえで、避けて通れないのが「バージョン管理」という考え方です。
バージョン管理とは、ファイルの変更履歴を「バージョン」として記録・管理する仕組みのことです。

バージョン管理はどのようなときに必要な仕組みなのでしょうか。
その機能と必要性をみていきましょう。

バージョン管理をしないと何が困るか

ひとりで開発作業を行っている場合、「自分しか触らない」「今までも特に困っていない」と、バージョン管理の必要性をあまり意識することがないかもしれません。
しかし、バージョン管理を行っていないことはリスクがあります。
バージョン管理を適切におこなうことで、以下のような様々なリスクを回避できるのです。

間違えてファイルを壊してしまったときに戻れない

作業中にファイル操作などを誤るのはよくあること。
間違って消してしまった、設定を変更したら動かなくなった、どこを直したのかわからなくなったなど、困った経験がある方も多いのではないでしょうか。

このような状況で、もしバージョン管理をしていないと「元に戻したい」と思っても、戻せる状態が残っていない という状態が起こります。
場合によっては復旧に時間がかかってしまったり、はじめから作り直しの作業が発生してしまうかもしれません。

一方バージョン管理をしていれば、変更前の状態に戻す、問題が起きる前のバージョンを確認する、といった対応が簡単にできるのです。

どれが正しいファイルか分からない

開発業務では一つのファイルに細かく変更や修正を加えるため、日々アップデートがされていきます。
また複数人で作業を行っている場合は、ファイルの更新はさらに煩雑かつ複雑になってきます。

そのため「ファイル名_最新版.xxx」「ファイル名_修正版.xxx」といった命名ルールでは、本当の最新なのはどれなのか、どのファイルを更新すればいいのかがわからなくなることも。

バージョン管理を行えば、常に「最新版」は1つだけになり、過去の状態は履歴として管理できます。

担当者が変わったときに引き継げない

ひとり情シスや少人数体制では、担当者の退職・異動・増員が起きたときに、情報が引き継げないリスクが高くなります。

バージョン管理をしていれば、いつ、どんな意図で、何が更新されたのかが履歴として残ります。
担当者が変わっても、状況を把握しやすくなり安心です。

「自分1人だから大丈夫」は長期的に見ると危険

ひとりで作業している間は問題がなくても、業務が増える、人が増える、外部に引き継ぎといったタイミングで、過去の作業がブラックボックス化していることが大きな負担になるケースも。

特に、ひとり情シス・ゼロ情シスの環境では「属人化」が大きなリスクになり得ます。
バージョン管理は、「将来の自分や、次の担当者のための保険」と考えてるとわかりやすいかもしれません。

Gitは「バージョン管理を専門に行うツール」

ここまで見てきたように、Gitはバージョン管理を行うことに特化したツールです。

Gitの役割はあくまでシンプルで、ファイルの変更を記録する・変更履歴をたどれるようにする・必要に応じて過去の状態に戻せるようにする、という「履歴管理」に集中しています。
一方で、Gitそのものにはファイルを一覧で見る画面や、共有や権限管理の仕組みといった機能は用意されていません。

つまりGitは、バージョン管理の中身を担う「基盤のような存在」だと考えるとよいでしょう。

GitHubは「バージョン管理を業務で使いやすくするサービス」

GitHubは、このGitの仕組みを業務の中で扱いやすくするためのサービスです。

GitHubを使うことで、Gitの履歴をクラウド上で管理できる・ブラウザから内容を確認や編集ができる・複数人で安全に共有できる、といったことが可能になります。

Gitが「裏側の仕組み」だとすると、GitHubは人が日常的に触るための表側といえるでしょう。

GitHubが管理しているのは「ファイル」と「変更履歴」

GitHubで管理している対象は、とても明確。

  ファイルそのもの
  そのファイルが、いつ・どのように変更されてきたかという履歴

この2つをセットで管理します。

重要なのは、ファイルを置いたり編集したりするだけで、変更履歴が自動的に残る点です。
特別な操作をしなくても履歴が記録されていくため、あとから振り返ったり、別の人に引き継いだりすることが容易になります。

また、GitHubで管理できるファイルの種類にほとんど制限はありません。
たとえば、次のようなものも問題なく管理できます。

• テキストファイル（README、手順書など）
• Excel・CSV・PDF
• スクリプトや設定ファイル
• 社内向けのメモやドキュメント

「コードを書く人のためのツール」という印象を持たれがちですが、実際には業務ドキュメントや管理用ファイルの置き場所としても十分に活用できるのが大きな特徴です。

【実践】GitHubの使い方（Windows版）

1. 事前準備

上の章でGitHubがGitの仕組みを使っていることをお伝えしました。
GitHubを利用する前に、Gitを利用できる状態にしておく必要があります。

まずはGitのインストールと初期設定をすすめましょう。

※このセクションは少しのコマンド操作が含まれますが、GitHubの設定からはWeb操作中心となります。

1-1. Gitのインストール

Git公式サイト  へアクセスし、「Windowsにインストール」ボタンをクリックします。

Windows版をインストールするため、「ウィンドウズ」タブに表示される「ダウンロードするには、ここをクリックしてください。」というリンクをクリックします。
なんらかの条件指定がある場合は、条件に沿ったリンクからダウンロードを開始します。
またWindows以外のOSの場合、それぞれのタブからダウンロード操作に進んでください。

今回は以下の名称のファイルがダウンロードされていました。（バージョンによってファイル名称も異なります。）
ダウンロードファイルを実行して、インストールを開始します。

セットアップウィザードが開いたら、「Install」をクリックします。

インストール先のフォルダを設定します。
指定がなければデフォルトのまま「Next」で進みましょう。

インストールに関する設定を選択します。
基本的には、そのままの状態で「Next」で進んで問題ありません。

ショートカットの設定についてです。
こちらも、そのまま「Next」で進んで問題ありません。

Git とテキストでやり取りする際に使用するエディタを選択します。

プルダウンを開くと、ずらっと英語のメニューが表示されます。
初心者の方は、扱いやすい「Use visual Studio Code as Git’s default editor」を選択するのがおすすめです。

エディタを選択したら、「Next」で進みます。

次は、新しく Git の管理を始めたときに作られる「最初のブランチ名」を設定します。
ブランチについては後の章で詳しく解説しますが「main」が一般的なため、「Override the default branch name for new repositories」を選択し、「main」としたまま「Next」で進みましょう。

パス（コマンドをどの場所から呼び出すか）の設定です。
そのままで問題ないので「Next」で進みます。

GitHubとSSHで接続をするとき、Gitが使用するSSHアプリを選択する画面です。
日常的に使っているSSHアプリがなければ、Gitに同梱されているOpenSSHを選択しましょう。
選択したら「Next」で進みます。

GitがHTTPSで通信を行う際に使用する、証明書の検証方法を選択します。
Windowsの標準機能を利用する設定のままで問題ありません。

テキストデータの改行コードを設定します。
改行コードはWindows環境では「CRLF」、MacやLinux環境では「LF」です。
Windows環境でそのままで問題ありません。

Git Bash を起動したときに、どのターミナル（画面・ウィンドウ）で表示するかを選択します。
とくに指定がなければ、操作しやすいMinTTYを選択しましょう。

Gitコマンドの実行時についての設定です。
そのままで問題ありませんので、「Next」で進みます。

GitHubに接続する際に使用する認証情報の管理方法を選択します。
そのままで問題ありませんので、「Next」で進みます。

Gitの動作を補助する追加オプションを設定します。
そのままで問題ありませんので、「Install」に進みます。

インストールの完了画面が表示されたら、「Finish」をクリックしてインストールを終了します。
そのまま設定に進む場合は「Launch Git Bash」（Git Bashを起動する）にチェックを入れてください。

1-2. Gitの初期設定

Gitをインストールすると、Gitを操作するためのコマンドラインツール「Git Bash」も自動的に利用できるようになります。
このGit Bashを使ってGitの初期設定を行っていきます。

 Gitのバージョンを確認する

まずはGit Bashに慣れるため、インストール確認をかねてGitのバージョンをコマンドで表示させてみましょう。
Gitの画面上で、以下のコードを入力してみましょう。
「$」の横に直接入力します。

$ git –version

エンターを押すとコマンドが実行され、結果が返ってきます。
このように、Gitのバージョン情報が表示されていれば正常に利用できています。

$ git --version
git version 2.52.0.windows.1

 ユーザー情報の設定

Gitはファイルの変更を記録する際に「誰が作業したのか」を記録します。
そのため、あらかじめ自分の名前とメールアドレスを登録しておく必要があります。
名前とメールアドレスは、ご自身のものに置き換えて設定してくださいね。

$ git config –global user.name “Your Name”
$ git config –global user.email “you@example.com”

GitとGitHubはメールアドレスで紐付けされるため、Gitに登録したユーザー名はGitHubとイコールではありません。
もちろん両方同じものを利用することも可能です。

 設定内容の確認

設定した情報が反映されているか確認します。

$ git config –list

上で設定したユーザー名とメールアドレスが表示されていれば、登録できています。

user.name="Your Name"
user.email="you@example.com

以上でGit（Git Bash）の設定は完了です。
Git Bashはexitと打ってエンターすると、閉じることができます。

2. GitHubを使う

2-1. GitHubアカウントの作成

ここからは、GitHubの登録と利用方法についてご説明します。

GitHub公式サイト  にアクセスし、「GitHubに登録する」または「サインアップ」に進みます。

アカウント作成画面が表示されます。
Googleアカウントとの連携、Appleアカウントとの連携、メールアドレスをパスワードを設定する方法が選択できます。
お好きな方法でアカウント登録を行いましょう。
今回の登録ではGmailを利用します。

進んでいくと、GitHubの「ユーザー名」を入力する画面に遷移します。

このユーザー名は、GitHub上でユーザーを識別するためのIDです。
具体的にはプロフィールページのURLとして使われるのをはじめ、GitHub上のすべての活動に紐づきます。
ユーザー名は本名以外にもハンドルネームや屋号、サービス名などが使用されるケースもあります。
後から変更することもできますが、ユーザー名の変更に伴ってプロフィールページのURLも変わってしまうため、公開されることを前提にユーザー名を決めましょう。

プロフィールページ自体は公開されますが、ファイルやコードの変更履歴を管理するリポジトリは「非公開（Private）」に設定することもできます。
社内資料や個人用のファイルを外部に見せずに管理することが可能です。
また業務利用を想定する場合は、個人用のメールアドレスではなく、業務用アドレスを使うことをおすすめします。

リポジトリの作成

まずはレポジトリを作成してみましょう。

GitHubを使い始めると、最初に出てくるのが「レポジトリ」という言葉です。
レポジトリとは、ファイルやフォルダをまとめて管理するための保管場所のことです。
GitHubでは、このレポジトリを単位として、ファイルの追加や編集、変更履歴の管理を行います。

イメージとしては、次のように考えると分かりやすいでしょう。

ひとつのレポジトリ ＝ ひとつの作業スペース
プロジェクトごとにレポジトリを分けて管理する

レポジトリの大きな特徴は、単なるファイル置き場ではないという点です。
上の章でも説明しているように、変更の履歴が自動的に記録されます。

日本語訳が少しわかりにくいため、ここからは英語表記のまま手順をお伝えします。
GitHubのトップ画面から、左上のメニューを選択します。

「Repositories」を選択します。

「New Repositories」をクリックしてレポジトリの作成画面に進みます。

新規レポジトリの作成をしていきます。

Owner：GitHubアカウント作成時にユーザー名が表示されます。
Repository name：レポジトリの名前を英数で入力します。この名前はレポジトリのURLの一部として使われます。
Description：このレポジトリが何のためのものかを書く欄です。入力は任意です。
Choose visibility：レポジトリの公開設定を行います。公開する場合は「Public」非公開にする場合は「Private」を選択します。後からの設定変更も可能。
Add README：レポジトリを開いたとき、最初に表示される文章として使われます。「ON」の設定がおすすめ。
Add .gitignore：一時的なファイルや設定ファイルなど、レポジトリに含めたくないものを除外するための設定です。
Add license：レポジトリを公開した時に、他の人がその内容をどのように使ってよいかを明示するための設定です。

この画面で必須項目なのは「Owner」「Repository name」「Choose visibility」のみです。

READMEについては以降の章で詳しく触れていきます。
読み進めながら設定をしてみたい場合は「Add README」はONにしておいてくださいね。
「Add .gitignore」と「Add license」は、初めは設定しなくても問題ありません。

「Create Repository」をクリックして設定を保存します。
画面が切り替わり、「test」と名付けたレポジトリが作成されました。

ファイルをアップロードする

作成したレポジトリにファイルをアップロードしてみましょう。
あらかじめデスクトップ上に作成しておいた、「Test.txt」というファイルをレポジトリにあげてみます。

画面中央の「Add file」から「Upload files」を選択します。

アップロード画面に切り替わったら、中央にあるエリアにファイルをドロップします。

ドロップしたファイルが、ドロップエリア下部分に（「test.txt」と出ている箇所）に表示されていることを確認したら、「Commit changes」の部分に説明を入力します。
上のコメント欄に操作の説明、下のコメント欄に詳細を記載します。
どちらも必須ではありませんが、書いておくことによって後から見返すことができるので便利です。

入力が完了したら「Commit changes」で確定します。

先程までは「README」しかなかったレポジトリに、「Test.txt」が表示されました。

READMEの編集

次に、READMEをみてみましょう。
画面下部分の「README」エリアに、現在READMEに記載されている内容が表示されます。
ここに、Markdown（マークダウン）を使って簡単なコメントを追加してみましょう。

READMEを編集する方法は2つ。

1.「README.md」ファイルをクリックし、リンクから編集画面に移動する方法
2. READMEエリアに表示されている編集ボタン（ペンマーク）を選択し、編集画面に移動する方法

READMEの内容を一度確認してから編集したい場合は 1、すぐに編集に進みたい場合は 2 を選ぶとよいでしょう。

Markdown（マークダウン）とは？
Markdownは、見出しや文章構造をシンプルな記号で書ける記法です。

READMEの編集画面に移動したら、テキストエリアに現在のREADMEの内容が表示されます。
Markdownを使って、READMEを簡単に編集していきましょう。

まずは見出しを作成してみます。
Markdownでは、行の先頭に # を付けることで見出しを作れます。
# の数が増やすことで小見出しも作成できます。

上の内容をプレビューに切り替えてみると、以下のような表示になります。

内容が問題なければ「Commit changes…」　ボタンをクリックします。
確認画面が表示されるので、「Commit changes」で確定します。

Markdownで追記した内容が反映されました。

変更履歴を確認する

ここまでで、ファイルのアップロードやREADMEの編集を行いました。
GitHubでは、こうした操作すべて「変更履歴」として記録されています。
次は、その履歴を実際に確認してみましょう。

ダッシュボードから、左のサイドバーを確認します。
変更履歴を確認したいレポジトリを選択します。

画面中央に表示される「Commits」をクリックします。

変更履歴が表示されました。
この変更履歴の画面では、主に次のような情報が確認できます。

・どんな変更をしたか（コミットメッセージ）
・いつ変更したか
・誰が変更したか

自分が行った操作が時系列で並んでいるのが確認できるはずです。

この「時系列で履歴を確認できる」というのが、まさにGitHubの大きな特徴です。
チームで作業をする場合も、「いつ」「誰が」「何をしたのか」すぐにわかるので、状況を共有しやすいのです。
こうした点がGitHubが多くの開発現場で活用されている理由のひとつです。

気になる料金とセキュリティ

新しいツールを業務で使うときに、多くの人が気になるのが 「料金」と「社内利用の安全性」 でしょう。
GitHubを利用するうえで知っておきたい、料金体系と社内利用時の考え方を整理します。

無料で利用できる範囲

GitHubは無料プラン・有料プランがあります。
無料プランでも、以下のようにかなりの範囲を利用できます。

無料プランで利用できること

  非公開（Private）リポジトリの作成
  ファイルの管理・変更履歴の保存
  複数人での共有・共同作業
  Webブラウザからの編集・確認

この記事で紹介しているような基本的な使い方や、社内資料や設定ファイルの管理、小規模チームでの利用であれば、無料プランで充分に対応できるでしょう。
まずは無料で試しながら、業務に合った活用方法を見つけていくのがおすすめです。

社内利用について

GitHubは、社内利用を前提として使われているケースも多いサービスです。
むしろ、リポジトリごとの「公開・非公開」設定を正しく行えば、情報の取り扱いをコントロールしやすく社内活用に向いているといえるでしょう。

あらかじめアクセスできる人を限定できるため、業務に関わる資料や設定情報を必要な範囲で安全に共有することが可能です。
情報が不用意に外部へ公開されることを防ぎつつ、社内での運用や引き継ぎもスムーズに行えるようになります。

社内利用を目的とする場合は、非公開（Private）リポジトリを使うのが基本と考えておくとよいでしょう。

まとめ

ここまで、GitHubの基本的な役割と操作の流れを一通り体験してきました。

GitHubは、開発者だけが使う特別なツールではありません。
ファイルと変更履歴をセットで管理できる「バージョン管理の仕組み」を、業務の中で使いやすい形にしたサービスです。

業務の中での情報管理や引き継ぎに不安を感じている方ほど、GitHubの仕組みはきっと役立つはずです。
ぜひ、ご自身や自社の業務に合った形で、少しずつ取り入れてみてくださいね。