実践!GitHub Pagesを使って自分のWebサイトを公開してみよう!

ブログアイキャッチ画像

作業環境と前提条件
  • 基本的なWebページ」について:今回公開していくWebページの構成は、主にHTMLとCSS、そして画像と少しのJavaScriptから成り立っているものです。なお使用しているテンプレートは、「Start Bootstrap」というサイトが無料で提供してくださっている、こちらのオープンソーステンプレートを使用させていただきましたので、データのイメージなどを掴みたい方はご参考になさってみてください。
  • 使用しているPC:作業で使用しているPCはMacBook Airです。Windowsでは細部の表示などが異なる場合があるかと思われますが、基本的な部分はWindowsでも同様に進めることができるかと思います。
  • 使用していくサービスと知識:今回は手元のローカル環境で編集を加えたHTMLやCSSなどのWebページを、「Git」と「GitHub」を使用し「GitHub Pages」で公開していく流れとなります。「ターミナル」での操作なども生じてきますので、分からない方はぜひ以下のページや書籍などでの事前の学習をオススメします。

 Webページをインターネット上に公開するには色々な方法がありますが、そのなかでも今回「GitHub Pages」を利用するメリットは主に以下の3つです。

「GitHub Pages」を利用する3つのメリット
  1. 無料のホスティングサービスであること:「GitHub Pages」は「GitHub」のアカウントさえ持っていれば、追加料金などをかけることなく利用することができます。また「GitHub」のアカウント自体も無料で作成することができますので、今回ご紹介する方法では費用をかけることなくWebページをインターネット上に公開することが可能です。
  2. 比較的簡単にセットアップができること:「GitHub Pages」サービスでは、「GitHub」のリポジトリにファイルをアップロードするだけでウェブサイトを公開することができます。ホスティングに関する特別な知識などはとくに必要がないことから、比較的簡単にセットアップをすることができます。
  3. GitHubとの連携していること:「GitHub」が提供しているサービスのため当たり前ではありますが、「GitHub」と連携していることも大きなメリットです。公開するウェブサイトの内容を「GitHub」で管理することができるため、更新や変更も容易です。

上記の他にも、安全性の高さや読み込みの速さなどにもメリットを感じる方が多いようです。

Webページ公開までの流れ

 では今回本記事で取り扱う「Webページ公開までの流れ」を事前に掴んでおきましょう。

Webページ公開までの流れ
  1. GitHubアカウントとリポジトリの作成
  2. GitHubへのSSHキーの設定
  3. Webページを作成するための事前準備
  4. GitHub Flowについて学ぶ
  5. GitHub Flowの実践
  6. GitHub PagesからWebページを公開

GitHub Flow」を実践しながらWebページの公開まで行っていくため、実際の開発フローのイメージを掴みたい方にも役立つ内容になっているかと思います。

GitHub」の操作に慣れていない方も、この機会にぜひ一緒にチャレンジしてみてください!

GitHubのアカウントとリポジトリを作成しよう

GitHubアカウントの新規作成

 ではまずは「GitHub」のアカウントから作成していきましょう。すでにアカウントをお持ちの方はこの項目は飛ばして「リポジトリの新規作成」に進むことをオススメします。

1.

まずは「GitHub」のトップページにアクセスし、赤枠で示した「サインアップ」もしくは「GitHubに登録する」の文字をクリックしてください。

GitHubのトップページ
2.

続いて登録情報を入力していきます。画面上では英語表記ですが、内容は以下のとおりです。

No.入力 / 選択項目説明
Username(必須)GitHubに登録するユーザ名
Email address(必須)GitHubに登録するEメールアドレス
Password(必須)GitHubで設定するパスワード
(15 文字以上、または数字と小文字を含む8 文字以上であること)
Email preferences製品の最新情報やお知らせなどが欲しい場合はチェックボックスに選択
Verify your accountロボットかどうかの確認(表示されている内容に従ってください)
Create account上記5項目を入力した後には【Create account】ボタンが緑色に変化しているはずですので、ボタンをクリックしアカウントを作成します。
登録情報一覧
3.

すると登録したEメールアドレス宛に認証用のパスコードが送られてくると同時に、下画像のような数字入力画面に移りますので、アドレスに送られてきたパスコードを画面に入力してください。

パスコード入力画面
4.

パスコードの入力後、以下の画像のようなダッシュボード画面に移動ができたら、ユーザーの新規登録は完了です。

あなたのアカウントが作成されました!

GitHubのダッシュボード画面

リポジトリの新規作成

 続いて、新規リポジトリの作成に移ります。

 「リポジトリ」とは主にGitHub上で使用される用語で、GitHub上で管理する「プロジェクト」に関わるデータや情報を保存するための場所のことを指しています。

 GitHubに馴染みのない方には少し分かりにくい概念ではあるのですが、GitHubユーザー同士であれば協力して管理や開発を行うことができる、フォルダのようなものだとイメージしてください。

 では、早速新規のリポジトリを作成していきましょう。

1.

下の画像の赤枠で囲った場所のどちらか――「Create repository(リポジトリを作成)」か「New repository(新規リポジトリ)」をクリックします。

リポジトリ作成画面
2.

続いて、作成する「リポジトリ」に関する情報を入力していきます。

入力内容

Repository name(リポジトリ名|必須)

② Description(リポジトリの内容についてなどを記述ができます|必須ではありません)

Public or Private(今回はWebページとしてインターネット上に公開したいため、どなたでもページにアクセスができる「Public」設定を選択します|どちらかの選択必須)

④上記項目を入力したら、「Create Repository」ボタンをクリックし、リポジトリを新規作成します。

今回はリポジトリの名前を「resume1」とし、新規作成していきます。

なおこの時点で、本リポジトリについて記述するページ「README.md」ファイルも一緒に作成したい場合は、「Add a README file」にチェックを。

またGitで無視をしたいファイルなどがある場合は、「.gitignore 」で指定することも可能です(無視をしたいファイルというのは、たとえばフレームワークなどが自動生成するログファイルなどのことです)。

ですが、「.gitignore 」の指定をしなくてもリポジトリは作成することができます。

3.

以下の画像のような画面が表示されれば、無事に新規のリポジトリが作成されたことになります。

(なお「README.md」ファイルをリポジトリと一緒に作成した方は、本画像とは異なる画面が表示されている可能性がありますが、エラーなどが起きていなければ、リポジトリは無事に作成されているはずです)

今回はこの「resume1」リポジトリに、公開したいHTMLやCSS等のファイルや画像をアップロードしていくことで、Webページをインターネットに公開していくという流れで進めていきます。

GitHubにSSHキー(公開鍵)を設定しよう

GitHubとの認証方法について

 ここから先は、GitHubなどのリモートリポジトリへアクセスするためにサーバーへ接続する機会も増えてきます。

 その際に「認証」という手続き、つまり「画面の向こうで操作をしている人が、たしかにユーザー本人であることを証明する手続き」が必要となってくるのですが、現在GitHubで使用できる認証の方式には主に以下の3つの方法があります。

GitHubとの3つの認証方法について(2023.11現在)
  1. 2 要素認証を使用したユーザー名とパスワード、またはパスキーを用いる方法:1つ目は、従来の「ユーザー名」と「パスワード」に加え、2要素認証(2FA)を利用する方式です。2FAは、セキュリティの安全性を高めるために、「ユーザー名」と「パスワード」だけでなく、追加の認証手段(例えば、モバイルアプリやSMSを通じて生成される一時的なパスコード)を要求する方法です。
  2. Personal Access Token (PAT): これは、たとえばGitコマンドラインを通じてGitHubリポジトリにアクセスする際などに使用される、トークンによる認証方式です。「トークン」とは、ユーザーの身元やアクセス権を認証するために使用されるデジタルコードのことを指しています。こうしたユーザーの身元やアクセスする権限を認証することができるトークンを、ユーザーは自身のGitHubのアカウントから生成することで、そのトークンの持ち主を本人だと認証することができる仕組みです。
  3. SSHキー: SSHキーとは「公開鍵」と「秘密鍵」のペアを事前に生成し、「公開鍵」をGitHubに登録することで、「秘密鍵」を持つユーザーのみがリポジトリへアクセスできるという方式です。SSHキーを利用することで、ユーザーはより安全にGitHubなどのリモートリポジトリへのアクセスを確立できるとされています。

 本記事ではこの3種類の認証方式のなかから、SSHキーによるサーバー認証方式を採用して説明をしていきます。

 SSHキーを使用するには事前に設定が必要なのですが、一度設定をしてしまえば、以降は「毎回コマンドライン上でユーザー名とパスワードを入力する」という手間を省くことができるようになり、作業の効率化を図ることができます。

SSHキーの生成

1.

では、SSHキーを設定するために、コマンドライン上に次のように入力・実行をしてください。

$ ssh-keygen -t rsa -b 4096 -C '(GitGubで登録をしたメールアドレス)'

'(GitGubで登録をしたメールアドレス)'の部分には、ご自身がGitHubに登録をしたメールアドレスの入力が必要です。

また繰り返しになりますが、今回はメールアドレスをシングルクォーテーションで囲んでいますが、ダブルクォーテーションで囲んでもかまいません。

2.

すると、左画像のような結果が表示されました。

表示を簡単に説明してみると、大体以下のような内容です。

  • Generating public/private rsa key pair.: これはRSA暗号方式を用いた「公開鍵」と「秘密鍵」のペアを生成していることを示しています。
  • Enter file in which to save the key (/Users/zomy/.ssh/id_rsa): この文章では、生成された「秘密鍵」を保存するファイルの場所を指定するよう求めています。デフォルトの保存場所は /Users/zomy/.ssh/id_rsa ですが、異なるファイル名やパスを指定することもできます。デフォルトのままでよければEnterキーを押します。

秘密鍵」を保存するファイルの場所は今回デフォルトのままで特に不都合はないため、このままEnterキーを押して先に進めます。

3.

続いてEnter passphrase (empty for no passphrase)、パスフレーズ(つまりパスワード)の設定を求められますので入力をし、Enterキーを押します。

ここではGitHubなどで設定したパスフレーズ(パスワード)とは別の、SSHキー専用のパスフレーズ(パスワード)を設定するようにしてください。

するとEnter same passphrase again: と、確認用に同じパスフレーズ(パスワード)の入力を求められますので、1度目に入力したパスフレーズを再度入力し、今一度Enterキーを押しましょう。

4.

下の画像のような結果が表示されたら、SSHキーペア(「公開鍵」と「秘密鍵」)が正常に生成されたということを示しています。

  • Your identification has been saved inの後ろに続く部分には「秘密鍵」の保存先
  • Your public key has been saved inの後ろに続く部分には「公開鍵

――がそれぞれ表示されています。

なお、今回の設定には特に関係ないのですが念のため③④について軽く触れておくと、③は「キーのフィンガープリント」 、つまり生成されたキーの一意な識別子(= フィンガープリント)が表示されており、④には「キーのランダムアートイメージ」、つまりSSHキーをビジュアル的に表現したものが表示されています。

SSHキー(公開鍵)をGitHubに登録する

 では生成した「公開鍵」をコピーして、GutHubに登録していきましょう。

1.

先ほど生成した「公開鍵」を、Macの方は次のコマンドでクリップボードすることができます。

$ pbcopy␣<␣(「公開鍵の保存先のパス)

実際の文字列を入力すると以下のとおりです。

$ pbcopy␣<␣/Users/zomy/.ssh/id_rsa.pub

(なお上記コマンドは、Mac OSシステムでのみ使用されるものですのでご注意ください)

2.

続いて、GitHubの設定画面を開いていきます。

まずは画面右上のアイコンをクリックします。

3.

するとメニューが開きますので、その中から「Settings」を選択し開いていきます。

4.

続いて左側のメニューから「SSH and GPG Keys」を選択しクリックします。

5.

その後右上の緑ボタン「New SSH Key」をクリックし、SSHキーの新規作成画面に移ります。

6.

すると「Add new SSH Key」の画面へ移動しますので、入力作業を進めていきます。

①には今回作成するSSHキーの「Title」を入力し、②では「Authentication Key」を選択、③には先ほどクリップボードにコピーをしたSSHキーを貼り付けます。

①〜③の入力が間違いなく完了したら、④「Add SSH Key」をクリックし、「公開鍵public key)」をGitHubに登録しましょう。

7.

最後に、アカウントのパスワード入力を求められますので、①にご自身のGitHubアカウントのパスワードを入力し、その後②をクリックすると手続きは完了です。

以上でGitHubに「公開鍵」を登録することができました。

8.

再度「SSH and GPG Keys」画面で確認をすると、「公開鍵」であるSSHキーが、ご自身で設定したタイトルで登録されていることが確認できます。

もし誤って作成してしまった場合は、右に位置する「Delete」ボタンをクリックすると、SSHキーを削除することもできます。

SSHキー(公開鍵)が正しく設定できたかの確認

ではSSHキー認証が正しく設定されているかを、GitHubの設定画面だけでなくターミナル上でも確認をしてみることにしましょう。

1.

以下のコマンドをターミナル上に入力・実行をします。

$ ssh -T git@github.com
2.

コマンドを実行後、画面上にYou've successfully authenticatedのメッセージが表示されれば、無事にSSHキーが設定されたことを示しています。

Webページを作成するための事前準備をしよう

GitHubのリポジトリをローカル環境にクローンする

 ここからは、こちらでGitHub上に作成した「resume1」リポジトリをローカル環境にクローンしていきます。

 GitHub上にあるリモートリポジトリ(この場合は「resume1」リポジトリのこと)をローカル環境にクローンする、というのは、より簡単に言い換えると、インターネット上のGitHubにあるプロジェクトである「resume1」リポジトリのコピーを自分の手元のPCにダウンロードする、ということです。

 これにより、インターネットに接続していない時でもそのプロジェクトのファイルにアクセスし、編集を行うことができます。

 では「resume1」リポジトリをクローンしていくために、まずは「ターミナル」を開きましょう。

1.

まずはターミナルを開きます。

この記事をご覧になっている方の環境にもよると思いますが、基本的にターミナルを開いた直後は「ホーム(~)」ディレクトリに現在地が位置していると思います。

ですが、そうでない方の場合にも備えて、一旦「ホーム(~)」ディレクトリに移動するコマンドを打ち、そこから「デスクトップ」ディレクトリへ移動します。

2.

では実際にターミナル上で作業を行っていきましょう。

$ cd␣~/Desktop

上記のコマンドを打つことで「ホーム(~)」ディレクトリから「デスクトップ」ディレクトリへ移動することができます。

Enterキーを打ったあとのコマンドプロンプト(赤線の部分)からも、現在地が「デスクトップ」ディレクトリへ移動したことが見て取れますね。

(補足:移動先のディレクトリはお好みの場所にしていただいて結構ですが、こちらでは「Desktop」ディレクトリに移動した前提で話を進めていきます)

3.

続いてGitHubで①「resume1」リポジトリのページを選択していることを確認後、②「code」タブが選択されていることを確認。③「SSH」項目が選択されていることをチェックし、④「リポジトリのURL」をコピーします。

4.

その後ターミナルに移り、git cloneコマンドのあとに、先ほどコピーした「リポジトリのURL」を貼り付けます。

実際に「リポジトリのURL」を貼り付けした場合は以下の通りになります。

$ git␣clone␣(各自選択をしコピーしたリポジトリURL)
$ git␣clone␣git@github.com:mimimi-zomy/resume1.git

その後はEnterキーで実行をします。

5.

すると、画面上には「warning:」という形で注意書きが表示されました。

表示された内容は以下のとおりです。

warning: You appear to have cloned an empty repository.(あなたがクローンしたのは、何のコミットなどもされていない空のリポジトリです)

ですが、今回は空のリポジトリをクローンしているため、特に問題はありません。

6.

念のためFinderで「デスクトップ」フォルダの中身を確認してみると、確かに「デスクトップ」フォルダ内に「resume1」リポジトリ(≒フォルダ)がクローンされていることが確認できます。

7.

では以下のコマンドで、クローンしたリポジトリへ移動をしましょう。

$ cd␣resume1/

(最後の/(スラッシュ)はあってもなくても移動できます)

Enterキーで実行すると、コマンドプロンプトの表示からも分かる通り、「resume1」リポジトリに移動できたことが確認できます。

今後はこの「resume1」リポジトリで作業を進めていきます。

ローカルリポジトリの作成

1.

では作業中のディレクトリである「resume1」をGitリポジトリにするために、下記のコマンドを入力・実行していきます。

$ git␣init

git initコマンドの「init」は英語の「initialize(初期化)」の略で、言葉のとおりディレクトリの初期化と、これからこのディレクトリをGitで管理をするという宣言を行うことができます。

Initialized empty Git repository」は「初期化が成功し、空のGitリポジトリが作成された」ことを示している一文です。

これでgit initコマンドの実行が成功し、「resume1」ディレクトリがGitの管理下に置かれたことがわかりました。

2.

ではgit init実行後にカレントディレクトリ(現在の作業ディレクトリ)の内容を、lsコマンドに-aオプションをつけて確認してみることにしましょう。

lsコマンドではディレクトリ内のファイルやディレクトリの一覧を表示することができますが、くわえて-aオプションをつけることで、通常時は不可視となっている隠しファイルもすべて表示することができます。

なお-aオプションの-aはallの頭文字です。

$ ls␣-a

コマンドを実行すると「.git」ディレクトリの存在が確認できました。

Gitでは、この「.git」ディレクトリの中にファイルの履歴やバックアップなどを保管していくことで、バージョン管理を行っています。

つまり、この「.git」ディレクトリ、つまりローカルリポジトリの存在が確認できるということは、「resume1」ディレクトリがGitで管理できるようになったという証でもあるのです。

またMacの場合はcommand+shift+.を同時に押すと、Finder上でも不可視フォルダを半透明状態で表示させることができます。

ソースコードの準備

 続いて、公開するWebページのソースコードを準備します。

 今回は、「はじめに」でもお伝えした通り、こちらの無料テンプレートを使用しWebを作成していきます。

 ですが、ダウンロードしたばかりのテンプレートデータにすぐに手を加えてしまうのではなく、まずはデータのバックアップを取るためにも、まずは「ダウンロード」したばかりの手つかずのテンプレートデータをGitHubにアップロードていきます。

 その後に文章や画像などを別途独自のものに差し替えるなどしてソースコードを作成しアップロードし、最終的にはご自身のレジュメを作成する、という流れで進めていきます。

1.

赤枠で記述されている「free download」ボタンをクリックし、テンプレートをダウンロードしてください。

2.

するとzip形式の「startbootstrap-resume-gh-pages」というテンプレートファイルのダウンロードが始まり、その後に同名ファイルの解凍が開始すると思います。

ファイルの解凍が終わりましたら、「startbootstrap-resume-gh-pages」フォルダ内の中身一式を、「デスクトップ」フォルダにある、先ほどクローンした「resume1」フォルダ内にドラッグ&ドロップで移動させます。

3.

resume1」フォルダ内を確認すると、不可視フォルダである「.git」フォルダと、先ほどダウンロードしたばかりの「startbootstrap-resume-gh-pages」フォルダから抜き出した中身一式の存在が確認できます。

4-1.

ではgit statusコマンドで現在の状況を確認してみましょう。

$ git␣status
4-2.

git statusコマンドの実行後に表示されたメッセージについては以下のとおりです。

  • On branch main:現在のブランチがmainブランチであることを示しています。
  • No commits yet:まだコミットが行われていないことを意味します。リポジトリにはコミットが存在せず、新しい変更がコミットされていない状態です。
  • Untracked files:ステージングエリアに含まれていないファイル(index.html)が存在しています。つまり、このファイルの変更はコミットされておらず、Gitの追跡対象になっていません。
  • nothing added to commit but untracked files present (use "git add" to track): コミット対象の変更がなく、かつ追跡対象でないファイルが存在するため、新しいコミットが行われていないというメッセージです。

赤枠で囲われたファイルは先ほどフォルダに追加されたばかりのため、まだステージングもコミットもされていないことが確認できました。

5.

ではまず各種ファイルをステージングエリアにステージングしていきましょう。

ステージングにはgit addコマンドを使用します。

$ git␣add␣.

なおこのコマンドは、実行された現在のディレクトリ(. は現在のディレクトリを指す)の中にある全ての変更(新しいファイル、変更されたファイル、削除されたファイルなど)をGitのステージングエリア(インデックス)に追加するコマンドです。

6.

では再度git statusコマンドを実行し、現状を再確認してみましょう。

$ git␣status

すると上の画像のとおりメッセージが表示されました。

表示されているメッセージからは、画像やWebに関連するデータ(HTMLやCSSデータ)が無事ステージングされたことを示しています。

7-1.

続いてコミットを行っていきます。

今回はgit commitコマンドと併せて-mオプションを使用し、コマンドライン上に直接コミットメッセージを1行入力し、コミットしていきます。

$ git␣commit␣-m␣'任意のコミットメッセージ'

そのため、今回は次のように入力します。

$ git␣commit␣-m␣'first commit'

なお、今回はコミットメッセージをシングルクォーテーションで囲んでいますが、コミットメッセージをダブルクォーテーションで囲んでもかまいません。

コミットをEnterキーで実行したあとの画面を確認してみると、コミットが無事に完了し、結果がコマンドラインに表示されています。

7-2.

コミット実行後に表示されたメッセージについては以下のとおりです。

  • [master (root-commit) 9e5cd6b] first commit:これは、新しいコミットがmainブランチに追加されたことを示しています。9e5cd6bはコミットの識別子(ハッシュ値)であり、first commitは先ほど入力した1行のコミットメッセージです。
  • 5 files changed, 11231 insertions(+): この行は、今回のコミットが行われたファイルが5つで、そのファイルの変更内容は11,231行の追加( 11231 insertions)であることを示しています。

要するに、git commitコマンドを使用して新しいコミットを作成したことと、そのコミットに5つのファイルの変更(11,231行の追加)であることが画面上に示されているということです。

そしてコマンドの最後の行がコマンドプロンプトに戻るため、新しいコミットが正常に作成されていることが読み取れます。

8-1.

ではコミットが成功した状態で、またgit statusコマンドを実行し、現状を確認してみましょう。

$ git␣status

すると、上の画像のような結果がコマンドラインに表示されました。

8-2.

表示された内容を簡単に説明しますと…

  • On branch main: 現在のブランチがmainブランチであること
  • nothing to commit: コミットする変更がないこと
  • working tree clean: ワーキングツリー(作業ディレクトリ)はクリーンで変更がなく、ローカルリポジトリとワーキングツリーの状態が一致していること

上記3点の内容を読み取ることができました。

編集が加えられていたすべてのファイルのコミットが成功したことにより、ワーキングツリーが現在はクリーンな状態であることが改めて確認できました。

 ダウンロードしたばかりのソースコードに手を加えるのは、次の「first commitをリモートリポジトリへプッシュする」が終了してからにしましょう。

 first commitとしてテンプレートをリモートリポジトリに登録しておくことで、バックアップを取りながら手元での開発を進めることができるためです。

「first commit」をリモートリポジトリへプッシュする

 ではいよいよ、つまり手元のPC環境であるローカルリポジトリから、リモートリポジトリであるGitHubへプッシュしていきます。

 git push は、ローカルリポジトリの変更内容(今回はであればfirst commit)をリモートリポジトリにアップロードする際に使用されるコマンドです。

1.

下の画像のとおり、目的のリポジトリのページを開き、①「SSH」の項目を選択していることを確認後、②GitHubリポジトリのSSH形式のURLをコピーします。

2-1.

続いて、以下のコマンドをターミナルに入力していきます。

$ git␣remote␣add␣origin␣(SSH形式のURL)

(SSH形式のURL)の部分には、先ほどコピーしたSSH形式のURLを貼り付けます。

実際のコマンドは以下のとおりです。

$ git␣remote␣add␣origin␣git@github.com:mimimi-zomy/resume1.git

当然ですが、git@github~の部分は使用者ごとに異なりますので、ご自身でコピーしたものを貼り付けてください。

Enterキーを押して実行すると、リモートリポジトリが登録できました。

2-2.

入力したコマンドについて、もう少し踏み込んで説明しますと…

  • git remote add:これは、新しいリモートリポジトリを現在のローカルリポジトリに追加するために使用されるGitコマンドです。
  • origin:これはリモートリポジトリの短縮名です。Gitでは、デフォルトのリモートリポジトリを指す名前として「origin」が一般的に使用されます。この名前は任意で変更することも可能ですが、今回も慣例にならって「origin」を指定しています。
  • git@github.com:mimimi-zomy/resume1.git:これはリモートリポジトリのSSH形式のアドレスです。入力された内容からは、GitHub上の mimimi-zomy というユーザーの resume1 というリポジトリを指している、ということが確認できます(ここはユーザーによって異なりますので、実際の入力時はご自身の情報を入力するようにしてください)。

以上のことから、

$ git␣remote␣add␣origin␣git@github.com:mimimi-zomy/resume1.git

を入力・実行することで、現在のローカルリポジトリに新しいリモートリポジトリを追加することができるというわけです。

3.

では、新しいリモートリポジトリが本当に追加できているかどうか、画面に表示させて確認してみましょう。

以下のコマンドを入力してください。

$ git␣remote␣-v

今回入力したgit remote -vコマンドは、リモートリポジトリのURLを含めて表示するためのコマンドです。

ちなみに-vオプションは「verbose(詳細)」の頭文字で、リモートリポジトリの名前とURLを両方表示することができます。

今回表示させた出力内容は、リモートリポジトリが正しく設定されていることが確認できます。

fetchpushの両方の操作に同じURL(GitHubリポジトリ)が使われていることを示しており、ローカルリポジトリとGitHub上のリポジトリとの間でコードの同期が行える状態になっていることが確認できました。

4.

ここから先はmainブランチが選択されている必要があるため、git branchコマンドで現在のブランチを事前に確認しておきましょう。

$ git␣branch

上の画像では、mainのブランチの左側に*が表示され、mainの文字も緑色で表示されていることから、現在のブランチはmainであることが確かに確認できました。

5.

続いて、以下のコマンドを入力・実行し、ローカルリポジトリの変更をリモートリポジトリにプッシュしていきます。

$ git␣push␣-u␣origin␣main

このコマンドを実行すると、ローカルのmainブランチの変更がGitHubのoriginリポジトリにプッシュすることができます。

6.

コマンドを実行すると色々と結果が表示されますが、確認していただきたい箇所は赤枠で囲った部分です。

表示内容に軽く触れておきます。

  • newbranch main -> main: リモートリポジトリにmainという新しいブランチが作成され、またローカルのmainブランチの内容がそこにプッシュされたと表示されています。
  • Branch 'main' set up to track remote branch 'main' from 'origin': ローカルのmainブランチがリモートのmainブランチをトラッキング(追跡)するよう設定されました。よって、今後のプッシュやプルでブランチ名を指定する必要がなくなったことを示しています。

環境によっては、ここでパスフレーズ(パスワード)の入力を求められる場合もあるかと思いますので、その際にはSSHキー生成時に設定したパスフレーズを入力し、Enterキーで実行をしてください。

7.

では、先ほど開いていたGitHubの「resume1」リポジトリのページをリロードしてみましょう。

すると以前にローカル環境でコミットしたfirtst commitの内容がリモートリポジトリに反映されていることが確認でき、pushに成功したことが画面上でも見て取れます。

8.

今回リモートリポジトリにpushしたすべてのデータには赤枠部分の通りfirst commit というメッセージも関連付けられており、これが一番最初のコミットであることも確認できました。

 以上で、手を加えない状態のテンプレートを、リモートリポジトリであるGitHubにもfirst commitとして登録することができました。

リモートリポジトリの変更をローカルリポジトリに取り込もう

 現在は一人ですべての作業を行っているためリモートリポジトリの状態とローカルリポジトリの状態に差異がでることはありませんが、たとえばチームで開発している場合は、リモートリポジトリに他のチームメンバーが頻繁にアクセスをしているため、自分の手元のローカルリポジトリとリモートリポジトリの進捗状態に差異がでることがあります。

 そのため、自分が作業を進める前にリモートとローカルの状態を同期させ、その後最新の状態から変更などに着手することが重要です。

 今回はその方法について学んでいきます。

「プル」と「フェッチ」2つの選択肢

 Gitにおいてリモートリポジトリからデータをローカルリポジトリに取得するために使用されるコマンドは、「プル(pull)」と「フェッチ(fetch)」という2つの手法があります。

 「プル(pull)」と「フェッチ(fetch)」はそれぞれに異なる動作をするため、以下で簡単に説明をしておきます。

プル(Pull)とフェッチ(Fetch)
  • プルの機能:リモートリポジトリから変更をダウンロードし(これはフェッチの動作と同じ)、さらに現在のローカルブランチにそのデータを自動的にマージ(統合)までを行います
  • フェッチの機能: リモートリポジトリから全ての変更(コミット、ブランチ、タグなど)をローカルリポジトリにダウンロードしますが、現在の作業ブランチには自動的にマージ(統合)までは行いません

一見すると、データのダウンロードからマージまでを一気に行ってくれるpullの方がfetchより便利なように思いますが、安全性の観点から見ればfetchの方に軍配が上がります。なぜなら、現在のブランチの作業に影響を与えずにリモートのデータを取得できる方法がfetchだからです。

pullはリモートの変更を現在のブランチに自動的にマージまで行ってしまうため、ダウンロードしたデータと手元のローカルのデータ内容に矛盾などが生じた場合はコンフリクトが発生してしまう可能性もありますので、その点に注意して使用する必要があります。

 そのため、今回はfetchを使用してリモートリポジトリからデータをダウンロードし、git mergeでデータを統合していく二段階の方法を取りたいと思います。

1.

ではまず以下のコマンドをターミナルに入力し実行します。

$ git␣fetch␣origin

originと入力しているのは、fetch先のリモートリポジトリ名がoriginであるためです。

2.

次に、git merge コマンドを使用して、origin/mainから取得した最新の変更をローカルの作業ブランチにマージしていきます。

$ git␣merge␣origin/main

上記コマンドを実行することで、リモートリポジトリの最新の変更が現在の作業ブランチに取り込まれます。

左画像からは、コマンド実行後の画面にはAlready up to date.(すでにアップデート済み)と表示されたことが確認できます。

現在は一人で作業を進めているため当然ではありますが、リモートリポジトリとローカルリポジトリの内容に変更がなく、ローカルの環境がすでに最新の状態にあることを確認することができました。

 以降は手元のPCなどローカル環境で、テンプレートの文章や画像など、内容を独自のものに書き換えていきます。ですがその際はmainのブランチへ直接書き換えなどを行うのではなく、新しいブランチを新規作成し、mainブランチとは切り離した新規のブランチ上で作業を進めていくことにします。

GitHub Flowについて学ぼう

 では実際に開発を進めていく―――その前に、まずは有名な開発フローである「GitHub Flow」についても触れておきましょう。

 今回ご紹介するフロー(手法)はGitHub社内でも実践されているシンプルなワークフローで、「GitHub Flow」として多くの開発者の間で認知されており、実際数多の開発チームに採用されているものです。

GitHub Flowの流れ

 今回ご紹介する「GitHub Flow」の一連の流れは以下のとおりです。

  1. 作業のたびに新規ブランチを作成
  2. 変更内容を精査
  3. リモートリポジトリのメインやデフォルトのブランチに内容をマージ(統合)

 上記では3工程に分けられていますが、記述されていない重要な項目などを含め各工程をより詳細に紐解いてみると、以下の7工程としてご説明することも可能です。

GitHub Flowの流れ
  1. mainブランチは常にデプロイできる状態を保つ
    • このワークフローの中でもっとも重要視すべき項目です。
    • テストされていないコードや第三者のレビューが行われていないコードはmainブランチに統合すべきではありません。
  2. 新しい作業を行う際は、mainブランチから新ブランチを作成する
    • 新規ブランチを作成しそちらで新しい作業を開始することで、mainブランチを安全な状態に保ちながら作業を進めることができます。
    • 名付けるブランチ名は、そのブランチで何の作業を行っているかすぐに推察できるような具体的なものがベストとされています。
  3. 作成したローカルリポジトリのブランチにコミットする
    • ブランチ名に沿った開発を進めながら、定期的にブランチに加えた変更をコミットします。
    • 特にコミットの粒度については、コミットの意図がプルリクエストのレビュアーに伝わるような間隔で行うことが理想とされています。
  4. 同名のブランチをGitHubのリポジトリに作成し、定期的にプッシュする
    • 2.で新規に作成したブランチをGitHubにプッシュし、新規ブランチと同名のブランチをリモートリポジトリに作成します。
    • 定期的なプッシュはコードのバックアップとしても役立ちますし、同プロジェクトに参加しているリーダーや他の開発者が進捗状況をチェックする機会にもなります。
  5. 助けてほしい時やフィードバックが欲しいときはプルリクエストを作成し、プルリクエストでやり取りする
    • プルリクエストはmainブランチにマージしてほしい場合のみに使用するものではありません。
    • 最終的にmainブランチにマージする予定のブランチが大半かと思いますが、その場合でもマージのずっと前から、レビュアーにコードのレビューをしてもらい、フィードバックを貰いながら開発を進めるべきとされています。
  6. ほかの開発者がレビューし、作業終了を確認したらmainブランチにマージする
    • ブランチでの開発が完了しましたら、マージの前には他の開発者のレビューを必ず受けることにしましょう。
    • 他開発者にチェックして貰うことで、当事者では気づくことのできないミスにもマージ前に気づくことができます。
  7. mainブランチへのマージ後、ただちにデプロイする
    • マージ後はすぐにデプロイし、マージしたコードが問題ないことを確認しましょう。

 そしてこのフローを円滑に回しながら開発を進めていく手法が「GitHub Flow」と呼ばれるものなのです。

 なお今回は練習のため一人ですべての工程を行います。通常は他の開発者と共同で行う「プルリクエスト」も今回は自分で作成するなどして、擬似的な開発フローも体験していくことにしましょう。

GitHub Flowを実践していこう

 では前述の「GitHub Flow」を実践していくことにしましょう。

新規ブランチの作成

1.

まずは現在存在するブランチの確認から行います。

$ git␣branch

git branchコマンドを実行すると、画像のようにmainブランチのみの存在が確認でき、またmainの文字の左側には*の表示も見て取れます。

2-1.

では新しくreplaceというブランチを作成し、作業を進めていくことにしましょう。

$ git␣checkout␣-b␣(ブランチ名)

上記はコマンドの「ブランチ名」の部分に、新規で作成したいブランチの名前を入力すると、ブランチの作成とともにブランチの切り替えまで行ってくれる便利なコマンドです。

では以下のコマンドを実行してみましょう。

$ git␣checkout␣-b␣replace
2-2. 補足

2-1.ではgit checkout -bコマンドを使用することで「新規ブランチの作成」と「新規ブランチへの切り替え」を一気に行いましたが、「新規ブランチの作成」と「新規ブランチへの切り替え」を2回に分けて実行することも可能です。

$ git␣branch␣replace
$ git␣checkout␣replace

上記2回のコマンドを実行しても、「新規にreplaceブランチを作成」し「新規に作成したreplaceブランチへの切り替えを実施することが可能です。

3.

コマンドを実行した結果は左の画像のとおりです。

Switched to a new branch 'replace'とある通り、新規で作成されたreplaceブランチへ切り替えも完了したと表示されています。

4.

再度git branchコマンドを入力してみると、左画像のとおり、新しくreplaceブランチが作成された上に、replaceブランチへの切り替えも完了していることが確認できました。

今後はこのreplaceブランチでテンプレートのソースコードへの加筆や修正、画像の差し替え作業等を行っていきます。

繰り返しになりますが、今回のようにデフォルトブランチであるmainブランチからブランチを新規にを切り離して作業を進めることで、デフォルトのmainブランチに影響を与えずに開発を進めることができ、結果としてバグやエラーなどの不測の事態に備えることができるというわけです。

新規ブランチへのコミット

 では実際にファイルの内容(画像や文章)の差し替えなどが完了した前提で、続きを行っていきます。

1.

まずは改めて、現在のブランチの状態からの確認です。

$ git␣branch

現在存在するブランチはmainreplaceの2つで、そのうちのreplaceブランチを選択中です。

2.

またgit statusコマンドで、現在のワーキングツリーの状態も確認してみましょう。

$ git␣status

コマンドを実行すると①と②が表示がされました。

画面に表示された内容を簡単に説明すると、①「変更はされているがステージングされていない各種ファイル」と②「新規で追加されまだトラッキング(追跡)もされていないファイル」が存在していると表示されています。

3.

では以下のコマンドで、ステージングもトラッキングもされていないファイルすべてを、ワーキングツリーから一気にステージングエリアにステージングしていくことにします。

$ git␣add␣.

git add実行後、git statusコマンドで現状を確認してみましょう。

$ git␣status

すると以下の画像のように出力されました。

出力結果では、replace ブランチ上で行われた変更が、すべてステージングエリアに追加された――つまりコミットする準備が整った――状態であることが、緑色の文字で表示されています。

4.

ではステージングしていた各種ファイルをコミットしていきましょう。

$ git␣commit␣-m␣'名前や写真、文章の差し替え'

名前や写真、文章の差し替えの部分がコミットメッセージです。

画面上には「5つのファイルが変更された」ことと、「142行が追加(挿入)され、226行が削除された」ことが表示されています。

5.
$ git␣status

コミット後にgit statusコマンドを実行してみると、先ほどコミットが成功したため、現在のワーキングツリーはクリーンな状態になっていることが改めて確認できました。

リモートリポジトリにプッシュ

1.

では、これまでローカルリポジトリで行ってきた変更を、リモートリポジトリにプッシュ(送信)していきましょう。

$ git␣push␣origin␣replace

今回pushの際に入力する「origin」はリモートリポジトリの名前を、「replace」はプッシュするローカルブランチの名前をそれぞれ指しています。

ではEnterキーで実行していきましょう。

2.

git push実行後に画面に表示された結果が左画像の内容です。

ローカルの replace ブランチがリモートリポジトリ(GitHub上の mimimi-zomy/resume1)に正常にプッシュされたことを示しています。

表示内容のすべてを説明することまではしませんが、特に注目していただきたい部分は以下の部分です。

*[new branch] replace -> replace

表示内容からは、ローカルの replace ブランチがリモートリポジトリにプッシュされると同時に、新規ブランチとしても作成されたことが確認できます。

プルリクエストを作成

 では続いて、ローカルリモートリポジトリの内容を受信したGitHubでプルリクエストを作成していきます。

 プルリクエストはGitHubが提供している機能のひとつで、ローカルリポジトリからGitHubで受信したブランチや変更内容を実際に取り込んでも問題ないかどうか、確認をしたり検討したりする目的で使用されます。

 今回はひとりですべての作業を行っているためプルリクエストのメリットや恩恵を実感することは難しいかもしれませんが、実際の現場でチームなどで開発を進めている際には、変更を加えた当人以外がチェックを行うという意味で、とても重要なステップのひとつになっています。

1.

git push実行後にGitHubのページをリロードしてみると、replace had recent pushesの文字が黄色く画面に表示されています。

これは直近にプッシュされたreplaceブランチの存在を示しています。

では緑のボタンで表示されている【Compare & pull request】をクリックして、プルリクエストを作成していきましょう。

2.

Compare & pull request】ボタンをクリックすると、左画像のようなプルリクエスト作成画面に移ります。

第一に確認していただきたい点は①と②の表示内容です。

①には「ベースブランチ」、つまり変更内容がマージされる予定のブランチ名が、②にはレビューの対象としたい「トピックブランチ」がそれぞれ表示されています。

今回の場合は、

  • ①「ベースブランチ」:main
  • ②「トピックブランチ」:replace

となっていることを確認した後、作業を進めていきます。

③にはプルリクエストの「タイトル」を、④には今回行うプルリクエストの「詳細内容」を記載できますが、④は空欄のままで簡潔に実行しても支障はありません。

今回は自分ひとりの練習用のため表示されていませんが、本来のプルリクエストの使用目的は、プルリクエストを作成している当人が、他のチームメンバーに内容をレビューしてもらうことです。そのため⑤には通常「Reviewers」が表示され、メンバーを選択できる状態になっています。

⑤でレビュアーを選択し入力が完了したら、いよいよ⑥の【Create pull request】ボタンをクリックし、プルリクエストを作成していきます。

3.

以下の画像は、実際にプルリクエストが作成された画面です。

①の「Pull requests」タブにはプルリクエストが1つあることが表示されています。

また確認していただきたいのは②のRequire approval from specific reviewers before mergingというメッセージです。簡単に説明すると、「マージする前に特定のレビュー担当者からの承認を必要とする」かどうかを念のため提案してくれていまが、今回はひとりでの練習用プルリクエストですのでスルーして問題ありません。

③では、ベースブランチであるmainブランチと今回マージする予定のreplaceブランチの内容にはコンフリクトがない、つまり矛盾する部分はないと表示されています。

上記②と③の内容を確認しても問題がないと判断できるため、④の【Merge pull request】ボタンをクリックし、ベースブランチであるmainブランチにreplaceブランチの内容をマージしていくことにしましょう。

ブランチマージ

1.

Merge pull request】ボタンを押したあとは、最終確認として左画像のような「マージコミットのコメント入力」画面に移ります。

今回は特に問題がないため、デフォルト値の①のまま作業を進めていきます。

内容の確認を終えたら、②の【Confirm merge】ボタンでマージを確定させていきましょう。

2.

プルリクエストがマージされたあとの画面にはPull request successfully merged and closedプルリクエストは無事にマージされ、閉じられました」とのメッセージが表示されます。

プルリクエストは作成後からマージするまでは「オープン」状態、マージ後は「クローズ」状態となるのが一般的です。

3.

その後①の「Code」タブをクリックすると、②のmainブランチに、先ほどマージされたプルリクエストのreplaceブランチのタイトルが表示されていることが見て取れます(③)。

GitHub PagesからWebページを公開しよう

 ではいよいよここからは、マージしたファイルをGitHub PagesでWebページとして公開していくことにしましょう。

1.

まずは画面右上にある「Settings」のタブをクリックしてください。

2.

続いて、左手側に表示される「Pages」の項目をクリックします。

 この時点でページ上部に「Your site is live at GitHub PagesのURL」と表示された場合は、すでにWebページの公開ができています!

 もし表示されていない方は続きもチェックしてみてください。

3.

2.の手順時点でWebページの公開がされていない場合(URLが表示されていない場合)には、「Branch」の項目が「None」となっている可能性があります。

この「Branch」の項目をデフォルトブランチである「main」に選択し直して「Save」ボタンで保存をしてみると…

4.

下画像の赤枠で囲った部分のように、WebページのURLが表示されていることが確認できるかと思います。

 これでWebページをGitHub Pagesを使用してインターネット上に公開することができました!

おわりに

 ここまで、GitHub PagesでのWebページの公開方法を一緒に実践してきましたが、いかがでしたでしょうか?

 「Gitの操作方法」や「GitHubの使い方」、そして「GitHub Flow」などについては、本記事1本を読んだだけでただちに身につけられるものではありませんが、おおよその概要やざっくりとした流れなどはご確認いただけたのではないかと思います。

 より深い知識や技術を習得するには専門教材や専門書籍に頼る必要がありますが、今回ご紹介した一連の操作の「入門編」としてお役立ていただけましたら、大変嬉しく思います!

参考書籍・動画

 最後に、本記事を書くために勉強・参考にさせていただいた書籍と動画を下記にてご紹介いたします。

 本記事がどなたかの学習の役に立つことを願ってやみません。

 では以上、ここまでお付き合いいただきまして誠にありがとうございました!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です