Skip to main content

GitHub ワークフローの操作

学習の目的

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

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

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

GitHub ワークフローの概要

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

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

ブランチを作成する

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

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

コミットを実行する

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

プルリクエストを開いてコラボレーションする

プルリクエストを開いて、変更についての話し合いを開始します。プルリクエストはコード改良の出発点であるため、コードが完璧である必要はありません。

メモ

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

メインブランチにマージする

変更がチームに承認されたら、プルリクエストを機能ブランチからメインブランチにリリースしてマージします。 

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

Git をインストールする

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

GitHub アカウントにサインアップしてリポジトリを作成する

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

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

  1. ヘッダーの 新規作成 をクリックして、[New repository (新規リポジトリ)] を選択します。
  2. [Owner (所有者)] で、自分のアカウントを選択します。
  3. [Repository name (リポジトリ名)] に best-repo-ever と入力します。
  4. [Public (公開)] を選択します。
  5. [Initialize this repository with a README (このリポジトリを初期化して README を作成)] で、[Add a README file (README ファイルを追加)] を選択します。
  6. 次に、[Create repository (リポジトリの作成)] をクリックします。

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

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

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

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

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

  1. GitHub で、先ほど作成したリポジトリの [Code (コード)] タブをクリックします。
  2. [Code (コード)] ボタンをクリックします。
  3. クローン URL をクリップボードにコピーします。
  4. コマンドラインアプリケーションを開きます。Mac または Linux を使用している場合は、ターミナルを使用できます。Windows を使用している場合は、Git とともにインストールされる Git Bash を使用することをお勧めします。
  5. GitHub からリポジトリの完全コピーを取得します。
    git clone URL

    上記でコピーしたクローン URL に書き換えます。次のようなコードが表示されます。

    Cloning into 'best-repo-ever'...

    remote: Enumerating objects: 3, done.

    remote: Counting objects: 100% (3/3), done.

    remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)

    Receiving objects: 100% (3/3), done.
  1. クローンが完成したら、クローン操作で作成された新しいディレクトリに移動します。
    cd best-repo-ever

ローカル環境を設定する

コードを変更する前に、基本的な設定をいくつか行う必要があります。通常は、次の設定を 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 を使用してファイルを追跡する

GitHub を操作するためには、要求を認証する手段が必要です。コマンドラインで操作する場合は GitHub CLI、デスクトップの場合は GitHub Desktop を使用できます。このバッジでは GitHub Desktop を使用します。

  1. GitHub Desktop をダウンロードしてインストールします。
  2. GitHub Desktop を起動します。
  3. [Sign in to GitHub.com (GitHub.com にサインイン)] をクリックします。
  4. 指示に従ってアクセスを許可します。
  5. [Configure Git (Git の設定)] で、[Use my GitHub account name and email address (GitHub アカウント名とメールアドレスを使用する)] を選択します。
  6. [Finish (完了)] をクリックします。

これで GitHub Desktop を使用できます。先ほど GitHub でリポジトリをコピーしたため、ローカルリポジトリをリモートの GitHub リポジトリに接続しましょう。

  1. [Add an Existing Repository from your Local Drive (ローカルドライブから既存のリポジトリを追加)] をクリックするか、[File (ファイル)] > [Add Local Repository (ローカルリポジトリを追加)] をクリックします。
  2. [Choose (選択)] をクリックし、best-repo-ever ディレクトリを見つけて選択します。
    [Choose (選択)] が強調表示されている [Add Local Repository (ローカルリポジトリを追加)] ウィンドウ
  1. [Open (開く)] をクリックします。
  2. [Add Repository (リポジトリを追加)] をクリックします。
    [Current Repository (現在のリポジトリ)] が best-repo-ever に設定され、[Current Branch (現在のブランチ)] が main に設定されている GitHub Desktop

リポジトリのローカルコピーを作成し、Git の設定と GitHub への認証を行ったら、GitHub ワークフローを使用してプロジェクトに変更を実行できます。ここでは、コマンドライン、GitHub Desktop、GetHub を切り替えながら、Git を操作していきます。最初に、README.md ファイルに簡単な変更を加えてみましょう。 

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

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

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

  1. ブランチを作成します。
    git branch myfeaturebranch
  1. このブランチにチェックアウトします。
    git checkout myfeaturebranch

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

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 status コマンド、git add コマンド、git commit コマンドを使用して実行します。 

  1. ワーキングツリーの状況を確認します。
    git status

    Changes not staged for commit で README.md ファイルが変更されていることがわかります。

    “”
  1. ファイルをワーキングツリーからステージングエリアに移動します。
    git add README.md
  1. 何が起こったのか確認するには、次のコマンドを入力します。
    git status

    Changes to be committed に README.md ファイルがあることがわかります。

    “”
  1. 最初のスナップショットを作成します。
    git commit -m “My first commit”
  1. リポジトリの状況をもう一度確認してみましょう。
    git status
  1. コミットするものがなく、ワーキングツリーがクリーンです。

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

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

このブランチはローカルで作成したため、GitHub Desktop を使用してブランチをリモートリポジトリに公開します。

  1. GitHub Desktop を開きます。
  2. [Publish branch (ブランチを公開)] をクリックします。

ステップ 4: プルリクエストを作成する

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

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

    main ブランチと myfeature ブランチ間の変更を比較する GitHub のスクリーンショット
  1. [Create pull request (プルリクエストを作成)] をクリックします。
  2. [Add a title (タイトルを追加)] は My first commit (私の 1 つ目のコミット) になるはずです。
  3. 必要に応じて説明を追加します。
  4. [Create pull request (プルリクエストを作成)] をクリックします。

コードレビューを使用してコードの品質を管理する

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

一般的な会話

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

行コメント

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

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

レビュー

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

自動テスト

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

リリース

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

変更をマージする

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

マージはすばやく簡単に実行できます。

  1. GitHub で [Conversation (会話)] タブをクリックします。
  2. [Merge pull request (プルリクエストをマージ)] をクリックします。
  3. コミットメッセージと詳細な説明を追加します。
    [Commit message (コミットメッセージ)]、[Extended description (詳細な説明)]、[Commit email (コミットメール)]、[Confirm merge (マージを確認)] ボタンが表示されている [Merge (マージ)] ウィンドウ
  1. [Confirm merge (マージを確認)] をクリックします。

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

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

すべて同期された状態を保つ

プルリクエストをマージしたら、GitHub のブランチを削除します。その場合は、プルリクエスト画面の [Delete branch (ブランチを削除)] をクリックします。

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

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

  1. デフォルトブランチに切り替えます。
    git checkout main
  1. GitHub からすべての変更を取得します。
    git pull
メモ

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

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む