　第1回ではGitHubの全体像を、前回は人事や法務が社内規程の管理に使っている実例を紹介しました。第1回の最後に「次は実際に画面を開く」と予告していたので、少しお待たせしてしまいました。

今回は、いよいよ自分の手で触ってみます。ただし、コードは書きません。使うのはブラウザだけです。業務メモを1つ保存して、書き直して、その履歴を見る。やることはこれで全部です。

始める前の準備

GitHubのアカウントが必要です。アカウントは無料で作れます。登録の手順は公式の案内¹にまとまっているので、そちらを見ながら進めてください。登録したあと、2段階認証（パスワードに加えて、スマートフォンなどで本人確認をする仕組み）の設定を求められることがあります²。

もう一つ、先にお伝えしておきたいことがあります。GitHubの画面は英語です。とはいえ、今回押すボタンは5つほど。ボタン名は英語のまま書いて、横に意味を添えていきます。

リポジトリを作る

最初に、文章を入れておく場所を作ります。これがリポジトリです。第1回でも触れたとおり、「ファイルと変更履歴を置いておく箱」くらいに考えておけば十分です。

リポジトリの一覧画面にある、緑の「New repository（新しいリポジトリ）」ボタンを押します。画面右上の「＋」からも、同じ作成画面に進めます。

画像① リポジトリ一覧の右上にある、緑の「New repository」ボタン

作成画面で決めることは3つです。ほかの項目は、そのままで大丈夫です。

Repository name（リポジトリ名）は、work-notes のように半角の英数字とハイフンで付けておくと無難です。公開範囲は、Choose visibility（公開範囲を選ぶ）の欄で、Public（公開）かPrivate（非公開）を選びます。Publicはインターネット上の誰でも見られる設定なので、練習ではPrivateにしましょう。無料のプランでも、非公開のリポジトリは作れます³。

最後に、Add README（READMEを追加）のスイッチをOnにします。READMEは、リポジトリの説明書きになるファイルです。設定できたら、「Create repository（リポジトリを作成）」を押します。

画像② 名前を work-notes にし、Private を選び、Add README を On にした作成画面

これで箱ができました。

READMEに業務メモを書く

できたばかりのリポジトリには、READMEというファイルが1つだけ入っています。開いてみると、1行目にリポジトリの名前が書かれているはずです。

ファイルの右上にある鉛筆のマーク（Edit file＝ファイルを編集）を押すと、編集画面に切り替わります⁴。中身を、次のように書き換えてください。

# 業務メモ

このリポジトリでは、業務手順を管理します。

画像③ Edit タブで、READMEを「# 業務メモ」に書き換えたところ

1行目の # は、Markdownという書き方で「ここは見出し」という意味の記号です。今回覚えるMarkdownは、これだけで大丈夫。

編集画面の上には、Edit（編集）とPreview（プレビュー）の2つのタブがあります。Previewを押すと、仕上がりを確かめられます。# が消えて、「業務メモ」が大きな見出しになっているはずです。記号が見える画面と、記号が効いた見た目の画面。この2つを行き来できるようにしておくと、あとで戸惑わずに済みます。Previewの画面にある「Show diff（差分を表示）」にチェックを入れると、記録する前に、どこを変えたのかも確かめられます。

画像④ Preview タブに切り替えると、「#」が消えて見出しになる

Commitで記録して、もう一度直す

書き終えたら、「Commit changes...（変更を記録する）」を押します。Commit（コミット）は、「この時点の変更を記録する」操作です。上書き保存と似ていますが、前の状態が消えずに残るところが違います。

小さな画面が開き、2つのことを聞かれます⁴。

一つは、Commit message（コミットメッセージ）の欄です。何を変えたのかを短く書きます。Copilot（GitHubのAI機能）が文案を入れてくれる場合もありますが、内容が合っているかは自分で確かめてください。今回は「READMEを作成」とします。変えた理由まで残したいときは、その下のExtended description（詳しい説明）に書き足せます。

もう一つは、記録する場所の選択です。選択肢は2つあります。

Commit directly to the main branch（main＝リポジトリの本体に、そのまま記録する）
Create a new branch for this commit and start a pull request（新しいブランチを作って、プルリクエストを始める）

今回は1つ目を選んでください。2つ目は、次回使います。

画像⑤ コミットメッセージを確かめ、記録先は1つ目の「main に直接」を選ぶ

最後にもう一度「Commit changes」を押せば、記録は完了です。

続けて、もう一度直してみます。同じ手順で編集画面を開き、

このリポジトリでは、業務手順を管理します。

を

このリポジトリでは、業務手順と変更履歴を管理します。

に変えます。コミットメッセージは「READMEの説明を更新」として、mainに記録してください。

変更履歴を見る

ここからが、今回の本題です。

READMEのファイルを開き、「History（履歴）」を押すと、このファイルの記録の一覧が出てきます。リポジトリを作ったときの最初の記録（Initial commit）と、今回の2回分。合わせて3つ並んでいるはずです。

画像⑥ README.md の履歴。最初の記録と今回の2回分、合わせて3件が並ぶ

一覧からは、次のことが分かります。

いつ変えたか（日時）
誰が変えたか（アカウント名）
何のための変更か（コミットメッセージ）

いちばん新しい「READMEの説明を更新」を開いてみてください。前の文が赤、新しい文が緑で並んでいます。行の頭には、消えた行に「-」、加わった行に「+」の印も付きます。何を変えたのか、前は何だったのか。この画面一つで確かめられます。

画像⑦ 変更前の文（赤、-）と変更後の文（緑、+）が並ぶ比較画面

第1回で、「完成版」「修正版」「最終版」のファイルが並び、どれを使えばよいか分からなくなる場面を描きました。この仕組みがあれば、ファイルは1つのままで構いません。「最終版2」や「最終版_本当の最終版」を作らなくても、前の状態は履歴にちゃんと残っています。

ただし、なぜ変えたのかまでは自動では残りません。残るのは、コミットメッセージや詳しい説明の欄に書いた分だけです。理由を書き残すのは、人の仕事なんですね。

つまずきやすいところ

手を動かしていると、引っかかりやすい点がいくつかあります。

# のあとには、半角スペースを1つ入れてください。「#業務メモ」のようにくっつけると、見出しにならず、記号がそのまま表示されます。Previewで見出しにならないときは、まずここを確かめてみてください。

もう一つは、Commitを押す前に画面を閉じてしまうことです。編集画面で書き換えただけでは、まだ記録されていません。隣にある「Cancel changes」を押すと、書き換えた内容は取り消されます。「Commit changes」を最後まで押して、初めて履歴に残ります。

READMEを追加する設定を入れ忘れた場合は、リポジトリの中身が空のまま作られます。慌てずに、練習用のリポジトリをもう一つ作り直せば大丈夫です。

まとめと次回予告

今回分かったことは3つだけです。

コードを書かなくても、GitHubは使える
普通の文章を保存できる
修正の履歴が残る

次回は、直接書き換えるのではなく、「この文章をこう変えてもよいですか」と修正案として出す方法を試します。プルリクエストと呼ばれる仕組みです。今回、記録先を選ぶときに出てきた2つ目の選択肢が、そこで出番を迎えます。