Skip to main content
The Trailblazer Community will be undergoing scheduled maintenance from 8:40 PM PDT on Wednesday, September 30 to 3:00 AM PDT on Thursday, October 1, 2026. During this window, the site will be unavailable.

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 ヘルプ] サむトから新しいフィヌドバックフォヌムにい぀でもアクセスできるようになりたした。

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