GitHub ワークフローの操作

学習の目的

この単元を完了すると、次のことができるようになります。

  • GitHub ワークフローの手順を示す。
  • リモート作業環境とローカル作業環境の違いを説明する。
  • ファイルを新規に作成する手順や、既存のファイルに変更を加える手順を実行する。

コード、コラボレーション、出荷の手順を示すフローチャート。

GitHub ワークフローの概要

GitHub フローはコンパクトなワークフローであり、プロジェクトを損う心配をせずに、新しいアイデアを安全に試すことができます。主なステップは次のとおりです。

  1. マスタからブランチを作成する
  2. コミットを実行する
  3. プル要求を開く
  4. コラボレーションする
    1. さらなるコミットを実行する
    2. チームメンバーとコードについてディスカッションやレビューを行う
  5. 最終テストのためにリリースする
  6. ブランチをマスタブランチにマージする

ブランチを作成する
ブランチ機能は Git の主要な概念です。Git ではすべてがブランチ上に存在します。デフォルトでは、プロジェクトの本番バージョンはマスタブランチに存在します。 

新しい機能の試験や問題への対応の準備ができたら、プロジェクトの新しいブランチを作成します。作成されたブランチはマスタとまったく同じですが、変更を実行するとブランチのみに反映されます。 

コミットを実行する
プロジェクト内のファイルに変更を加えたら、その変更を機能ブランチにコミットします。

プル要求を開いてコラボレーションする
プル要求を開いて、変更についての話し合いを開始します。プル要求はコード改良の出発点であるため、コードが完璧である必要はありません。

メモ

メモ

ベストプラクティスとして、プル要求はプロセスのできるだけ早い時期に開くことをお勧めします。これにより、プロセスでチームメンバーとコラボレータが状況を把握でき、変更が違った方向に進んた場合、不要な作業の量を減らすのに役立ちます。

マスタブランチにマージする
変更がチームに承認されたら、プル要求を機能ブランチからマスターブランチにリリースしてマージします。 

理屈がわかったところで、早速実践してみましょう。

Git のインストール

この後 Git のサンプルで作業できるように、まずコンピュータに Git をインストールします。インストールすると、ローカルでリポジトリを操作できるようになります。Git Web サイトにアクセスして、Git の公式バージョンをインストールする手順に従います。インストール時にデフォルト設定をすべて受け入れます。

GitHub アカウントのサインアップおよびリポジトリの作成

最初にすることは、GitHub 個人アカウントへのサインアップです。GitHub の無料バージョンであれば、以下の手順に従います。

次に、作業するリポジトリを作成します。

  1. ヘッダーの プラスアイコンの画像 をクリックして、[New repository (新規リポジトリ)] を選択します。
  2. リポジトリ名に「best-repo-ever」と入力します。
  3. プロジェクトを公開にするか非公開にするかを選択します。
  4. [Initialize this repository with a README (このリポジトリを初期化して README を作成)] を選択します。
  5. [Create repository (リポジトリの作成)] をクリックします。

リポジトリの作成画面のスクリーンショット。

GitHub での作業とローカルでの作業

GitHub で直接プロジェクトを変更することもできますが、大半の人々はローカルマシンで作業することを好みます。ローカルマシンの使い慣れた IDE やテキストエディタで変更を加えることができるからです。ここでいくつかの重要な用語を確認しておきましょう。

  • リモートリポジトリは GitHub 上のリポジトリのコピーです。コラボレータ全員が各自の変更をこのリポジトリに同期させ、グループが利用するための信頼できるソースにします。
  • ローカルリポジトリはユーザのコンピュータ上に格納されている Git リポジトリです。ローカルディレクトリがリモートリポジトリにリンクされている場合、ローカルリポジトリはリモートリポジトリの完全コピーになり、そこにすべてのファイル、ブランチ、履歴が含まれます。

ローカルリポジトリとリモートリポジトリが対話するのは、Git の 4 つのネットワークコマンド (git clonegit fetchgit pullgit push) のいずれかを実行した場合のみです。

リポジトリでローカルに作業する場合は、まずマシンにクローンを作成する必要があります。リポジトリのクローンを作成する手順は、次のとおりです。

  1. GitHub で、先ほど作成したリポジトリの [Code (コード)] タブをクリックします。
  2. [Clone or download (クローンまたはダウンロード)] をクリックします。
  3. クローン URL をクリップボードにコピーします。
  4. コマンドラインアプリケーションを開きます。Mac または Linux を使用している場合は、ターミナルを使用できます。Windows を使用している場合は、Git とともにインストールされる Git Bash を使用することをお勧めします。
  5. git clone <CLONE-URL> で、リポジトリの完全コピーを GitHub から取得します。<CLONE-URL> を、上記でコピーしたクローン URL に書き換えます。次のようなコードが表示されます。
    Cloning into 'best-repo-ever'...
    remote: Counting objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), done.
  6. クローンが完成したら、cd best-repo-ever で、クローン操作によって作成された新しいディレクトリに移動します。

注意: GitHub Desktop などのデスクトップアプリケーションを使用して、Git および GitHub と対話することもできます。こうしたアプリケーションではリポジトリと視覚的に対話できるため、多くの場合はきわめて便利です。

ローカル環境の設定

コードを変更する前に、基本的な設定をいくつか行う必要があります。通常は、次の設定を 1 回のみ行います。Git には、3 つのレベルの設定オプションが用意されています。次の設定コマンドオプションを参照してください。

コマンドオプション 説明
git config --system
システム全体の設定であり、使用中のコンピュータのすべてのユーザに適用されます。
git config --global
ユーザレベルの設定であり、自身のユーザアカウントのみに適用されます。
git config--local
リポジトリレベルの設定であり、このオプションが設定されている特定のリポジトリのみに適用されます。Git 設定のデフォルト値は --local です。

Git によって自動的に追加される設定もいくつかあります。「git config --list」と入力すると、3 つのレベルの設定を確認できます。

Git ではユーザ名およびメールアドレス設定を使用して、作成したコミットごとに固有のフィンガープリントを生成します。 

この設定を行わなければコミットを作成できません。そこでコマンドラインアプリケーションを使用して自身で設定します。

git config --global user.name "First Last"

続いて次のように入力します。

git config --global user.email "you@email.com"

注意: この設定の完了を知らせる確認メッセージは表示されませんが、エラーが表示されていなければ問題ありません。

autocrlf の設定
次に、core.autocrlf を設定します (autocrlf は自動行頭復帰改行のことです)。行末や改行の処理はシステムごとに異なります。別のオペレーティングシステムで作成されたファイルを開き、そのファイルにこのオプションが設定されていない場合、Git は、オペレーティングシステムの行末処理に基づいて、ファイルに変更が加えられたものと解釈します。

Windows ユーザは次のコードを入力します。

git config --global core.autocrlf true

Mac または Linux ユーザは次のコードを入力します。

git config --global core.autocrlf input

GitHub を使用したファイルの追跡

リポジトリのローカルコピーを作成し、Git を設定したら、いよいよ GitHub ワークフローを使用してプロジェクトに変更を加えていきます。最初に、README.md ファイルに簡単な変更を加えてみましょう。 

ステップ 1: ブランチを作成する

ローカルブランチのリストを表示するために「git branch」と入力します。現時点ではおそらく master というブランチが 1 つだけ表示されます。 

作業用の新しいブランチ (myfeaturebranch) を作成します。

  1. git branch myfeaturebranch」と入力します。
  2. git checkout myfeaturebranch で、このブランチにチェックアウトします。

次のようなコードが表示されます。

kjameson-ltm:best-repo-ever kjameson git branch
* master
kjameson-ltm:best-repo-ever kjameson git branch myfeaturebranch
kjameson-ltm:best-repo-ever kjameson git checkout myfeaturebranch
Switched to branch 'myfeaturebranch'

注意: 他の VCS でチェックアウトという言葉を聞いたことがある場合、おそらく Git でのチェックアウトとは意味が異なります。Git のチェックアウトは、HEAD という重要なポインタを移動することです。この場合は新しいブランチに移動します。HEAD はブランチの先端を指し示します。HEAD については、最後の単元で詳しく説明します。 

ステップ 2: README.md ファイルを変更して、その変更をローカルリポジトリにコミットする

新しいブランチにチェックアウトしたら、何らかの変更を加えて Git の実際の動作を確認します。

  1. リポジトリの README.md を開きます。
  2. 使い慣れたテキストエディタで何かを追記します。
  3. 記述を終えたら、変更を保存します。

ファイルに何らかの変更を加えたところで、最初のスナップショットを作成します。コマンドラインで作業する場合は、2 段階コミットという概念を理解しておく必要があります。

ローカルで作業する場合、Git はファイルと変更を 3 つのツリーに配置する方法で履歴を維持します。この 3 つのツリーは、ワーキング、ステージング (インデックスともいう)、履歴です。ファイルの追加、削除、変更は、ワーキングツリーで行います。

Git の 3 つのツリー (ワーキング、ステージング、履歴) の図。

変更をバージョン管理に追加するには、個別の作業単位を表すファイルのコレクションを作成します。ここではワーキングエリアでこの単位をビルドします。

構成した作業単位に問題がなければ、ステージングエリア全体のスナップショットを作成します。この操作をコミットといいます。

このプロセスは、git add コマンドと git commit コマンドを使用して実行します。 

  1. git status で、ワーキングツリーの状況を確認します。
    kjameson-ltm:best-repo-ever kjameson git status
    On branch myfeaturebranch
    Changes not staged for commit:
          (use "git add <file>..." to update what will be committed)
          (use "git checkout -- <file>..." to discard changes in working directory)
       modified: README.md
    no changes added to commit (use "git add" and/or "git commit -a")
  2. git add README.md で、ファイルをワーキングツリーからステージングエリアに移動します。
  3. git status と入力して、どのようになったのかを見てみます。
    kjameson-ltm:best-repo-ever kjameson git status
    On branch myfeaturebranch
    Changes to be committed:
          (use "git reset HEAD <file>..." to unstage)
       modified: README.md 
  4. git commit -m “My first commit” で、最初のスナップショットを作成します。
  5. git status でリポジトリの状況をもう一度確認してみましょう。
    kjameson-ltm:best-repo-ever kjameson git status
    On branch myfeaturebranch
    nothing to commit, working tree clean

ステップ 3: 変更をリモートリポジトリに送信する

現段階では、このコミットはローカルにしか行われていません。リモートリポジトリを確認すると、自身のブランチも、たった今実行した変更も表示されません。変更をリモートに表示するには、最初にリモートリポジトリに変更をプッシュする必要があります。 

このブランチはローカルで作成したため、まずこのローカルブランチに対応するリモートブランチを作成します。同じコマンドで、2 つのブランチの追跡関係も設定します。

  1. git push -u origin myfeaturebranch」と入力します。
  2. 画面の指示に従って、GitHub のユーザ名とパスワードを順に入力します。
    kjameson-ltm:best-repo-ever kjameson git push -u origin myfeaturebranch
    Username for 'https://github.com': kierenjameson
    Password for 'https://kierenjameson@github.com':
    Counting objects: 6, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (4/4), done.
    Writing objects: 100% (6/6), 551 bytes | 0 bytes/s, done.
    Total 6 (delta 1), reused 0 (delta 0)
    remote: Resolving deltas: 100% (1/1), done.
    To https://github.com/kierenjameson/best-repo-ever.git
       * [new branch] myfeaturebranch -> myfeaturebranch
    Branch myfeaturebranch set up to track remote branch myfeaturebranch from origin.

注意: この長いコマンドが必要になるのは、新しいブランチを初めてプッシュするときのみです。その後は「git push」と入力します。

ステップ 4: プル要求を作成する

リモートリポジトリに変更をプッシュしたら、GitHub でプル要求を開いてみましょう。 

  1. Web の GitHub アカウントに移動します。
  2. [Pull Request (プル要求)] タブをクリックします。
  3. [New Pull Request (新規プル要求)] をクリックします。
  4. [Base (ベース)] ドロップダウンで、[master] を選択します。
  5. [Compare (比較)] ドロップダウンで、[myfeaturebranch] を選択します。次のようなコードが表示されます。

マスタブランチと myfeature ブランチ間の変更を比較する GitHub のスクリーンショット。

  1. [Create pull request (プル要求を作成)] をクリックします。
  2. 件名とコメントを入力します。
  3. [Create pull request (プル要求を作成)] をクリックします。

コードレビューによるコードの品質管理

プル要求の役割はブランチを比較することだけではありません。手動と自動の両方でコードをレビューして品質を保証する手段でもあります。

一般的な会話
[Conversation (会話)] タブでは、プル要求に一般的なコメントを追加できます。

行コメント
[Files Changed (変更されたファイル)] タブ (A) の行にマウスポインタを置くと、青い + アイコン (B) が表示されます。このアイコンをクリックすると、特定の行にコメント (C) を入力できます。こうした行レベルのコメントは、推奨する変更を補足説明する最適な手段です。これらのコメントは会話ビューにも表示されます。

行コメントの追加方法を示すスクリーンショット。

レビュー
行コメントの記入時に、[Start a Review (レビューを開始)] (D) を選択することもできます。レビューの作成時に、多数の行コメントを概要メッセージにまとめることができます。レビューを送信するときに、単なるコメントなのか、承認なのか、あるいは変更依頼なのかを示すことができます。GitHub でプル要求のレビューとブランチ保護を併用すると、プル要求にレビューが 1 つも存在しない場合のマージを禁止することができます。

自動テスト
プロジェクトに CI/CD を統合している場合は、プル要求上にテストの状況がレポートされます。これらのテストは自由にカスタマイズできます。

リリース

チームメンバーによるプル要求のレビューと承認が終わり、必要なテストすべてに合格したら、ブランチをリリースして本番で変更を検証できます。変更に問題がある場合は、既存のマスタを本番にリリースして戻すことで、変更をロールバックできます。

変更のマージ

ブランチをマージするときは、機能ブランチからコンテンツと履歴を取得して、マスタブランチのコンテンツと履歴に追加します。

マージはすばやく簡単に実行できます。[Merge pull request (プル要求をマージ)] をクリックし、マージコメントを追加して、[Confirm merge (マージを確認)] をクリックするだけです。

誰がプル要求をマージするのかについて、チームでルールを定めておきます。次のようなルールな考えられます。

  • プル要求を作成した人がマージする。マージに起因するイシューは、プル要求の作成者が解決する必要があるためです。
  • プロジェクトチーム内の 1 人を指名する。この方法では一貫性が保たれますが、作業が滞る可能性があります。
  • プル要求の作成者以外の全員がマージできる。この方法では必ずレビューが 1 回以上実施されます。

すべて同期された状態で維持

プル要求をマージしたら、GitHub のブランチを削除します。削除するには、プル要求画面の下部にある [Delete branch (ブランチを削除)] をクリックします。

ただし、GitHub 上でマージおよび削除を行っても、リポジトリのローカルコピーが自動的に更新されることはありません。コマンドラインアプリケーションに戻り、すべて同期しておきましょう。

最初に、GitHub で行った変更をリポジトリのローカルコピーに取り込む必要があります。

  1. git checkout master で、デフォルトブランチに切り替えます。
  2. git pull で、GitHub からすべての変更を取得します。
    kjameson-ltm:best-repo-ever kjameson git checkout master
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.
    kjameson-ltm:best-repo-ever kjameson git pull
    remote: Counting objects: 1, done.
    remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
    Unpacking objects: 100% (1/1), done.
    From https://github.com/kierenjameson/best-repo-ever
           f464053..599f35f master -> origin/master
    Updating f464053..599f35f
    Fast-forward
       README.md | 4 +++- 1
       file changed, 3 insertions(+), 1 deletion(-)

注意: git pull は、GitHub からすべての変更を取得し、現在表示しているブランチを更新して、リモートの変更を反映させる複合コマンドです。git fetchgit merge という 2 つの異なるコマンドが実行されます。