VS Codeを活用した開発 (Gitの各種操作・デバッグ) -人工知能応用特論Ⅰ 第5回

2025年度 人工知能応用特論Ⅰ： 機械学習・データサイエンスのための プログラミング 第5回: Visual Studio Codeを活用した開発 東京農工大学大学院先進学際科学府 山田宏樹 1

スケジュール 第1回：Gitの基礎 第2回：Git・GitHubの実践 第3回：Pythonの環境構築 第4回：Dev Containerによる開発環境の構築 第5回：Visual Studio Code (VS Code) を活用した開発 第6回：読みやすいpythonコードの書き方 第7回：pytestを使ったテスト駆動開発 第8回：機械学習のプロジェクトにおける実験管理 スケジュールはあくまで暫定的なものです 2

今回の授業の目標 VS Codeを使った開発の基礎を学ぶ 世の中にはたくさんのテキストエディタが溢れています．特にこだわりがなけれ ば，ひとまずVisual Studio Code (VS Code) を使ってみるのがおすすめです．すで にこだわりを持って他のエディタを使っている人は，VS CodeでどのようにGitの 操作やデバッグができるか本講義で知ってもらえればと思います．(一応補足して おきますが，VS Codeを使うことを強制している訳ではないです) エンジニアのテキストエディタ論争については以下の動画がおすすめです． YouTube:「テキストエディタ戦争」とは何か？-ゆるコンピュータ科学ラジオ 3

• https://www.youtube.com/watch?v=KpDTFSijA6U

実行環境 今回の講義で使うツールは以下の通り Git GitHub GitHub CLI Visual Studio Code (VS Code) 講義の課題で，上記のインストールは完了していると思います． 4

目次 1. VS Codeの基礎 (復習) VS Codeの画面構成 VS Codeのワークスペース VS Codeのコマンドパレット 2. VS CodeでのGitの操作 ブランチ戦略 GitHub flowをVS CodeのGit操作で実践する 3. VS Codeでのデバッグ デバッグの流れ Pythonデバッグの設定 デバッグの演習 5

1. VS Codeの基礎 (復習) 6

VS Code の画面構成 アクティビティーバー サイドバー エディタ パネル ステータスバー 7

VS codeのワークスペース 一般的に開発プロジェクトに必要な設定ファイルやソースコードは一つのフォル ダにまとめて管理します．gitでは，このフォルダをプロジェクトと呼び，そのフ ォルダの直下で .git が作られていたかと思います． VS Codeでは開発プロジェクトごとの作業環境をワークスペースと呼びます． A Visual Studio Code workspace is the collection of one or more folders that are opened in a VS Code window (instance). In most cases, you will have a single folder opened as the workspace. However, depending on your development workflow, you can include more than one folder, using an advanced configuration called Multi-root workspaces. What is a VS Code workspace? VS Codeではgitのプロジェクトに相当するフォルダをワークスペースとして開 き，開発を進めていくのが基本です． 8

• https://code.visualstudio.com/docs/editing/workspaces/workspaces

ワークスペースとしてフォルダを開く ワークスペースとしてフォルダを開く方法は5パターンあります． ウィンドウメニューから「File」→「Open Folder...」を選択 コマンドパレットから「File Open Folder ...」を選択 エクスプローラービューを開き「Open Folder」を選択 フォルダをVS Codeのウィンドウに，ドラッグ＆ドロップ シェル上で開きたいフォルダまで移動し code . を実行 演習：上のどの方法を使ってもいいので，下記のリポジトリをクローンし て，そのフォルダをワークスペースとして開いてください． https://github.com/koki-yamada-lab/devcontainer_lecture 9

• https://github.com/koki-yamada-lab/devcontainer_lecture

以下のような感じで， devcontainer_lecture がワークスペースとして開くこと ができていればOKです． 10

コマンドパレット コマンドパレットは全てのコマンドを検索・実行できる機能です．各種操作で使 うことが多いので，ショートカットキーを覚えてすぐ開けるようにしましょう． ショートカットキー: Windows/Linux: Ctrl + Shift + P macOS: Command + Shift + P 11

コマンドパレットの使用例 の各種操作を行いたいと思ったとき，コマンドパレットで git と検索してみ ましょう． git 関連のコマンドが候補として表示されます．表示されたコマンド をクリックするとその操作が実行できます． git コマンドパレットは Esc キーで閉じることができます 12

ファイルのあいまい検索 Windows/Linux: Ctrl + P macOS: Command + P でワークスペース内のファイルをあいまい検索できます．あいまい検索なので， ファイル名の部分一致でも検索されます．また，さっきのコマンドパレットと違 い > が検索の部分に記入されていないことに注意してください．ちなみにこの検 索部分で > を入力するとコマンドを検索できます． 13

2. VS CodeでのGitの操作 14

Gitを使った実際の開発の流れを体感しよう！ 第1回，第2回でGitとGitHubの操作を解説したと思います．コマンドラインでGitを 操作するのは面倒だと思いませんでしたか？もちろんCLIでGitを操作する人もい ると思いますが，個人的にはVS CodeでGitの操作をするのが楽だと思います． 実際の開発ではGitをどう使う？ Gitを実際の開発で使う時には，チームでGitの運用ルールを決めます．その中で重 要なルールの一つがブランチ戦略です． これから扱う内容 まず，第2回講義で時間がなくて説明できなかったブランチ戦略を解説します このブランチ戦略の流れをVS CodeのGit操作で演習してみましょう 15

ブランチ戦略について ブランチ戦略は，どのブランチをどの目的で作るか，まだどう管理するかを規定 したルールのことであり，有名なものだとGit flowやGitHub flowなどがあります． Git flow 大規模なチームで開発するときに用いられるブランチ戦略です． main , develop , feature , release , hotfix というブランチを運用して，開発を進めます．この ブランチ戦略はかなり複雑な運用をするので，研究などで個人開発する時には， あまり適していないブランチ戦略かもしれません． 参考1: Gitflow 戦略の利点と欠点 参考2: 特別な理由なしにgit-flowを新規採用するべきではない GitHub flow 小規模開発や研究に適したシンプルなブランチ戦略です．本講義ではGitHub flow に基づくワークフローを解説します． 参考: GitHub フロー 16

• https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/choosing-git-branch-approach/advantages-and-disadvantages-of-the-gitflow-strategy.html
• https://qiita.com/ktateish/items/76ca0130aec3be05376c
• https://docs.github.com/ja/get-started/using-github/github-flow

GitHub flowに基づくワークフロー 基本方針 と feature の2種類のブランチを運用 main ブランチでは動作確認ずみで安定状態のバージョンを管理 開発はすべて main から派生した feature ブランチで行う main では開発を行わず， feature ブランチをマージして機能を追加する main 17

1. Featureブランチを作る Featureブランチの名前は，そのブランチで何の作業を行なっているかがわかるよ うなものにしましょう．ここでは例として，data loaderを実装するために， add_dataloader という名前のfeatureブランチを作ってみましょう． git switch -c add_dataloader は「create」の意味しており，新しくブランチを作成して自動でそのブランチ に切り替えます． -c main main feature add_dataloader 18

2. Featureブランチで作業を進める Featureブランチでdata loaderの実装をすすめ，適宜コミットしましょう．また， 下記コードを実行すると，リモートリポジトリに add_dataloader ができ，バッ クアップを取ることができます． git push -u origin add_dataloader 初回のみ -u をつけ，上流ブランチの設定をしましょう．次回以降は単に git push でOKです． 作業が完了したら，テストをして追加した機能が正しく動作するか検証します （pytestによるテストの書き方についても本講義で解説予定です） main main feature ・・・ add_dataloader 19

3. (複数人で開発をしている場合) pull requestを作成する 個人開発の場合，この作業は必須ではありません 1. コードに加えた変更に関して，コラボレーター (先輩，指導教員，共同研究 者など)にフィードバックを依頼するpull requestを作成します． 2. レビュー担当者は質問，コメント，提案を残します． 本講義では，これ以上pull requestとレビューについて踏み込みませんが，以下の 資料が参考になります． GitHub Docs: pull requestを作成 GitHub公式サイトでpull requestの作成方法が説明されています GitHub Docs: pull requestでの変更をレビューする GitHub公式サイトでpull requestでの変更をレビューする方法が説明されています CyberAgent AI Lab研修 / チーム開発から学ぶコードレビューのお作法 CyberAgentのAI Labの研修資料が公開されています．コードレビューのお作法や ベストプラクティスがまとまっているので，チーム開発をする人は必見です ※ 20

• https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
• https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests
• https://speakerdeck.com/chck/code-review-in-a-team

(補足) なぜpull requestという名前？ 自分が変更した内容を main にマージするようにお願いするので，merge request ではないのかと思うかもしれません． その感覚は普通で，実際にGit LabというサービスではGitHubのpull requestに相当 する操作にmerge requestという名前がついてます． Pull requestの意味としては，他のコラボレーターに対して，「自分のリポジトリに pullして検証してみてね」という意味が込められているらしいです． 参考:Why is it called a pull request instead of a merge or add request? 21

• https://www.reddit.com/r/git/comments/nvahcp/why_is_it_called_a_pull_request_instead_of_a/

4. Featureブランチをマージする マージの仕方にはいくつか種類があります．本講義ではNon-fast-forward merge とsquash mergeを取り上げます． ※ リベースという操作を使ってマージする方法もあるのですが，リベースには注意 すべきポイントも多いのと使わなくても特に問題にはならないので，本講義では 取り上げません． マージについておさらい 指定したブランチの変更を現在のブランチに統合する操作をマージと呼びます． GitHub flowではfeatureブランチでの作業完了後に， main に feature ブランチの 変更を取り込むので， git switch により main に移動した後で， git merge を する必要があります． 22

Non-fast-forward mergeによるfeatureブランチの変更を統合 Non-fast-forward mergeは以下のように実行できます． git switch main git merge --no-ff add_dataloader Non-fast-forward mergeの特徴はfeatureブランチのコミットが全て残ることです． 細かい変更も全て残ってしまうため，注意して運用しないと履歴が煩雑になりま す． git rebase -i を活用することでコミットをまとめたりすることもできます が，運用が複雑になりがちです．個人的には次に紹介するsquash mergeの方がシ ンプルで運用しやすくておすすめです． main main git merge --no-ff add_dataloader main feature ・・・ ・・・ add_dataloader add_dataloader 23

Squash mergeによるfeatureブランチの統合 Squash mergeは以下のように実行できます． git switch main git merge --squash add_dataloader git commit により，現在のブランチとmerge対象のブランチの差分が 一つにまとめられ，ステージングされた状態となります．ステージングまでしか されないので忘れずに git commit をする必要があります． git merge --squash main main feature main git merge --squash add_dataloader git commit 変更を⼀つにまとめる ・・・ ・・・ add_dataloader add_dataloader 24

Squash mergeの利点 featureブランチの余計なコミットで main ブランチの履歴を汚すという心配 がない featureブランチでコミットを綺麗にまとめるという運用をする必要がない → 適当なタイミングでコミットを作りバックアップをするという運用が可能 main で作られるコミットはfeatureブランチ単位で作られるので， main ブラ ンチの履歴がシンプルになる main main feature main git merge --squash add_dataloader git commit 変更を⼀つにまとめる ・・・ ・・・ add_dataloader add_dataloader 25

(補足) Pull requestを作成した場合のマージ方法 Pull requestを作成した場合，レビュー担当者によるレビュー後に修正を行なった 上でGitHub上でマージを行います．GitHub上で，通常のマージ，Squash merge， リベースを使ったマージを選べます．詳しくはGitHub公式サイトの以下のページ を参考にしましょう GitHub Docs: pull request のマージ 26

• https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request

5. Featureブランチを削除する ここでは，squash mergeをした前提で話を進めます．GitHub flowではfeatureブ ランチをマージ後には，featureブランチを削除することが多いです．これは，た くさんのブランチが履歴に残ったままだと混乱を引き起こす原因となるためで す．以下のようにしてブランチを削除します． git branch -D add_dataloader Squash mergeをした場合だと，featureブランチを削除すれば，そこで作られたコ ミットはログで表示されなくなります， git branch –D add_dataloader main main この部分は内部的には保存されたままだが， 到達不能コミットとなりログで表⽰されなくなる ・・・ ・・・ add_dataloader 到達不能コミットはどのブランチからも 辿れないコミットのことを指す．⼀定期間経過すると， 到達不能コミットは gitのガベージコレクションにより消去される． 27

ここまでの作業がGitHub flowで開発を進める1サイクルです． 例えば次にCNNを作るなら， add_CNN というfeatureブランチ を作って，再びこのサイクルを実施します． 28

GitHub flowのおさらい GitHub flowに基づくワークフローでの実装の流れ 1. Featureブランチを作る 2. Featureブランチで作業を進める 3. (複数人で開発をしている場合) pull requestを作成する 4. Featureブランチをマージする 5. Featureブランチを削除する 1から5のサイクルを繰り返す 29

(演習) GitHub flowをVS Codeで実践してみよう これまで説明したGitHub flowをVS CodeのGit操作で演習します． VS Codeの拡張機能 Git Graph をインストールする まずは，VS Codeの拡張機能ビューから git graph をインストールします． 30

0. GitHub上でリポジトリを作り，ローカル環境にクローン まず，GitHub上で git_vscode というリポジトリを作りましょう． GitHubでリポジトリを作る方法を忘れた方は，第2回講義資料を参照 作ったリポジトリをローカル環境にクローンしましょう 作ったリポジトリを git clone でローカルの環境にクローンして，VS Codeでワ ークスペースとして開きましょう 31

1. VS CodeでFeatureブランチを作る 1. ソースコントロールビューの CHANGES の右にある ⋯ をクリックし， Branch → Create Branch … か Cretate Branch From … をクリック ( Create Branch … はカレントブランチからブランチを作成し， Cretate Branch From … は指定したブランチから新たなブランチを作成します) 2. 新しく作るブランチの名前を入力すると，ブランチの作成が完了し，新しく 作られたブランチがカレントブランチとなります． 32

実行結果 add_dataloader というブランチを作った結果は以下のようになります． ステータスバーにはカレントブランチが表示されます．カレントブランチが add_dataloader となっていることがわかると思います． 33

(補足) 様々なブランチの作り方 上述した方法以外にも，VS Codeでブランチを作る方法は2つあります． ステータスバーに表示されているカレントブランチの名前をクリック → Create New Branch か Create New Branch を選択してブランチを作成 コマンドパレットを開き， git create branch と検索し， Create Branch … か Cretate Branch From … を選択しブランチを作成 34

2. Featureブランチで作業を進める: VS Codeでのgitの各種操作 git add の方法 以前のコミットから変更があると，ソースコントロールビューの Changes に変更 されたファイルが表示されます．試しに， README.md に適当な変更を加え，新た に main.py を作ってみましょう．そうするとソースコントロールビューは以下の ように見えると思います． 35

のところのファイル名の横に表示されている + をクリックすると，その ファイルがステージング，つまり git add されます．ステージングされたファイ ルは Staged Changes に表示されます．またステージングされたファイルの横に 表示される - をクリックするとステージングを解除できます． Changes 36

git commit の方法 ソースコントロールビューに表示されている ✓ Commit と書かれている青いボタ ン上部のテキストボックスには，コミットメッセージを入力できます．メッセー ジを入力後に ✓ Commit をクリックするとコミットが実行されます． ちなみに GitHub Copilot が入っているとテキストボックス右側に 二つの菱形マー ク が表示されます．そのマークをクリックすると，AIがこれまでの変更を要約し たコミットメッセージを生成してくれます． 37

git commit の実行結果 ソースコントロールビューの GRAPH の部分に注目すると，新しいコミットとその コミットメッセージが追加されていることがわかると思います． 38

git push の方法 リモートリポジトリに同期していないブランチの場合，ステータスバーのカレン トブランチ名の横に， 雲に↑がついたマーク のアイコンが表示されます．そのアイコ ンをクリックすると， git pull と git push が同時に実行されます．実行後， GitHubをみると， add_dataloader のブランチが同期されていることが確認でき ます．つまり，Featureブランチでの作業内容がGitHub上にバックアップされたこ ととなります． 39

(補足) git pull と git push を個別に実行したい場合 と git push を個別に実行したい場合は，ソースコントロールビューの CHANGES の右にある ⋯ をクリックし， Pull または Push を選択して実行するこ とができます．このとき，上流ブランチとして設定されているリモートリポジト リに対して，これらの操作が実行されます．(上流ブランチについて忘れた人は第 2回講義資料の「上流ブランチとリモート追跡ブランチ」を参照)．今回は，自分 のGitHubで作ったリポジトリをクローンしているので，すでに上流ブランチとし てGitHubのリポジトリが登録されています． git pull 40

3. (複数人で開発をしている場合) pull requestを作成する この操作はGitHub上で行います．GitHub上でリポジトリを開き，作業していたブ ランチを開くと上部に Compare & pull request という緑色のボタンが出るの で，それをクリックするとpull requestを作成することができます．ここではこれ 以上詳しく解説しません． 41

4. Featureブランチをマージする では，VS CodeでFeatureブランチの変更を main に取り込みましょう． 1. まず， main ブランチに移動します．ソースコントロールビューの CHANGES の右にある ⋯ をクリックし， Checkout to … を選択して main を選ぶと，カ レントブランチが main に変更されます． 42

2. main に移動すると，ソースコントロールビューの GRAPH で add_dataloader のコミットが見えなくなりますが，驚かないでください． ソースコントロールビューの CHANGES の git graph のマークをクリックする とGit Graphのエディタが開きます．そこで add_dataloader がちゃんと存在 していることが確認できます． 43

3. 開いた git graph のエディタでマージしたいブランチを右クリックし， Merge into current branch … を選択します．すると，マージの仕方のオプ ションが表示されます．Squahs mergeをする場合は Squash Commits にチェ ックを入れましょう．Squash mergeを実行すると， add_dataloader ブラン チが残ったまま， main に add_dataloader の変更を一つにまとめたコミッ トが作られます．(Squash mergeの効果をわかりやすくするために， add_dataloader でもう一つコミットを追加して図を作ってます． ) 44

5. Featureブランチを削除する でFeatureブランチを右クリックして， Delete Branch … を選択しま す．すると，選択したブランチを削除するかの画面が表示され， Force Delete にチェックを入れると強制削除( git remove の -D オプションと同義)を実行し， Delete this branch on the remote にチェックを入れると，リモートリポジト リのFeatureブランチも削除されます．GitHub Flowだと開発を完了したFeatureブ ランチは基本的に削除するので，両方にチェックを入れて削除しましょう．ブラ ンチを削除すると以下のようになります． git graph 45

そして，まだローカルで main に add_dataloader で取り込んだコミットをリモー トリポジトリに反映していないので， Sync Changes と書かれた青いボタンをク リックすると，リモートリポジトリに変更を同期することができます．この操作 はブランチを削除する前にやっても大丈夫です． ここまででGitHub Flowの1サイクルが完了です 46

3. VS Codeでのデバッグ 47

デバッグ みなさん，デバッグ機能は使っていますか？もし，printデバッグ (実行途中の変数 の状態等を一時的にprint文で画面に出力するデバッグ方法) をしているなら，今日 の講義で卒業しましょう！ VS Codeのデバッグでできること VS Codeは多くのプログラミング言語で使えるデバッグ機能を持っており，異な るプログラミング言語であっても共通のUIでデバッグを実行できます． ソースコードのある行にブレークポイントを設定すると，その行でプログラ ムを一時停止できる ブレークポイントで停止した場所で，変数の確認や評価式の実行，関数の実 行も可能 48

VS Codeでのデバッグの流れ VS Codeのデバッグの流れは以下の通りです (参考：Debug code with VS Code) 1. デバッグ設定のテンプレートを選択し， .vscode/launch.json を作成 2. ブレークポイントを指定 3. デバッグビューからデバッグ設定の名前を選択し，デバッグを開始 4. デバッグモード: ブレークポイントでプログラムが停止するので，デバッグビ ューでブレークポイントにおける変数などを確認．プログラムを1行ずつ実行 したり，次のブレークポイントまでプログラムを実行することが可能 この一連の流れを演習します．まずは以下のdebugの演習をするためのリポジト リをクローンして，VS Codeでワークスペースとして開いてください． https://github.com/koki-yamada-lab/lecture_debug 49

• https://code.visualstudio.com/docs/debugtest/debugging
• https://github.com/koki-yamada-lab/lecture_debug

1. デバッグの設定: lanunch.json の作成 VS Codeでは，デバッグの設定をプロジェクトルートに .vscode/launch.json を 作成する必要があります． .vscode/launch.json を作成するには，デフォルトで 用意されている言語ごとのテンプレートを使うと良いです．今回はPythonのデバ ッグ設定をします． (準備) Pythonの拡張機能を追加する 拡張機能ビューからMicrosoft公式の Python の拡張機能を追加しましょう．この 拡張機能のIdentifierは ms-python.python です． ms-python.python を拡張機能ビ ューの検索ボックスに入力すると見つかります． 50

デバッグビューを開き launch.json を作成する アクティビティーバーの 実行ボタンに虫がついたようなマーク をクリックすると，デ バッグビューが開きます．そこで create a launch.json file をクリックする と，利用するデバッガを選択するポップアップが表示されるので， Python Debugger を選択しましょう．そして，さらにPythonのデバッグのテンプレートが 表示されるので，今回は Python File を選びましょう．ちなみに， Python File with Arguments では引数を指定してデバッグを行う設定が可能です． 51

上記設定をすると，以下のように .vscode/launch.json が自動で作られます． { } // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Python Debugger: Current File", "type": "debugpy", "request": "launch", "program": "${file}", "console": "integratedTerminal" } ] これでひとまず .vscode/launch.json の作成は完了です．もちろんこ の .vscode/launch.json を共有しておけば，どの環境でもこのデバッガを利用可 能となります．すでにプロジェクトルートに .vscode/launch.json がある場合 は， create a launch.json file は表示されないことに注意しましょう． 52

2. ブレークポイントの指定 デバッグをしたいソースコードにブレークポイントを指定しましょう．行番号の 少し左側をクリックするとブレークポイントを指定できます（指定されたところ に赤い丸が表示されます）． では， debug_demo.py を開き， print("Generated data:", data) と書かれた行 にブレークポイントを指定してみましょう． 53

3. デバッグの開始 デバッグビューのデバッグ設定の名前 (今回は Python Debugger: Current File ) をプルダウンから選択し，開始ボタン (緑の▶︎) を押します． 54

4. デバッグモード中にできること 55

ステップ実行ボタン ステップ実行の各種操作を行うことができます． 続行 (Continue): 次のブレークポイントで停止するまで処理を継続 Step Over: 現在の行を実行し，次の行で停止 Step Into: 現在の行の実行が関数の場合，その関数の中でステップ実行に進む Step Out: 現在実行中の関数を終わるまで進め，呼び出し元の関数で停止 Restart: デバッグ実行しているプログラムを再起動 停止 (Stop): デバッグ実行しているプログラムを停止 変数ビュー ブレークポイントやステップ実行でプログラムが停止しているときに，各変数の 値を確認したり更新したりすることができます． ウォッチ式ビュー ウォッチ式ビューでは，任意の評価式を追加することができ，その評価式の結果 を見ることが可能です．試しにウォッチ式に sum(data) と入力してみると，その 56 結果が表示されます．

コールスタックビュー ステップ実行で関数を呼び出している元の関数をリストで表示 ブレークポイントビュー 設定したブレークポイントをリスト表示 デバッグコンソールタブ デバッグ実行時には，プログラムの出力がパネルのデバッグコンソールダブに表 示されます． > のところに評価式を実行することで任意の変数を確認したり，関 数を実行することが可能です． 57

エディタのハイライト 行のハイライトはステップ実行で停止している行を表示し，コード上の変数のポ ップアップは現在の変数の値を表示します． デバッグを完了する ステップ実行ボタンの「続行 (Continue)」でプログラムの実行が完了するか，「停 止 (Stop)」でプログラムを停止すれば，デバッグモードは終了します． 58

(補足) ブレークポイントの種類 ブレークポイントを指定する場所で右クリックをすると，いくつかの種類のブレ ークポイントがあることがわかります． Add Breakpoint : 処理が行に到達したタイミングで停止 Add Conditional Breakpoint : 変数や状態が指定した条件を満たしたときに 停止 Add Logpoint : 評価式を設定しておくと，その行を通過するたびにデバッグ コンソールにログを出力 Add Triggered Breakpint : 指定しておいた他のブレークポイントが起動し たときのみ，ブレークポイントが有効化され，指定しておいたブレークポイ ントが起動しなかった場合は，ブレークポイントが有効化されない． これ以上詳しくは解説しませんが，使ってみると便利です． 59

参考資料 本講義で取り扱えなかった内容 VS CodeでのGitのdiff画面表示，コンフリクトの解消方法 lanch.json のデバッグ設定の詳細 これらの内容は以下の書籍の第4章と第5章を読みましょう！ 森下篤，改訂新版 Visual Studio Code実践ガイド，技術評論社，2024 この本はVS Codeを使い倒すテクニックがたくさん載っていて読んでいて楽しい です．本講義資料もこの本を参考にして作っています．VS Codeを使い倒したい人 はぜひ買って読んでみてください． 60

• https://gihyo.jp/book/2024/978-4-297-13909-4

課題 課題内容 今回紹介した，GitHub Flowの1サイクルを終えた時点でのVS Codeの画面をGit Graphのエディタを表示させた状態で，スクリーンショットをとりSiriusで提出し てください．スクリーンショットの形式は png , jpeg , pdf のどれかにしてくだ さい． 注意事項 ファイル名と拡張子が正しいか確認すること． 締め切り 日本標準時で次回講義の前日の23:59まで 61

課題のスクリーンショットの例: 62

ここまで資料をご覧になっていただきありがとうございます. 資料に間違いがあったり，より良いベストプラクティスがある 場合はご連絡ください．次回以降の講義にフィードバックを活 かします． Twitter: @KokiYamada6 本講義は，学習コストと得られる恩恵のバランスをとっています．より良いベス トプラクティスがあったとしても，学習コストの理由により採用しない場合があ ります．その点についてご了承ください． 63

• https://x.com/KokiYamada6