Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

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. リポジトリ名に「best-repo-ever」と入力します。
  3. プロジェクトを公開にするか非公開にするかを選択します。
  4. [Initialize this repository with a README (このリポジトリを初期化して README を作成)] で、[Add a README file (README ファイルを追加)] を選択します。
  5. 次に、[Create repository (リポジトリの作成)] をクリックします。

リポジトリ名と初期化が上記の説明のとおり設定されている [Create a new repository (リポジトリの新規作成)] 画面

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

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

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

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

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

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

Cloning into 'best-repo-ever'...remote: Counting objects: 3, done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.

  1. クローンが完成したら、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」と入力します。現時点ではおそらメインのブランチが 1 つだけ表示されます。 

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

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

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

kjameson-ltm:best-repo-ever kjameson git branch

* main

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 (ベース)] ドロップダウンで、[main] を選択します。 
  5. [Compare (比較)] ドロップダウンで、[myfeaturebranch] を選択します。次のようなコードが表示されます。マスターブランチと myfeature ブランチ間の変更を比較する GitHub のスクリーンショット。
  6. [Create pull request (プルリクエストを作成)] をクリックします。 
  7. 件名とコメントを入力します。
  8. [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 main で、デフォルトブランチに切り替えます。
  2. 次のコマンドで、GitHub からすべての変更を取得します。

    git pull
    kjameson-ltm:best-repo-ever kjameson git checkout main
    Switched to branch 'main'
    Your branch is up-to-date with 'origin/main'.
    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 main -> origin/main
    Updating f464053..599f35f
    Fast-forward
    README.md | 4 +++- 1
    file changed, 3 insertions(+), 1 deletion(-)
メモ

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

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

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

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