機械学習・データサイエンスのためのプログラミング: Git・GitHubの実践

人工知能応用特論Ⅰ： 機械学習・データサイエンスのための プログラミング 第2回 Git・GitHubの実践 東京農工大学大学院先進学際科学府 山田宏樹 1

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

前回のおさらい 前回の講義でGitの用語を一通り解説しました． Gitの用語を忘れた人は，下記資料で復習しましょう． Gitの仕組みと用語（慶應義塾大学の渡辺先生が公開している資料） 数値計算屋のためのGit入門（慶應義塾大学の渡辺先生が公開している資料） 東京大学の松井勇佑先生のGit/Githubの資料 上記の慶應大の渡辺先生のGit・GitHubの講義は本になってます．より深く学びた い人はこの本で学ぶと良いと思います．本講義もこの本を参考にしています． ゼロから学ぶGit/GitHub 現代的なソフトウェア開発のために 3

• https://speakerdeck.com/kaityo256/github-term
• https://speakerdeck.com/kaityo256/starting-git
• https://eeic-software1.github.io/2020/git/
• https://www.kspub.co.jp/book/detail/5352199.html

実行環境 今回の講義で使うツールは以下の通り Git GitHub GitHub CLI Visual Studio Code (VS Code) 前回の講義の課題で，GitとVS CodeのインストールとGitHubのアカウント作成は 完了していると思います． GitHub CLIのインストールは後ほど説明． 4

GitHubとは？ 様々なサービスを提供している リモートリポジトリを提供 複数人での開発をサポートする機能 (Pull request, コードレビューなど) 自動化とCI/CD (継続的インテグレーション・継続的デリバリー) 機能 他多数 とりあえずは，リモートリポジトリ機能だけ使えれば問題ないです． リモートリポジトリは無料アカウントでも使えます． ⾃分のPC (ローカルリポジトリ) GitHub (リモートリポジトリ) 5

GitHub を使い始める まず，以下のことをやりましょう 1. GitHubへのアカウント登録： 学生はGitHub Educationに登録しましょう．GitHub Copilotなどが無料になりま す．申請はスマートフォンでした方が良いです．申請時にカメラで学生証の写真 を撮ってアップロードする必要があるためです．この写真は申請をしているデバ イスのカメラで撮った写真しか承認されないので注意 2. GitHub CLIのインストール コマンドラインからGitHubの各種操作ができるようになります． GitHub CLIを入れなくてもGitHubは使えますが，すごく便利なのでインストール することを強く推奨します． インストール方法はこちら 6

• https://docs.github.com/ja/education/about-github-education/github-education-for-students/apply-to-github-education-as-a-student
• https://github.com/cli/cli#installation

GitHub CLIを使った認証 ローカルのPCのからGitHubへアクセスできるようにするためには認証が必要 GitHub CLI の gh auth login を使えば簡単に認証が可能となる． 1. ターミナルで gh auth login を実行 gh auth login 2. 認証を行う場所を選ぶ [GitHub.com]を選べば良いです． 3. 認証方式を選ぶ HTTPSとSSHがあります．とりあえず，HTTPSを選べば良いです． 4. 認証をブラウザ経由で行うか選ぶ ブラウザ経由で認証するのが楽． Login with a web browser を選びます． あとはブラウザで認証すれば完了 7

(補足) GitHub CLIを使わずに認証を行う GitHub CLIを使わずに認証をするのは少し面倒です． 例えば，SSH認証する場合はSSH keyをローカルのPCで生成し，そのkeyをブラウ ザでGitHubに登録する必要があります．本講義では解説しませんが，ネットで調 べればやり方は出てきます． 参考：SSHを使用したGitHubへの接続 8

• https://docs.github.com/ja/authentication/connecting-to-github-with-ssh

新規プロジェクトをGit・GitHubで管理し始める 0. （設定していなければ）名前・メールアドレスをgitに登録 gitインストール時にまだ名前とメールアドレスを設定していない人は，ローカル PCのターミナルで以下のコードのようにして設定してください． 一度設定すれば，次回リポジトリを作るときには設定する必要はありません git config --global user.name "K. Yamada" git config --global user.email [email protected] のところは自分の名前に変え， [email protected] を自分のメー ルアドレスに変えること "K. Yamada" 1. GitHub上で新規プロジェクトを作成 GitHubのページのRepositoriesの「New」あるいは「New repository」と書かれた 緑のボタンをクリックすると，新しいリポジトリを作成できます． 9

1.1 General Repository name: リポジトリ名を決めます．プロジェクトの 内容がわかるような簡潔な名前をつけまし ょう．今回は lecture_git とします． Description: リポジトリの説明を加えます． 10

1.2 Configuration Choose visibility: Public か Private を選ぶ． Private に するとリポジトリが外部に公開されない． Start with template: テンプレートリポジトリを指定する．特に なければ No template とする Add README: README.md ファイルはリポジトリの説明 をするためのmarkdwonドキュメント． On にしましょう． Add .gitignore: (.gitignoreは後ほど解説) .gitignoreを指定する．作成するリポジトリ で使用する言語を選びましょう．今回は Python を選びます． Add licence: (今回は説明を省略) 11

2. 作成したリポジトリをローカルのPCにクローン クローンとは？ リモートリポジトリのプロジェクト全体を自分のローカル環境に丸ごとコピー （複製）することを指します． 作成したリポジトリのページの右上あたりにある「Code」と書かれた緑色のボタ ンをクリックするとリポジトリのURLが表示される． 12

ローカルPCのターミナルで，クローンしたい場所に移動したのち， 以下のコードを実行 GitHub CLIを使う場合 上の図で表示されているコードをそのまま実行すれば良い． gh repo clone koki-yamada-lab/lecture_git koki-yamada-lab/lecture_git えてください． HTTPSやSSHの場合 の部分は各自，自身のリポジトリのURLに置き換 git clone [GitHubに表示されているURL] 例: HTTPSの場合 git clone https://github.com/koki-yamada-lab/lecture_git.git プロジェクトが丸ごとローカルPCに複製され，Git・GitHubを使う準備が完了 13

(補足)クローンしたリポジトリについて gitの初期化 前回の講義でgitを初期化するときに git init をすると説明しましたが，クロー ンしてきたリポジトリにはすでに .git はあるので， git init をする必要はあり ません． リモートリポジトリ ローカルのPCにクローンしたローカルリポジトリでは，クローン元のリポジトリ がリモートリポジトリとして自動的に設定されています（remote名はorigin）．な ので，自分のGitHubのリモートリポジトリをクローンした場合，リモートリポジ トリの設定をする必要はありません． 14

3. .gitignore を設定する Gitで管理する必要のないファイルを設定することができます． .gitignore で設定したファイルはGitの管理から除外されます． GitHubでリポジトリを作るときに，.gitignoreに関する設定があったと思いま す．そこでプログラミング言語を指定すると，その言語が生成しがちな中間 ファイルを無視する設定が記載された .gitignore を作ってくれます． (重要) Gitで管理すべきでないファイルとは？ 言語やOSなどが生成する一時・中間ファイルなど 機密情報 容量の大きいデータ (100MB以上のものは禁止，50MB以上で警告が出る) Gitでは，データセットや学習したモデル等を管理すべきではありません．あくま で，コードを管理するツールであることを念頭におくべきです．どうしても大き いファイルを扱いたい場合はGit Large File Storage (Git LFS) がありますが，初心者 が使うのはおすすめしません． 15

.gitignore の設定方法 除外対象としたいファイル名を .gitignore に記載する 例えば， example.png を除外対象としたいなら， .gitignore に example.png と 記載するだけで良い． フォルダ丸ごと管理から除外する 例えば， data というフォルダを除外したい場合， .gitignore に data/ と記載 すれば良い． 特定の拡張子を除外する 例えば，拡張子 png のファイルを除外したい場合， .gitignore に *.png と記載 すれば良い． * はワイルドカードの意味をもつ． より詳細な設定方法 詳細は各自調べてください．例えば，一つのプロジェクト内に複数 の .gitignore を置くことも可能であり，その挙動も明確に規定されています． 16 参考:gitignoreの公式ドキュメント

• https://git-scm.com/docs/gitignore/ja

(補足) .DS_Store を除外する macOSを使って開発をしていると，勝手に .DS_Store というファイルが生成され ます．GitHubで生成された .gitignore には .DS_Store が含まれていないことが 多いので，忘れずに追加しましょう． .DS_Store を公開するとセキュリティリス クにつながる可能性があります． 参考：うさぎでもわかる 今更だが.DS_Storeとはなにか、GitHubとかに公開する とどんな危険性があるのか とはいえ毎回プロジェクトごとに設定するのは面倒... ローカルPCの ~/.config/git/ignore に除外したいファイルを設定すれば，その ローカルPC内の全てのリポジトリでそのファイルが除外されます．以下のコード をローカルPCのターミナルで実行すると， .DS_Store を除外する設定が完了しま す．(Macユーザーは必ずこの設定をしましょう！) mkdir -p ~/.config/git echo '.DS_Store' >> ~/.config/git/ignore 17

• https://zenn.dev/taku_sid/articles/20250514_ds_store_danger

ここまでの内容をおさらい 新規プロジェクトをGit・GitHubで管理し始めるには 0. （設定していなければ）名前・メールアドレスをgitに登録 1. GitHub上で新規プロジェクトを作成 2. 作成したリポジトリをローカルのPCにクローン 3. .gitignore を設定する 続いて，既存のプロジェクトでGit・GitHubの管理を開始する方法を補足 したのち，実際にローカルPCでファイルを編集した内容をリモートリポ ジトリに反映させる方法を紹介 18

（補足）既存のプロジェクトでGit・GitHubの管理 を開始する 講義を受けている方の中には，すでに開始しているプロジェクトに対してGit・ GitHubの管理を開始したい人もいると思います．そのやり方を解説します． 参考：ローカルでホストされているコードを GitHub に追加する 1. .gitignore で .venv や __pycache__ ，容量の大きいデータなどを 除外する．（やり方はこれまで説明した通り） 2. git init をしてgitの初期化をする 管理したいプロジェクトのルートディレクトリで， git init をしてgitの初期化 をします．さらに，プロジェクト内の現在の状態をコミットします．以下がコー ドの一例です． git init git add . git commit -m "Initial commit" 19

• https://docs.github.com/ja/migrations/importing-source-code/using-the-command-line-to-import-source-code/adding-locally-hosted-code-to-github

3. GitHub上で空のリポジトリを作成します． これまで説明した方法でGitHub上で空のリポジトリを作成します． ただし，リポジトリ作成時に README.md ， .gitignore ， LICENSE を加えないよ うに注意．リモートリポジトリに余計なファイルがあると，ローカルと競合する ためです． 4. GitHubのリモートリポジトリと接続する git remote add によりリモートリポジトリと接続します． git remote add origin REMOTE-URL REMOTE-URL の部分はGitHubで作ったリポジトリのURLに置き換えてください． 5. ローカルリポジトリの変更をプッシュします git push -u origin main のオプションについては後ほど補足します． これで設定は完了！ -u 20

コミットをしてその変更をリモートリポジトリに 反映させる 演習： クローンしてきたプロジェクト内に新たなファイルを作り，そ のファイルをステージング，コミットしてからリモートリポジ トリにプッシュしましょう！ 1. まず， hello.py というpythonファイルをプロジェクト内で作成する 以下の内容の hello.py ファイルを作ってください print('Hello world!') 21

2. 編集したファイルをステージングする コマンドでステージングすることができます． hello.py を早速ステージングしてみましょう！ git add git add hello.py これで， hello.py がステージングされました． 実際にgitを活用する時には，個別にファイルをステージングする機会は少ないで す．以下のコードで変更されたコードを全てステージングすることができます． git add . この . はカレントディレクトリを指しており，カレントディレクトリとその中の 全てのファイルとサブディレクトリを追加する操作をしています． 22

3. ステージングした内容をコミットする

コミットはある時点のプロジェクトの状態（スナップショット）を保存すること
を指します．忘れてしまった人は前回の講義資料を見返しましょう．
コミットは git commit コマンドで実行できます．
git commit -m "add hello.py"

以降の文章はコミットメッセージと呼ばれる，そのコミットを端的に表すメ
ッセージです．コミットのたびにコミットメッセージを書く必要があります．
-m

git log

コマンドによりコミットの履歴を見ることができます．（以下，実行例）
yamadakoki@MacBook-Pro-2021 lecture_git % git log
commit a154ee84bacca201723968c5ba6702cf91cce587 (HEAD -> main)
Author: Koki Yamada <メールアドレスが表示される>
Date:
Mon Oct 13 17:45:41 2025 +0900
add hello.py
commit f7208d83eeb9afbb3ffd32dc49909fbb0120e65f (origin/main, origin/HEAD)
Author: Koki Yamada <メールアドレスが表示される>
Date:
Sun Oct 12 16:41:09 2025 +0900

23

4. コミットした内容をリモートリポジトリに反映する これまで変更した内容をリモートリポジトリに反映させます．コミットは複数で も大丈夫です． git push コマンドで実行します． git push REMOTE-NAME BRANCH-NAME ここで REMOTE-NAME はリモートリポジトリのリモート名を表しており，クローン してきた場合デフォルトで origin となってます．また BRANCH-NAME は push し たいローカルリポジトリのブランチ名を表します． つまり，以下を実行すれば良いです． git push origin main これで，変更がリモートリポジトリ (GitHub) に反映されました． 24

リモートの変更をローカルに反映させる ここまででローカルの変更をリモートに反映させる方法を学んだ．次はリモート の変更内容をローカルに反映させる方法を学ぶ． リモートの変更を反映させたい状況の一例 git push後 ローカルの変更が反映される GitHub git push ローカルの変更を反映 (リモートリポジトリ) ⾃分のPC (ローカルリポジトリ) git fetchと git merge or git pull リモートの変更を反映 計算機サーバー (ローカルリポジトリ) 25

演習：GitHub上でリモートリポジトリのファイルに変更を加 え，その変更をローカルリポジトリに取り込む 1. GitHub上で， hello.py に変更を加える 下図の鉛筆マークの部分をクリックすると，そのファイルを編集できます． 26

を "Hello new world" に変更して，右上の「Commit changes...」 と書かれた緑のボタンを押して，コミットします． "Hello world" これで，リモートリポジトリに新しくコミットが加わりました． 27

2. リモートの変更をローカルリポジトリに取り込む によりリモートリポジトリの変更をローカルリポジトリに取り込みま す．リモートリポジトリの変更を全て取り込みたい時には， git fetch の後にリ モート名のみをつけます． git fetch git fetch origin ここで， git fetch は変更をローカルに取り込みますが，ローカルの main や HEAD は移動しないことに注意． main GitHub (リモートリポジトリ) git fetch リモートの変更を反映 main ⾃分のPC (ローカルリポジトリ) git fetchで 追加された部分 origin/main 28

3. fetch した変更をマージする してきたリモートリポジトリの変更を，ローカルリポジトリの main に取 り込みましょう． git merge を使ってカレントブランチに origin/main を取り込むことができま す． fetch git merge origin/main main main git merge origin/main origin/main を使えば， git fetch と git merge を同時にできますが，慣れないう ちは git pull は使わないようにしましょう． git pull 29

(補足) 上流ブランチとリモート追跡ブランチ 上流ブランチ 「このブランチは，どのリモートブランチと対応しているか」を示すために，上 流ブランチという設定が存在します．最初にリポジトリをクローンした直後に， main ブランチとともに「リモートのmainブランチ」に対応する origin/main が 作成され，自動的に origin/main はローカル main の上流ブランチとして登録さ れます． 「（補足）既存のプロジェクトでGit・GitHubの管理を開始する」で説明したよう な状況だと，クローンしてリポジトリを作っていないため，自動で上流ブランチ の設定がなされない．一般的には，最初に push するときに上流ブランチを設定 することができる git push -u origin main オプションをつけることで， push 時に main の上流ブランチとして origin/main を設定してくれます． -u 30

リモート追跡ブランチ ローカルの origin/main はリモートの main を追跡しており， git fetch や git push で同期する．リモートの main ブランチに対して， origin/main をリ モート追跡ブランチと呼びます． main GitHub (リモートリポジトリ) main ⾃分のPC (ローカルリポジトリ) リモート追跡 (remote tracking) 上流 (Upstream) origin/main 31

ここまでの内容のおさらい2 ローカルPCでファイルを編集した内容をリモートリポジトリ に反映させるには 1. git add により，編集したファイルをステージングする 2. git commit により，ステージングした内容をコミットする 3. git push により，コミットした内容をリモートリポジトリに反映する リモートの変更をローカルに反映させるには 1. git fetch により，リモートリポジトリの変更をローカルリポジトリに取り 込む 2. git merge により，取り込んだリモートリポジトリの変更をカレントブラン チに統合する 32

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

• 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 34

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

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

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の研修資料が公開されています．コードレビューのお作法や ベストプラクティスがまとまっているので，チーム開発をする人は必見です ※ 37

• 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? 38

• 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 を する必要があります． 一方でfeatureブランチで作業中に，リモートリポジトリの main に更新があった 場合には， 39

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 40

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 41

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

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

• 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 brand -D add_dataloader Squash mergeをした場合だと，featureブランチを削除すれば，そこで作られたコ ミットはログで表示されなくなります， git branch –D add_dataloader main main この部分は内部的には保存されたままだが， 到達不能コミットとなりログで表⽰されなくなる ・・・ ・・・ add_dataloader 到達不能コミットはどのブランチからも 辿れないコミットのことを指す．⼀定期間経過すると， 到達不能コミットは gitのガベージコレクションにより消去される． 44

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

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

覚えることが多くて面倒くさそうと思った方へ 正直，いちいち git add とか git commit とか打つのめんどくさいと思うのは普 通だと思います． そこで，第4回：Visual Studio Code (VS Code) を活用した開発でVS Code上の GUIでGit・GitHubの操作を行う方法を教えます．ボタンをぽちぽちするだけで各 種操作ができるのでとっつきやすいと思います． 47

課題 課題内容 自分のPCにDocker Desktopをインストールし，Docker Desktopの画面のスクリー ンショットをSiriusで提出してください．ファイル名は 学籍番号_名前_docker とし てください．スクリーンショットの形式は png , jpeg , pdf のどれかにしてくだ さい 注意事項 ファイル名が正しいか確認すること． 締め切り 日本標準時で次回講義の前日の23:59まで 48

• https://www.docker.com/ja-jp/products/docker-desktop/

Docker Desktopのスクリーンショットの例 49

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

• https://x.com/KokiYamada6