---
title: Git・GitHubの実践 - 人工知能応用特論Ⅰ 第2回
tags: 
author: [Koki Yamada](https://docswell.com/user/2625216247)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/D7YZRVKQJM.jpg?width=480
description: 東京農工大学大学院先進学際科学府の人工知能応用特論Ⅰの第2回資料です．
published: October 17, 25
canonical: https://docswell.com/s/2625216247/KJQVWN-tuat_ais_mlds2
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/D7YZRVKQJM.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/VEN3DMR2E8.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/Y799GNMD73.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/G789VKL5JD.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/L7LW5ZL3ER.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4EM93VMM7W.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/PERGQ2VL79.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/P7XX5DW67X.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/37KW6XVG7D.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LJ3165M5E5.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/8JDXVD6Y7G.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/VEPPVXY2E8.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/27V2ZLGX7Q.jpg)

ローカル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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/5JGR4X8R7L.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/47QVG89YEP.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/KE4M52XZ71.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/L718WMNDJG.jpg)

(補足) .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 &#039;.DS_Store&#039; &gt;&gt; ~/.config/git/ignore
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/G7WZ634872.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4JZ1YV29E3.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/YE6LD5VD7V.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/GE513YD8J4.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/9721ZG8VER.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/DJYZRV6QEM.jpg)

3. ステージングした内容をコミットする
コミットはある時点のプロジェクトの状態（スナップショット）を保存すること
を指します．忘れてしまった人は前回の講義資料を見返しましょう．
コミットは git commit コマンドで実行できます．
git commit -m &quot;add hello.py&quot;
以降の文章はコミットメッセージと呼ばれる，そのコミットを端的に表すメ
ッセージです．コミットのたびにコミットメッセージを書く必要があります．
-m
git log
コマンドによりコミットの履歴を見ることができます．（以下，実行例）
yamadakoki@MacBook-Pro-2021 lecture_git % git log
commit a154ee84bacca201723968c5ba6702cf91cce587 (HEAD -&gt; main)
Author: Koki Yamada &lt;メールアドレスが表示される&gt;
Date:
Mon Oct 13 17:45:41 2025 +0900
add hello.py
commit f7208d83eeb9afbb3ffd32dc49909fbb0120e65f (origin/main, origin/HEAD)
Author: Koki Yamada &lt;メールアドレスが表示される&gt;
Date:
Sun Oct 12 16:41:09 2025 +0900
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/V7N3DMZ278.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/YJ99GNZDJ3.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GJ89VK15ED.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/LJLW5ZQ37R.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/47M93V1MJW.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/P7RGQ2LLJ9.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/PJXX5P66JX.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/3JKW6D1GJD.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/LE316RQ575.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/8EDXVY9YJG.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/V7PPV6Z278.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/2JV2Z3WXJQ.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/5EGR43DRJL.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/4JQVG51Y7P.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/K74M59RZJ1.jpg)

(補足) なぜ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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/LJ18WKQDEG.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/GJWZ6DM8J2.jpg)

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-ﬀ add_dataloader
main
feature
・・・
・・・
add_dataloader
add_dataloader
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4EZ1YGQ973.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/Y76LDY6DJV.jpg)

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


# Page. 43

![Page Image](https://bcdn.docswell.com/page/G7513G68E4.jpg)

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


# Page. 44

![Page Image](https://bcdn.docswell.com/page/9J21ZYMV7R.jpg)

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のガベージコレクションにより消去される．
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/DEYZRGXQ7M.jpg)

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


# Page. 46

![Page Image](https://bcdn.docswell.com/page/VJN3DG12J8.jpg)

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


# Page. 47

![Page Image](https://bcdn.docswell.com/page/YE99GW5DE3.jpg)

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


# Page. 48

![Page Image](https://bcdn.docswell.com/page/GE89VNY57D.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/LELW5P43JR.jpg)

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


# Page. 50

![Page Image](https://bcdn.docswell.com/page/4JM934KMEW.jpg)

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


