Gitのインストールと環境構築 — ローカル環境をゼロから整える

Gitとは何か？バージョン管理の必要性

Gitはソフトウェア開発者のためのバージョン管理システムです。たとえば、あなたが文章を書いている途中で「前のバージョンに戻したい！」となったとき、手動でファイルをコピーしていたら大変ですよね？Gitはこの問題を解決するツールで、コードの変更履歴を記録し、いつでも過去の状態に戻せるようにします。チーム開発では、複数人が同じファイルを同時に編集するリスクを防ぐためにも必須です。

Gitの主な特徴

Gitのインストール手順（Windows/macOS/Linux）

Windowsの場合

1. Git公式サイト（https://git-scm.com）にアクセス
2. 「Download for Windows」をクリックしてインストーラーをダウンロード
3. インストーラーを実行 → すべての設定をデフォルトで進める
4. コマンドプロンプトで git --version と入力し、インストール確認

# インストール確認コマンド
git --version
# 出力例: git version 2.40.0.windows.1

macOSの場合

1. Homebrewをインストール済みであれば、以下のコマンドでインストール

brew install git

1. Homebrewが未インストールの場合、https://brew.sh からインストーラーを取得
2. git --version で確認

Linux（Ubuntu/Debian）の場合

sudo apt update
sudo apt install git
git --version

Gitの基本設定：ユーザー名とメールアドレス

Gitはコミット（変更の記録）にあなたの名前とメールアドレスを記録します。これは「この変更を誰が行ったか」をチームで追跡するために重要です。

# グローバル設定（すべてのプロジェクトで有効）
git config --global user.name "YourName"
git config --global user.email "your.email@example.com"

# 設定確認
git config --global user.name
git config --global user.email

💡 例：チームで開発する場合、設定が間違えると「誰がどのファイルを修正したか」が混乱します。必ず正しい情報を設定しましょう。

リポジトリの作成と初期化

リポジトリ（repo）は、Gitが管理するプロジェクトの単位です。たとえば、あなたのフォルダを「Gitが管理するフォルダ」に変えるための操作が git init です。

実践例：空のプロジェクト作成

# 新しいディレクトリ作成
mkdir my-first-git
cd my-first-git

# Gitリポジトリを初期化
git init
# 出力: Initialized empty Git repository in .../.git/

.git ディレクトリの役割

git init を実行すると、隠しディレクトリ .git が作成されます。ここにすべての履歴や設定が保存されます。このディレクトリを削除すると、プロジェクトのバージョン管理が無効になります。

ブランチの基本と操作

ブランチは、コードの「別の進化ライン」です。たとえば、メインの開発ライン（main）で作業しながら、新機能を開発するためのブランチ（feature-login）を作れます。

ブランチ操作の基本コマンド

# ブランチ一覧（現在のブランチに*がつく）
git branch

# 新しいブランチ作成
git branch feature-login

# ブランチ切り替え
git checkout feature-login

# 作成と切り替えを同時に行う
git checkout -b feature-login

ファイルの追跡とコミット

Gitでは、ファイルの変更を「ステージング」と「コミット」の2段階で管理します。

ステップバイステップ

1. ファイルを作成（例: README.md）
2. 変更をステージング（一時保存）

git add README.md

1. コミット（確定）

git commit -m "Add README file"

📌 -m オプションはコミットメッセージを指定するときに使います。メッセージは変更内容を説明する短い文章が望ましいです。

ファイルのライフサイクル

実践ワーク：ゼロからリポジトリを作成する

目標

• Gitをインストール
• 新しいリポジトリを作成
• 2つのファイルを追加してコミット

手順

1. ターミナルを開き、以下を実行

mkdir my-git-practice
cd my-git-practice
git init

1. 以下の2つのファイルを作成

echo "# My Project" > README.md
touch index.html

1. 変更をステージング

git add README.md index.html

1. コミット

git commit -m "Initial commit with README and HTML"

まとめと次回の準備

本日の学習ポイント

• Gitのインストールと基本設定
• リポジトリの作成とブランチ操作
• ファイルの追跡とコミットの流れ

次回の準備

• リモートリポジトリ（GitHub）との連携
• git push と git pull の使い方
• コンフリクト（競合）の解決方法

🚀 次回は、ローカル環境で作成したプロジェクトをGitHubというクラウド上のリポジトリにアップロードする方法を学びます。準備として、GitHubアカウントの作成をおすすめします。

参考文献

1. 『Pro Git』（Scott Chacon & Ben Straub 著）
   Gitの詳細な仕組みと中級者向けの内容が網羅された定番書籍。
2. Git公式ドキュメント（https://git-scm.com/book/ja/v2）
   公式で信頼性の高い日本語リファレンス。
3. GitHub Learn（https://lab.github.com）
   GitHubの操作とGitの実践的な使い方を学べるインタラクティブな学習サイト。

リポジトリの作成と基本操作 — init・add・commitの使い方

Gitの基本概念：リポジトリとは何か

Gitの世界では、リポジトリ（repository） はプロジェクトの「歴史帳」のような存在です。これは、ファイルの変更履歴を記録し、チームメンバーと共有するためのデジタルな「プロジェクトの本棚」です。たとえば、本棚に本を追加し、ページをめくって過去の内容を確認するように、Gitのリポジトリではファイルの変更履歴を確認できます。

リポジトリを作成するには、git init コマンドを使います。このコマンドは、カレントディレクトリをGitが管理するプロジェクトに変換します。実行すると、.git という隠しフォルダが生成され、ここですべてのバージョン情報が保存されます。

# 新しいプロジェクトディレクトリを作成
mkdir my-project
cd my-project

# Gitリポジトリを初期化
git init

このコマンドを実行すると、以下のような出力が表示されます：

Initialized empty Git repository in /path/to/my-project/.git/

この.gitフォルダは「Gitの脳みそ」であり、コミット履歴や設定情報を保管します。この時点で、このディレクトリはGitの管理下にあるプロジェクトとなりました。

ファイルの追加：addコマンドの使い方

リポジトリにファイルを追加するには、git add コマンドを使います。このコマンドは、ファイルを「ステージングエリア（Staging Area）」に送る役割を持ちます。ステージングエリアは、コミットする変更を一時的に保管する「チェックアウトカウンター」のような存在です。

たとえば、index.html というファイルを作成して、それをステージングエリアに追加するには以下のようにします：

# ファイルを作成
echo "<h1>Hello Git!</h1>" > index.html

# ファイルをステージングエリアに追加
git add index.html

このコマンドは、index.html の変更を「次のコミットに含める」ことを意味します。複数のファイルを一度に追加するには、git add . を使います。ただし、不要なファイル（例：ログファイル）を追加しないよう注意が必要です。

変更の保存：commitコマンドの使い方

ステージングエリアにファイルを追加した後は、git commit コマンドで変更をコミット（commit）します。コミットは、変更を「歴史帳に記録する」行為であり、時間の節点として保存されます。

# 変更をコミット（コミットメッセージは必須）
git commit -m "index.htmlを新規作成"

このコマンドは、-m オプションでコミットメッセージを指定します。コミットメッセージは、変更の目的を簡潔に説明する必要があります。たとえば、「修正しました」よりも「ヘッダーのテキストを修正」の方が具体的で役立ちます。

コミットメッセージのガイドライン： - 何を変更したかを説明する - 大文字で始める - 文の終わりにピリオドをつけない - 例: "Add README.md with project description"

ステータス確認と差分確認

変更が正しくコミットされているかを確認するには、git status と git diff コマンドを使います。

# 現在のステータスを確認
git status

# 変更内容を確認（ステージング前）
git diff

# ステージング後の変更を確認
git diff --cached

git status は、どのファイルが変更されているか、ステージングされているかを一覧表示します。git diff は、変更内容を詳細に表示します。たとえば、index.html の差分を確認したい場合、以下のようになります：

git diff index.html

このコマンドは、ファイルの「変更前 vs 変更後」を表示し、コミット前にミスがないか確認できます。

実践ワーク：シンプルなプロジェクトの作成

以下に沿って、実際にGitの基本操作を試してみましょう：

1. 新しいディレクトリを作成し、git init でリポジトリを初期化
2. index.html と style.css を作成し、git add . でステージング
3. git commit -m "プロジェクトの初期構築" でコミット
4. git status でステータスを確認
5. index.html を編集し、git diff で変更を確認
6. 変更をステージングし、コミット

# ステップ1-3
mkdir my-website
cd my-website
git init
echo "<h1>My Website</h1>" > index.html
echo "body { background: #f0f0f0; }" > style.css
git add .
git commit -m "プロジェクトの初期構築"

# ステップ4-6
echo "<p>Welcome to my site!</p>" >> index.html
git diff index.html  # 差分を確認
git add index.html
git commit -m "ウェルカムメッセージを追加"

まとめと次回の準備

本講では、Gitリポジトリの作成からファイルの追加、コミットまでを学びました。git init でリポジトリを初期化し、git add で変更をステージング、git commit で変更を保存する流れを理解しました。これらのコマンドは、Gitを使う上で最も基本的で重要な操作です。

次回は、「リモートリポジトリとの連携（push・pull・clone）」について学びます。ローカルの変更をGitHubやGitLabなどのサーバーに保存し、チームメンバーと共有する方法を紹介します。準備として、GitHubアカウントの作成をおすすめします。

参考文献

1. 『Pro Git』（Scott Chacon & Ben Straub）
   Gitの公式ガイドで、初心者から上級者まで対応。日本語訳も存在。
2. GitHub公式ドキュメント
   https://docs.github.com/ja
   GitHub特有の機能やワークフローを学ぶのに最適。
3. Atlassian Git入門ガイド
   https://www.atlassian.com/jp/git/tutorials
   操作手順がビジュアルでわかりやすい。
4. Gitの公式ドキュメント
   https://git-scm.com/book/ja/v2
   Gitのコア機能を網羅したリファレンス。

変更履歴の確認と差分表示 — status・diff・logの活用術

前回の講義では、git init、git add、git commitを用いたリポジトリの作成と基本操作を学びました。しかし、チーム開発では単に変更を保存するだけでなく、「誰が」「いつ」「どのような変更をしたか」を正確に把握する必要があります。本講義では、Gitが持つ3つのコマンド——status、diff、log——を通じて、変更履歴の確認と差分表示の実践的な使い方を解説します。これらのコマンドをマスターすることで、コードの変化を可視化し、チームメンバーとの連携をスムーズにすることが可能になります。

1. git statusで作業状況を確認する

git statusは、現在の作業ディレクトリとステージング領域の状態を確認するためのコマンドです。ファイルが「未追跡」「変更済み」「インデックス済み」のいずれに該当するかを一目で把握できます。

実行例

# 新しいファイルを作成し、状態を確認
echo "Hello, Git!" > hello.txt
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        hello.txt

nothing added to commit but untracked files present (use "git add" to track)

この出力から、hello.txtが未追跡（Untracked）であることがわかります。git add hello.txtを実行すれば、ステージング領域に追加され、次回コミットの対象になります。

2. git diffで変更内容を視覚化する

git diffは、未コミットの変更内容を表示するコマンドです。ファイルの差分（diff）を色付きで表示し、具体的に何が変更されたかを確認できます。これは「まだコミットしていない作業中ファイル」や「ステージング領域との差分」を比較するのに最適です。

実行例

# 既存のファイルを編集
echo "Welcome to Git!" > hello.txt
git diff

diff --git a/hello.txt b/hello.txt
index 9d6035f..c2905d2 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1 @@
-Hello, Git!
+Welcome to Git!

-が削除された行、+が追加された行を表しています。この差分を確認して、意図した変更かどうかをチェックできます。git diffは、コミット前に「本当にこれでいいか？」を確認するための重要なステップです。

3. git logでコミット履歴を追跡する

git logは、リポジトリ内のコミット履歴を表示するコマンドです。どのユーザーが、いつ、どのような変更をコミットしたかを確認できます。コミットのハッシュ値（一意のID）やメッセージ、日時が表示されるため、チーム開発でのバージョン管理に不可欠です。

実行例

# 2回のコミットを作成
git add hello.txt
git commit -m "Initial commit"
echo "Goodbye, Git!" > hello.txt
git add hello.txt
git commit -m "Final message"
git log

commit 2a1c3b4e7d8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Mon Jul 1 12:00:00 2024 +0900

    Final message

commit 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
Author: Your Name <your.email@example.com>
Date:   Mon Jul 1 11:55:00 2024 +0900

    Initial commit

git logの出力は、コミットハッシュ（2a1c3b4...）、作者名・メール、日時、メッセージを含みます。この情報は、バグの原因を特定する際や、過去のバージョンに戻す必要があるときに役立ちます。

4. git diffの応用：特定コミットとの差分比較

git diffは、特定のコミットとの差分を比較することも可能です。これにより、過去のバージョンと現在の状態を比較して、変更点を特定できます。

実行例

# 最新コミットとの差分を表示
git diff HEAD~1

diff --git a/hello.txt b/hello.txt
index c2905d2..9d6035f 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1 @@
-Welcome to Git!
+Goodbye, Git!

HEAD~1は「最新コミットの1つ前のバージョン」という意味です。このように、git diffをコミットハッシュやHEADと組み合わせることで、柔軟な差分比較が可能になります。

5. git logのオプション：履歴をよりわかりやすく表示

git logには、履歴を視覚的にわかりやすくするオプションが多数存在します。代表的なものは以下の通りです。

実行例

git log --oneline --graph

* 2a1c3b4 (HEAD -> main) Final message
* 1a2b3c4 Initial commit

--onelineでコミットメッセージを短く表示し、--graphでブランチ構造を視覚化できます。これは複数ブランチでの開発時に特に役立ちます。

実践ワーク

以下を順番に実行し、git status、git diff、git logの使い方を体感してください。

1. 新しいファイルREADME.mdを作成し、git addしてgit commitする。
2. README.mdを編集し、git statusで状態を確認する。
3. git diffで変更内容を表示し、コミットするかどうかを判断する。
4. git logでコミット履歴を確認し、--onelineオプションの効果を確認する。

まとめと次回の準備

本講義では、Gitの変更履歴確認と差分表示のコアコマンド——status、diff、log——について学びました。これらのコマンドを活用することで、チーム開発における変更の透明性を高め、バージョン管理を効率化できます。

次回は「ブランチの作成とマージ」について学びます。git branch、git checkout、git mergeを用いて、複数の開発フローを管理する方法を解説します。準備として、git branchコマンドの基本的な使い方について調べておいてください。

参考文献

1. Pro Git - GitHubの公式ドキュメント
2. 田中 貴之『Git入門』技術評論社（2020年）
3. Atlassian Git ガイド

ブランチ管理の基礎 — create・switch・mergeの実践

ブランチとは？チーム開発における重要な役割

Gitの世界では、ブランチ（branch）は「並行して作業できる道」のような存在です。たとえば、チームで開発しているアプリケーションで、Aさんは新機能の開発を進めている間に、Bさんはバグ修正を行いたいとします。この場合、mainブランチ（プロジェクトの「メインの道」）に直接作業をすると、未完成なコードや修正途中のコードが混ざってしまい、他のメンバーの作業を妨げてしまいます。

ブランチを使うと、mainブランチを「分岐」させて、それぞれが別の道で作業できます。完成したら再びmainブランチに「合流」（merge）させることで、チーム全体の作業をスムーズに進められるのです。

ブランチの作成：git branchとgit switchの使い分け

ブランチの作成方法

ブランチを作成するにはgit branch [ブランチ名]コマンドを使います。たとえば、新機能「ユーザー認証」の開発用ブランチをfeature/authと命名する場合：

# ブランチの作成
git branch feature/auth

# 作成されたブランチを確認
git branch
# 出力例:
#   main
# * feature/auth ← *が現在のブランチを示す

ただし、作成したブランチに自動で移動するにはgit switch [ブランチ名]を使います：

# 作成と同時に移動
git switch -c feature/auth
# または
git switch feature/auth

ブランチ作成の注意点

ブランチの切り替え：git switchの実践

現在の作業状況を保持する仕組み

Gitでは、未コミットの変更がある状態でブランチを切り替えるとエラーになります。これは「途中の作業を別の道に持っていくと混乱する」という考え方からです。たとえば、mainブランチでREADME.mdを編集中にfeature/authに切り替えたい場合：

# エラーになる例
git switch feature/auth
# error: 未コミットの変更があります。

この場合、git stashで変更を一時保存するか、git commitでコミットする必要があります。

# 一時保存（stash）
git stash

# ブランチ切り替え
git switch feature/auth

# 後で戻ってきたら変更を取り戻す
git stash apply

例：複数ブランチでの作業フロー

# mainブランチで作業
git switch main
# 変更をコミット
git add .
git commit -m "mainブランチでの更新"

# 新規ブランチに切り替え
git switch feature/auth
# 新機能の開発を進める

ブランチのマージ：git mergeの基本と注意点

マージの基本手順

ブランチの作業が完了したら、mainブランチに戻ってmerge（マージ）します。たとえば、feature/authの変更をmainに反映する場合：

# mainブランチに移動
git switch main

# ブランチのマージ
git merge feature/auth

マージの成功条件

• 両方のブランチで同じファイルの同じ部分に変更がない場合：自動的にマージが完了します。
• 変更が重複している場合：「マージコンフリクト」が発生し、手動で解決が必要です。

マージコンフリクトの例

# 例: 両方のブランチで`index.html`の同じ行に変更があった場合
<<<<<<< HEAD
<h1>Welcome to Main Branch</h1>
=======
<h1>Welcome to Feature Branch</h1>
>>>>>>> feature/auth

この場合、Gitは<<<<<<<から>>>>>>>で区切り、どちらの変更かを表示します。手動でどちらかを選ぶか、両方を組み合わせて編集します。

ブランチ管理のベストプラクティス

ブランチ命名規則

• 明確な目的を反映する名前を使う（例：feature/, bugfix/, hotfix/）
• 動詞＋名詞の構成が望ましい（例：feature/add-login, bugfix/fix-header）

定期的なmainブランチの更新

feature/authブランチで作業中でも、mainブランチの最新変更を反映するには：

# feature/authブランチでmainブランチをマージ
git switch feature/auth
git merge main

これにより、他のメンバーがmainブランチに追加した変更を事前に確認できます。

実践ワーク

タスク：3つのブランチで作業を進める

1. mainブランチで初期化： bash git init myproject cd myproject echo "Initial content" > README.md git add README.md git commit -m "Initial commit"

2. 新規ブランチを作成し、変更を加える： bash git switch -c feature/auth echo "User authentication feature" >> README.md git add README.md git commit -m "Add auth feature"

3. mainブランチに戻り、マージする： bash git switch main git merge feature/auth

4. 追加のブランチでコンフリクトを誘発： bash git switch -c feature/checkout echo "Checkout functionality" >> README.md git add README.md git commit -m "Add checkout" git switch main echo "Main branch update" >> README.md git add README.md git commit -m "Update main" git switch feature/checkout git merge main # コンフリクト発生 → 手動で解決

まとめと次回の準備

本講義では、Gitのブランチ管理の基本となるcreate, switch, mergeを実践しました。ブランチはチーム開発において「作業の分離と統合」を可能にする重要な仕組みです。特にgit mergeのコンフリクト処理は、現実の開発現場で頻繁に発生するため、しっかり練習しておくことが大切です。

次回の準備

• プルリクエスト（Pull Request）の仕組みについて理解する
• リモートリポジトリとの連携（push/pull）を学ぶ

参考文献

1. 『Pro Git』（Scott Chacon & Ben Straub 著）
   Gitの公式ドキュメントに基づいた詳しい解説書。特に「Branching Workflows」の章がおすすめです。

2. Git公式ドキュメント（https://git-scm.com/book/ja/v2）
   日本語で読める公式ガイドブック。git branchやgit mergeの詳細が記載されています。

3. GitHub Learning Lab（https://lab.github.com）
   GitHubでのブランチ操作をシミュレーションできるインタラクティブな学習サイト。チーム開発のシナリオもカバーしています。

リモートリポジトリとの連携 — clone・push・pullの基本フロー

前回までの講義では、ローカルリポジトリの作成、変更履歴の確認、ブランチ管理の基本を学びました。チーム開発において、これらの操作はローカル環境でのみでは不十分です。実際の開発では、複数の開発者が同じプロジェクトに協力するために「リモートリポジトリ」が必要になります。この講義では、Gitでリモートリポジトリと連携するための基本コマンド（clone・push・pull）について、具体的な例を交えて解説します。

リモートリポジトリとは何か

リモートリポジトリ（Remote Repository）とは、ネットワーク上に存在するバージョン管理用のデータベースです。通常はGitHub、GitLab、Bitbucketなどのクラウドサービスにホストされ、複数の開発者がコードを共有・同期するために使用されます。

例: チーム開発のシナリオ

• 開発者Aがリモートリポジトリを作成し、mainブランチを初期化します。
• 開発者Bがリモートリポジトリをローカルにコピー（clone）します。
• 開発者Bがfeatureブランチを作成し、変更を加えます。
• 開発者Bがローカルの変更をリモートに反映（push）します。
• 開発者Aがリモートの最新変更を自分のローカルに取得（pull）します。

このように、リモートリポジトリは「チームの共有作業台」のような役割を果たします。ローカルリポジトリとリモートリポジトリを連携させることで、開発者の作業が一貫性を保ちながら進みます。

clone: リモートリポジトリの複製

git cloneコマンドは、リモートリポジトリをローカルに完全に複製するためのコマンドです。これは、プロジェクトに初めて参加する開発者がコードベースを取得する際に使用されます。

実行例

# GitHub上のリモートリポジトリを複製
git clone https://github.com/username/example-project.git

• このコマンドは、example-projectというディレクトリを作成し、リモートリポジトリのすべてのファイルと履歴をコピーします。
• 実行後、ローカルの.gitディレクトリにはリモートのURLが記録されます（originというデフォルト名で登録されます）。

注意点

• cloneはリモートのmainブランチをデフォルトで取得します。
• 他のブランチを取得するには、-bオプションを使用します。 bash git clone -b develop https://github.com/username/example-project.git

push: ローカル変更のリモート反映

git pushコマンドは、ローカルリポジトリの変更をリモートリポジトリにアップロードするためのコマンドです。これは「自分の作業をチームに共有する」ための操作です。

実行例

# ローカルの変更をリモートに反映
git push origin main

• originはリモートリポジトリのデフォルト名です。
• mainは対象となるブランチ名です。

フローのステップ

1. 変更のコミット：git addとgit commitでローカルに保存。
2. プッシュ：git pushでリモートに反映。
3. 確認：GitHubなどのWebインターフェースで変更が反映されていることを確認。

エラー対応

• Updates were rejectedエラー：リモートリポジティにローカルと異なる変更がある場合、pullしてマージ後に再試行します。 bash git pull origin main git push origin main

pull: リモート変更のローカル取得

git pullコマンドは、リモートリポジトリの変更をローカルにダウンロードしてマージするためのコマンドです。これは「チームの最新作業を自分の環境に取り込む」ための操作です。

実行例

# リモートの変更をローカルに取得
git pull origin main

• このコマンドはfetch（取得）とmerge（マージ）の2つの操作を組み合わせたものです。
• ローカルに同じ変更が存在しない場合、自動的にマージが実行されます。

シナリオ: コンフリクトの回避

• 2人が同じファイルを変更した場合、pull時にコンフリクトが発生します。
• この場合、Gitは.git/CONFLICTファイルを生成し、手動で解決するよう促します。

clone・push・pullの基本フローまとめ

フローグラフ

[ローカルリポジトリ] ← clone → [リモートリポジトリ]
[ローカルリポジトリ] ← pull → [リモートリポジトリ]
[ローカルリポジトリ] ← push → [リモートリポジトリ]

実践ワーク

演習課題: サンプルプロジェクトで練習

1. リモートリポジトリの作成
2. GitHubに「sample-project」という名前の空リポジトリを作成します。

3. 初期ブランチをmainに設定します。

4. クローンする
   bash git clone https://github.com/your-username/sample-project.git

5. 変更を加える

6. README.mdファイルに「Hello, Git!」と記述します。

7. 変更をコミットします。 bash git add README.md git commit -m "Add initial content"

8. 変更をプッシュする
   bash git push origin main

9. 別の端末でプルする

10. 別のPCやディレクトリでgit cloneし、その後git pullを実行します。

まとめと次回の準備

本講義では、リモートリポジトリと連携するための3つの基本コマンド（clone・push・pull）について学びました。これらのコマンドは、チーム開発において必須のスキルであり、コードの共有と同期を可能にします。特に、pushとpullの組み合わせは、変更の整合性を保つために重要です。

次回は、プルリクエスト（Pull Request）やコードレビューの基本について解説します。プルリクエストは、チームメンバーに変更を承認してもらうための仕組みであり、開発プロセスをより安全にします。準備として、GitHubやGitLabのWebインターフェースにアクセスして、プルリクエストの作成方法を確認しておいてください。

参考文献

1. 『Pro Git（第2版）』（Scott Chacon & Ben Straub 著）
2. Gitの基本から高度なトピックまで網羅した定番書籍。英語版は公式ドキュメントとしても利用可能です。
3. Git公式ドキュメント（https://git-scm.com/book/ja/v2）
4. 日本語で読みやすく、コマンドの詳細な説明が載っています。
5. GitHub公式ドキュメント（https://docs.github.com/ja）
6. GitHub特有の機能（プルリクエスト、コードレビューなど）について学ぶためのリソースです。

チーム開発のためのプルリクエスト — コンフリクト解決の実践

前回の講義で「リモートリポジトリとの連携」を学び、pushやpullを使って他のメンバーとコードを共有する方法を習得しました。今回は、チーム開発において最も重要なプロセスの一つである「プルリクエスト（Pull Request）」に焦点を当てます。特に、複数人が同じファイルを編集した際に発生する「コンフリクト（衝突）」の解決方法を、具体的な実例とステップバイステップの手順で解説します。

1. プルリクエストとは何か？チーム開発における役割

プルリクエスト（PR）は、自分の作業したコードを他のメンバーにレビューしてもらうための仕組みです。GitHubやGitLabなどのプラットフォームで広く利用され、コード品質の向上やチームの協働を促進します。

たとえば、2人が同じファイルを異なるタイミングで編集した場合、一方の変更がもう一方に「上書きされてしまう」可能性があります。このような問題を防ぐために、プルリクエストでは「自分の変更をマージする前に、他のメンバーに確認してもらう」プロセスが組み込まれています。

プルリクエストの基本フロー

1. メインブランチ（例: main）から新しいブランチ（例: feature/login）を分岐
2. 自分のブランチで機能やバグ修正を実装
3. リモートリポジトリに変更をpushしてプルリクエストを作成
4. 他のメンバーがコードをレビューし、問題があれば修正を求められる
5. レビューが通れば、自分の変更がメインブランチにマージされる

# ブランチ作成と切り替え（第2講の内容を復習）
git checkout -b feature/login

# 変更を加えてコミット
git add .
git commit -m "ログイン機能の実装"

# リモートにプッシュ
git push origin feature/login

2. コンフリクトの発生とその原因

コンフリクトは、同じファイルの同じ部分を複数人が異なる内容で編集した場合に発生します。たとえば、2人が同時にindex.htmlのヘッダー部分を変更した場合、Gitは「どちらの変更を優先すべきか」判断できないため、マージに失敗します。

コンフリクトの具体例

# 2人の開発者が同時に`index.html`を編集
# 開発者Aの変更
<h1>ウェルカム！</h1>

# 開発者Bの変更
<h1>ようこそ、私たちのサービスへ！</h1>

# マージ時に発生するコンフリクトの例
<<<<<<< HEAD
<h1>ウェルカム！</h1>
=======
<h1>ようこそ、私たちのサービスへ！</h1>
>>>>>>> feature/login

この状態では、Gitが「どちらの変更を採用すべきか」を自動では決められず、手動で解決する必要があります。

3. コンフリクトの解決方法：git merge vs git rebase

コンフリクト解決には2つの主なアプローチがあります。

方法1: git mergeでマージ

# メインブランチの最新コードを取得
git checkout main
git pull origin main

# 作業ブランチに戻り、マージを試行
git checkout feature/login
git merge main

• メリット: マージ履歴が明確に残る
• デメリット: コンフリクトが発生した場合、手動で解決が必要

方法2: git rebaseで変更を適用

# 作業ブランチでrebaseを実行
git checkout feature/login
git rebase main

• メリット: コンフリクトを「直近の変更に合わせる」形で解決
• デメリット: リベース後のコミット履歴が変更されるため、注意が必要

4. コンフリクト解決の手順：ステップバイステップ

以下は、コンフリクトが発生した際の解決プロセスです。

1. コンフリクトの確認
   GitがCONFLICTと表示し、<<<<<<<, =======, >>>>>>>の記号で変更部分を囲みます。

2. 変更内容の確認と編集
   以下のように、ファイルを開いてどちらの変更を採用するか手動で選択します。 ```html

ようこそ、私たちのサービスへ！（ウェルカム！）

```

1. 変更をコミット
   bash git add index.html git commit -m "コンフリクトを解決"

2. プルリクエストの再送信
   GitHubやGitLabのインターフェースで、解決済みの変更を再送信します。

5. コンフリクトを防ぐためのベストプラクティス

• 頻繁にgit pullを実行する
  メインブランチの最新コードを定期的に取得することで、コンフリクトを早期に発見できます。

• 小さな単位の変更を実装する
  1つのプルリクエストで複数の機能を実装すると、コンフリクトの可能性が高まります。

• コードレビューを活用する
  他のメンバーに早期にレビューを依頼し、問題を早期に修正します。

実践ワーク

演習課題: 2人の開発者のコンフリクトを解決

1. 環境構築
   bash git init conflict-demo cd conflict-demo touch index.html git add index.html git commit -m "Initial commit"

2. ブランチ分岐と変更

3. Aさん: feature/aブランチでindex.htmlの<h1>タグを変更

4. Bさん: feature/bブランチで同じ<h1>タグを異なる内容に変更

5. コンフリクトの再現
   bash git checkout feature/a git merge feature/b

6. コンフリクト解決
   ファイルを開いて両方の変更を統合し、git addとgit commitで解決します。

まとめと次回の準備

本講義では、プルリクエストの基本フローとコンフリクトの解決方法について学びました。チーム開発においては、変更履歴の明確さとコミュニケーションが不可欠です。特に、コンフリクトは避けることのできない現実として、正しい対処法を身につけることが重要です。

次回の準備

• 第7講: Gitのアドバンス運用 — タグ管理とリリースフロー
  リリースバージョンの管理や、複数環境での開発フローについて学びます。

参考文献

1. 『Pro Git（第2版）』 - Scott Chacon & Ben Straub（公式ドキュメントの日本語訳も存在）
   Gitの基本操作からアドバンスな技術まで、網羅的な解説がされています。

2. GitHub公式ドキュメント - https://docs.github.com/
   プルリクエストやコンフリクト解決の手順が詳細に記載されています。

3. GitLab公式ガイド - https://docs.gitlab.com/
   GitLab特有の機能（例: Merge Request）やワークフローについて学べます。

進階操作の活用 — rebase・cherry-pick・stashの使い分け

前の講義で学んだ「ブランチのマージ」や「プルリクエストのコンフリクト解決」は、チーム開発において基本となるスキルです。しかし、実際の開発では、「複数の変更を整理する」や「一時的に作業を保存する」といったニッチな操作が必要になる場面があります。本講義では、Gitの進階操作として、rebase（リベース）、cherry-pick（チェリーピック）、stash（スタッシュ）の3つのコマンドを解説します。これらは、開発の柔軟性を高めるための「武器」です。それぞれの使い分けと活用例を具体的に学んでいきましょう。

rebase: ブランチの履歴を整理する

rebaseは、「ブランチの履歴を再構成する」コマンドです。通常、mergeでは2つのブランチの変更を分岐状態に保持したまま結合しますが、rebaseは「変更を再適用する」ことで、線形な履歴を作成します。

使用例: メインブランチの最新変更を反映

# developブランチに切り替え
git checkout develop

# mainブランチの最新変更をdevelopブランチに適用
git pull origin main

# 自分の特徴ブランチ（feature-branch）に切り替え
git checkout feature-branch

# mainブランチの変更を「再適用」して履歴を整理
git rebase main

なぜ使うか？

• 履歴の可読性向上: 分岐が複雑になるのを防ぎ、コミット履歴が直線的になる
• プルリクエストの整理: レビュー時に「不要な中間コミット」を排除できる

注意点

• 履歴を書き換えているため、push後に他人に共有したブランチでは使用しない（rebase後に履歴が変化し、混乱を招く）

cherry-pick: 特定のコミットを適用する

cherry-pickは、「他のブランチにある特定のコミットをコピーして適用する」コマンドです。たとえば、バグ修正を特定のブランチに適用したい場合に役立ちます。

使用例: バグ修正コミットの適用

# mainブランチに切り替え
git checkout main

# developブランチのコミット履歴を確認
git log develop

# コミットハッシュ（例: abc1234）を確認後、mainブランチに適用
git cherry-pick abc1234

なぜ使うか？

• 特定の変更のみ反映したい場合（例: 本番環境への緊急修正）
• 複数のブランチ間で変更を分離したい場合

注意点

• コミットの履歴が複製されるため、履歴の「同一性」が保てない（例: 同じ修正が複数のブランチに存在）

stash: 一時的な変更保存

stashは、「未コミットの変更を一時的に保存・復元する」コマンドです。たとえば、現在の作業を保存して別のタスクを処理する場合に便利です。

使用例: 一時的な変更の保存と復元

# 未コミットの変更を保存
git stash save "CSS調整の途中変更"

# 他のブランチに切り替えて作業
git checkout develop
# 作業終了後、元のブランチに戻る
git checkout feature-branch

# 保存した変更を復元
git stash apply

なぜ使うか？

• 作業を中断した場合に、状態を保存できる
• 複数の作業を同時に処理する際の効率化

よく使うコマンド一覧

実践ワーク: 3つのコマンドを組み合わせる

シナリオ
あなたは以下のような状況にいます： 1. feature-branchで作業中だが、一時的にmainの最新変更を反映したい 2. developブランチに存在するバグ修正コミットをmainに適用したい 3. 未コミットの変更を保存して別のブランチで作業したい

解決手順

1. rebaseでmainの変更を反映
2. cherry-pickでバグ修正コミットを適用
3. stashで変更を保存・復元

# 1. rebaseで履歴整理
git checkout feature-branch
git pull origin main
git rebase main

# 2. cherry-pickでバグ修正適用
git checkout main
git cherry-pick abc1234  # バグ修正コミット

# 3. stashで変更保存
git checkout develop
git stash save "途中のCSS調整"
# 作業終了後
git stash apply

まとめと次回の準備

本講義では、Gitの進階操作として以下の3つのコマンドを学びました： - rebase: 履歴を直線的に整理（作業中のブランチ用） - cherry-pick: 特定コミットをコピー（分離した変更適用用） - stash: 一時保存（作業中断時の利用）

これらを活用することで、チーム開発における柔軟性が大きく向上します。次回は「Gitのトラブルシューティングとトラブル回避策」について学びます。履歴の破損や誤った操作を回避する方法を解説しますので、ぜひお楽しみに。

参考文献

1. 「Pro Git」（Scott Chacon & Ben Straub）: Gitの公式な教科書で、rebaseやcherry-pickの詳細な説明がある
2. Git公式ドキュメント: https://git-scm.com/book/ja/v2
3. 「Git入門ガイド」（Atlassian）: 図解入りでstashの使い方を解説した記事あり

コミットの修正と元に戻す — amend・reset・revertのテクニック

チーム開発では、コミットの誤りや不要な変更に気づくことがあります。この講義では、Gitでコミットを修正したり、変更を元に戻すための3つのテクニック（amend、reset、revert）を詳しく解説します。第3講で学んだrebaseやcherry-pickと同様、これらはリポジトリの状態を柔軟に操作するための重要なツールです。

1. コミットの修正：git commit --amendの使い方

コミットは「変更点の記録」と考えるとわかりやすいです。たとえば、ファイルを編集してgit commitすると、その変更が履歴として保存されます。しかし、コミット後に「ファイルを忘れた」「メッセージを修正したい」と気づいた場合があります。

実例：コミットメッセージの修正

# 1. 変更を加えたファイルをステージ
$ git add README.md

# 2. 修正前のコミットメッセージ（例: "Add README"）
$ git commit -m "Add README"

# 3. メッセージを修正する（例: "Add README and LICENSE"）
$ git commit --amend -m "Add README and LICENSE"

注意点

• amendは直近のコミットのみを修正できます。
• 修正後のコミットは新しいハッシュ値を持つため、リモートリポジトリにpush済みの場合は--forceが必要です（リスクが伴うので、チーム内で共有されたコミットには使わないようにしましょう）。

2. コミットの削除・戻し：git resetの3つのモード

git resetは、コミットの履歴を「消す」か「戻す」かを決められるコマンドです。3つのモードがあります。

モードの比較表

実例：不要なコミットを削除

# 1. 仮に3つのコミットがあるとする（HEAD -> C3 -> C2 -> C1）
$ git log --oneline
abc1234 (HEAD -> main) C3: Add new feature
def5678 C2: Fix bug
ghi90ab C1: Initial commit

# 2. C3を削除し、C2を最新に（HEAD -> C2）
$ git reset --mixed def5678

注意点

• --hardは変更を永久に削除するため、実行前には必ずgit statusで確認しましょう。
• 共有されたリポジトリではresetを使わない（履歴を書き換えるリスク）。

3. 安全な元に戻し：git revertの活用

revertは、コミットを「無効化する」新しいコミットを作成します。これは、履歴を書き換えることなく、変更を元に戻すための安全な方法です。

実例：不適切なコミットを無効化

# 1. 悪影響のあるコミット（例: C2）を特定
$ git log --oneline
abc1234 (HEAD -> main) C3: Add new feature
def5678 C2: Add broken code
ghi90ab C1: Initial commit

# 2. C2を無効化する新しいコミットを生成
$ git revert def5678

結果

• revertは新しいコミットを追加し、履歴を変更しません。
• 他の開発者と共有されたコミットにも安全に適用できます。

4. それぞれのコマンドの使い分け

実践ワーク

ステップ1：コミットを修正する

1. ファイルexample.txtを作成し、git addとgit commitでコミットする。
2. 修正前のメッセージを"Initial commit"、修正後のメッセージを"Add example.txt"に変更する。

$ echo "Hello Git" > example.txt
$ git add example.txt
$ git commit -m "Initial commit"
$ git commit --amend -m "Add example.txt"

ステップ2：resetで状態を戻す

1. 新しいコミットを追加（例: "Add README"）。
2. git reset --mixed HEAD~1で直近のコミットを削除し、ファイルをワークツリーに残す。

$ echo "Project setup" > README.md
$ git add README.md
$ git commit -m "Add README"
$ git reset --mixed HEAD~1

ステップ3：revertで無効化する

1. README.mdを変更し、コミットする。
2. git revertで変更を無効化する新しいコミットを生成。

$ echo "Updated content" > README.md
$ git add README.md
$ git commit -m "Update README"
$ git revert HEAD

まとめと次回の準備

• amendは未共有のコミット修正に、resetは注意深く、revertは共有リポジトリで安全に使用しましょう。
• 次回は「ブランチ管理の進階」について学びます。特に、mergeとrebaseの違いや、チーム開発におけるベストプラクティスを解説します。

参考文献

1. 『Pro Git』（Scott Chacon & Ben Straub著）: Gitの基本と中級テクニックが網羅された定番書籍。
2. GitHub公式ドキュメント: Reverting Commits
3. Atlassian Git Tutorials: Understanding Git Reset

ワークフロー設計とベストプラクティス — Git Flowの導入

前回までで、プルリクエストの活用やコミット操作の修得を学びました。今回はチーム開発におけるGitワークフローの設計に焦点を当て、特にGit Flowという代表的なモデルを詳しく解説します。Git Flowはリリース管理を効率化するための分岐戦略で、複数人の開発者が協力してプロジェクトを進める際に非常に役立ちます。

Git Flowとは？チーム開発のための分岐戦略

Git FlowはVincent Driessen氏が提唱した、プロジェクトのライフサイクルに沿った分岐管理モデルです。基本的な分岐構造は次の通りです：

このモデルでは、各ブランチが明確な役割を持つことで、チームメンバーが混乱なく作業できます。たとえば、feature/loginブランチでログイン機能を開発中に、他のメンバーがfeature/paymentで決済機能を同時に開発できます。

Git Flowの基本手順：5ステップでプロジェクトを進める

Git Flowのワークフローは次の5ステップで構成されます：

1. フィーチャーブランチの作成と開発

新機能やバグ修正を始めるには、developブランチから分岐します。以下が具体的なコマンドです：

# developブランチに移動
git checkout develop

# 新しいフィーチャーブランチを作成（例: ログイン機能）
git checkout -b feature/login

# 変更をコミット
git add .
git commit -m "ログイン機能の実装"

この段階では、他の開発者の作業に影響を与えずに、自由にコードを書くことができます。

2. フィーチャーのdevelopへのマージ

機能が完成したら、developブランチへマージします。プルリクエスト（Pull Request）を通じてコードレビューを行うのがベストプラクティスです：

# developブランチに戻る
git checkout develop

# フィーチャーブランチの変更をマージ
git merge feature/login --no-ff

# ブランチを削除（必要に応じて）
git branch -d feature/login

--no-ffオプションは、マージを明確に記録し、履歴が見やすくなるようにします。

3. リリースブランチの作成と調整

リリース準備として、developからreleaseブランチを分岐します。この段階でバージョン番号を更新したり、最終的なテストを行います：

# developブランチからリリースブランチを作成
git checkout -b release/1.0 develop

# バージョン番号を変更（例: package.json）
git add .
git commit -m "バージョン1.0リリース準備"

このブランチでは、コードの変更は最小限にし、主に調整やテストに集中します。

4. リリースのmainへのマージとdevelopへの統合

リリースが完了したら、mainブランチにマージし、developにも変更を反映します：

# mainブランチにリリースブランチをマージ
git checkout main
git merge release/11.0 --no-ff

# developブランチにも変更を統合
git checkout develop
git merge release/1.0 --no-ff

これにより、mainには本番環境向けのコードが、developには次の開発用の最新コードが保たれます。

5. 緊急修正のhotfixブランチ

本番環境で問題が発生した場合、mainからhotfixブランチを分岐します。例として、セキュリティホールの修正：

# mainブランチからhotfixブランチを作成
git checkout -b hotfix/security main

# 修正をコミット
git add .
git commit -m "セキュリティホールの修正"

# mainとdevelopにマージ
git checkout main
git merge hotfix/security --no-ff
git checkout develop
git merge hotfix/security --no-ff

このプロセスにより、即時修正が可能でありながら、developブランチにも変更が反映されます。

Git Flowのメリットと注意点

Git Flowはチーム開発のスケーラビリティを高める強みがありますが、いくつかの注意点もあります：

• メリット:
• リリース管理が明確で、品質向上に貢献
• 並列開発を可能にし、複数の機能を同時に進められる

• 緊急修正を迅速に反映できる

• 注意点:

• 分岐数が多くなるため、管理が複雑になる可能性
• リリース間隔が短いプロジェクトには重くなる
• GitHub FlowやTrunk-Based Developmentなど、代替ワークフローも存在

たとえば、Agile開発ではリリース頻度が高いため、Git FlowよりもGitHub Flow（常時デプロイ）が適している場合があります。ワークフローの選択はプロジェクトの性格に応じて行う必要があります。

実践ワーク：Git Flowを体験する

以下のシナリオを元に、Git Flowを実際に使ってみましょう：

1. プロジェクトの初期化: bash git init my-project cd my-project touch README.md git add README.md git commit -m "Initial commit"

2. developブランチの作成: bash git checkout -b develop

3. 新機能の開発:

4. feature/timerブランチを作成し、カウントダウンタイマー機能を実装

5. developブランチへマージ

6. リリースの準備:

7. release/1.0ブランチを作成し、バージョン番号を更新

8. テストコードを追加してmainブランチへマージ

9. 緊急修正の実行:

10. hotfix/typoブランチを作成し、README.mdの誤字を修正
11. mainとdevelopブランチへマージ

この実践を通じて、Git Flowの各ステップがどのように機能するかを理解できます。

まとめと次回の準備

Git Flowは、複数人の開発者が協力してプロジェクトを進めるための強力なツールです。分岐の役割を明確にし、リリース管理を効率化することで、チームの生産性を高めることが可能です。ただし、プロジェクトの規模やリリース頻度に応じて最適なワークフローを選びましょう。

次回は、Git Flowの代替として広く使われているGitHub Flowについて学びます。より軽量なワークフローの特徴と、Git Flowとの比較を通じて、自分たちのチームに最適な選択を検討していきます。

参考文献

1. Pro Git（Scott Chacon, Ben Straub）
2. Gitの基本と高度な技術を網羅した定番書籍。Git Flowの詳細な説明が含まれます。
3. GitHub Flow: A Simple Git Workflow for Continuous Delivery（GitHub公式ドキュメント）
4. GitHub Flowの導入方法とメリットがわかりやすく解説されています。
5. Git and GitHub for Beginners（Marko Tadić）
6. 初心者向けに、Gitワークフローの選定方法を丁寧に説明しています。

実際の開発環境でのGit活用 — サンプルプロジェクトでの実践演習

サンプルプロジェクトの概要と目的

本講義では、チーム開発でGitを活用する実際のフローを学習します。具体的には、シンプルなタスク管理アプリケーションを題材に、以下を実践します。

• ブランチ管理（Git Flowに基づく）
• コンフリクトの解決
• メージュ戦略の選択
• リモートリポジトリとの連携

目的: これまで学んだrebaseやcherry-pick（第1講）、amendやreset（第2講）、Git Flow（第3講）の知識を、実際のプロジェクトに応用できるようになります。

開発環境のセットアップ

1. プロジェクトの初期化

まず、ローカルにプロジェクトを用意します。以下はNode.jsプロジェクトの例です。

# リポジトリの作成と初期化
mkdir task-manager
cd task-manager
git init

2. 初期コミットの作成

# READMEファイルを作成
echo "# タスクマネージャー" > README.md
git add README.md
git commit -m "Initial commit: README作成"

3. リモートリポジトリとの連携

GitHubやBitbucketなど、好きなサービスでリモートリポジトリを作成し、連携します。

# リモートの設定
git remote add origin https://github.com/your-username/task-manager.git
git push -u origin main

フィーチャーブランチでの開発

Git Flowでは、developブランチをベースにfeatureブランチを分岐します。以下は具体的な手順です。

1. フィーチャーブランチの作成

# developブランチを取得し、その上にfeatureブランチを作成
git checkout -b feature/add-task develop

2. 実装とコミット

add-task機能を追加します。以下はJavaScriptの例です。

// index.js
const tasks = [];

function addTask(task) {
  tasks.push(task);
  console.log("タスクが追加されました:", task);
}

addTask("宿題をやる");

# 変更をコミット
git add index.js
git commit -m "Feature: addTask関数実装"

3. リモートにプッシュ

git push origin feature/add-task

コンフリクトの解決

2人以上の開発者が同じファイルを編集した場合、コンフリクトが発生します。以下は解決手順です。

1. コンフリクトの再現

# 2人の開発者が同じファイルを編集
# 開発者A
git checkout -b feature/delete-task develop
echo "function deleteTask(id) { ... }" > index.js
git commit -am "Feature: deleteTask関数実装"

# 開発者B
git checkout feature/add-task
echo "function updateTask(id, newTask) { ... }" > index.js
git commit -am "Feature: updateTask関数実装"

2. メージュ時のコンフリクト

# 開発者Aがdevelopにマージ
git checkout develop
git merge feature/delete-task

# 開発者Bがdevelopにマージを試みるとコンフリクト
git checkout feature/add-task
git merge develop

コンソールに以下のようなメッセージが表示されます。

Auto-merging index.js
CONFLICT (content): Merge conflict in index.js

3. 手動での解決

index.jsを開き、以下のように編集します。

<<<<<<< HEAD
function updateTask(id, newTask) { ... }
=======
function deleteTask(id) { ... }
>>>>>>> develop

<<<<<<<と>>>>>>>の間のコードを整合性のあるものに修正します。

# 解決後、コミット
git add index.js
git commit -m "Conflict resolved: addTaskとdeleteTaskを統合"

メージュ戦略とベストプラクティス

メージュ戦略の比較

ベストプラクティス

1. rebaseでブランチを更新
   developブランチの最新を反映する際、rebaseを使用します。

bash git checkout feature/add-task git pull --rebase origin develop

1. --no-ffオプションでマージ
   マージ時に直列化を防ぎ、履歴を明確にします。

bash git merge --no-ff feature/add-task

1. amendでコミットの修正
   コミットメッセージや内容を修正する際、--amendを使用します。

bash git commit --amend -m "修正: タスク追加機能の説明を追記"

実践ワーク

タスク: バグ修正とマージ

1. バグの再現
   index.jsに意図的にバグを埋め込みます。

javascript function addTask(task) { tasks.push(task); // タスクを追加 console.log("タスクが追加されました:", task); } addTask("バグを修正する"); // 実行時にundefinedが出力される

1. バグ修正ブランチの作成
   bugfix/undefined-taskブランチを作成し、addTask関数を修正します。

bash git checkout -b bugfix/undefined-task # index.jsを修正 git commit -am "Bugfix: タスク名を正しく出力するように修正"

1. developへのマージ
   developブランチにマージし、mainブランチにリリースします。

bash git checkout develop git merge bugfix/undefined-task git checkout main git merge develop

まとめと次回の準備

本講義では、以下を学びました。

• フィーチャーブランチでの開発フロー
• コンフリクトの解決手順
• メージュ戦略の選択とベストプラクティス

次回の準備:
- GitHubやGitLabなどのクラウドリポジトリサービスの基本操作を確認 - git rebaseとgit mergeの違いを再確認（第1講）

参考文献

1. Pro Git (2nd Edition)
   Gitの基本から進階までを網羅した定番書籍。
2. GitHub Documentation: Using Git
   GitHub公式ドキュメントで、チーム開発向けのGitの使い方が解説。
3. Git入門: チーム開発のためのバージョン管理
   日本語で書かれたGitの入門書。チーム開発向けのワークフローが詳しく解説。