第08章 Git・共同開発（初心者向け改訂版）

この章の読み方： 本文の基本説明、直後の発展解説、例題、演習の順に読んでください。専門用語は初めて出てきた箇所で意味を確認し、コードの予想結果を考えてから実行します。

章末の演習は、それまでの本文の内容を使って解けるように設計しています。

用語の表記： 全10章共通の用語集 と表記を揃えています。

対象：プログラミング未経験者と他言語経験者。環境：Windows 11・Git for Windows・PowerShell。クラウド不要。

学習の順番：準備 → 初回コミット → 差分確認 → ブランチ → マージ → 競合の再現と解消 → 模擬共同開発 → Gitコマンドで履歴確認 → 復旧演習。

独学演習： 学んだ内容の確認には、第08章の実行予想・段階別ヒント・自己チェックを使ってください。本文の説明を読んだあと、自分で出力を予想してから試します。

00. はじめに：この章でできるようになること

Gitはプログラムの変更を履歴として残すソフトウェアです。複数人で同じプログラムを変更するとき、単にファイルをメールで送り合うと、どれが最新版か分からなくなります。

Gitを使えば、誰がどの変更を記録したかを調べ、別々に進めた作業を統合できます。

この章ではインターネット接続、GitHubアカウント、クラウドサービスを使用しません。自分のWindows PCだけで2人の開発者を模擬します。

前の章で学んだ商品管理を題材に、READMEに記載する仕様の変更をチームで統合します。Javaの実行は不要です。

学習到達目標は、(1)安全な場所で初回コミット、(2)差分の説明、(3)ブランチの統合、(4)コンフリクトの意図的な再現と解消、(5)別の作業者とのpush/pull、(6)Gitコマンドで履歴と差分の確認、(7)誤操作時の非破壊的な復旧、の7つです。

目安6～9時間。操作を理解できなければ時間より確認を優先してください。

注意： git restore、git reset --hard、git clean -fd、push --force は作業を失う可能性があるため、この章では実行しません。

実務のリポジトリでは演習しないでください。コマンドはPowerShell向けです。画面表示や改行は環境により多少異なります。

この節の独学チェック：00. はじめに：この章でできるようになること

確認問題： Git学習の到達目標として「変更を安全に管理する」とは何をすることですか。

取り組み方： 解答を見る前に自分の答えを記録してください。

01. 準備する道具と作業場所

Windows 11でスタートメニューを開き、「PowerShell」と入力してWindows PowerShellまたはPowerShellを開きます。一般ユーザー権限で構いません。

git --version と入力し、git version 2.x.x のような表示があれば準備完了です。

「git が見つからない」と表示された場合はGit for WindowsのインストールとPATHを第01章の説明に従って確認し、ターミナルを開き直します。

git --version
$HOME

$HOME は現在のユーザーのホームフォルダーです。これ以降の練習ファイルは $HOME\java-git-training-08 に限定します。**同名の既存フォルダーがあれば上書きしないでください。

** 次のコマンドで存在を確認します。

Test-Path "$HOME\java-git-training-08"

False なら新規作成できます。True なら過去の学習結果があるため、末尾に -2 などを付けて本教材のコマンド中の作業ディレクトリをすべて置換してください。確認しないまま削除してはいけません。

New-Item -ItemType Directory "$HOME\java-git-training-08" | Out-Null
Set-Location "$HOME\java-git-training-08"
Get-Location

以後、別の章や職場のフォルダーで実行しないため、開始時に Get-Location で現在地を確認します。

この節の独学チェック：01. 準備する道具と作業場所

確認問題： 作業用リポジトリを配置する場所は、別の実習と混在していてよいですか。

取り組み方： 解答を見る前に自分の答えを記録してください。

02. ファイル・リポジトリ・コミット・ブランチとは

ファイルはソースコードや説明文そのものです。作業ツリーは実際に編集しているファイル群です。リポジトリはGitが変更履歴を管理する単位で、通常は .git という隠しフォルダーを持ちます。

.git を手動で編集しません。

コミットは選んだ変更を履歴として保存した記録です。撮影した写真のように、後から時点を追えます。ただしGitは一般的なPC全体のバックアップではありません。

コミットしていない変更やGitの管理対象外のファイルは保護されません。

ステージは「次のコミットに何を入れるか」を準備する場所です。git add は保存完了ではなくステージへの登録で、git commit で初めて履歴になります。

作業ファイルを編集
      │ git add
      ▼
ステージ（次に記録したい内容）
      │ git commit
      ▼
ローカルの履歴（コミット）
      │ git push（共有先があるとき）
      ▼
共有リポジトリの履歴

ブランチはコミット履歴の先端を指す名前で、作業を分岐させるために使います。通常は安定した main を残し、機能追加を feature/... で進めます。

マージは別ブランチの変更を現在のブランチへ統合する操作です。意図的に競合を起こす演習は第07節にあります。

この節の独学チェック：02. ファイル・リポジトリ・コミット・ブランチとは

確認問題： Gitのリポジトリとコミットは何が違いますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

図解：Gitの三つの領域

図の読み方：git addは変更をステージし、git commitは履歴として記録します。

03. 新しいリポジトリを作り最初のコミット

先ほど作成した練習用親フォルダーにいることを確認し、次を1行ずつ実行します。

New-Item -ItemType Directory project | Out-Null
Set-Location project
git init -b main
git config user.name "Training Student"
git config user.email "student@example.invalid"
'# 商品管理練習' | Set-Content -Encoding utf8 README.md
git status

git init -b main は現在のフォルダーをGitで管理し、最初のブランチ名を main にします。Gitのバージョンが古く -b が使えない場合はGitを更新してください。

git config を --global なしで設定するとこの練習リポジトリ内だけの名前になります。名前は履歴の表示に使用します。メールは実際に送信されません。

git status に Untracked files: README.md のように表示されたら、まだGitがそのファイルを履歴に含めていない状態です。

git add README.md
git diff --cached
git commit -m "docs: 商品管理の説明を登録"
git status
git log --oneline

git diff --cached はステージにある変更を確認します。git commit -m は短い説明を付けて履歴を記録します。

成功するとコミットの英数字IDが表示され、git status は working tree clean と表示されます。IDは毎回異なっていて正常です。

この節の独学チェック：03. 新しいリポジトリを作り最初のコミット

確認問題： git initの後、変更を記録するまでの代表的な手順は何ですか。

取り組み方： 解答を見る前に自分の答えを記録してください。

04. 変更差分を確認してコミットする

説明文を一行追加してみます。

'商品を一覧表示する' | Add-Content -Encoding utf8 README.md
git diff
git status
git add README.md
git diff --staged
git commit -m "docs: 一覧表示の仕様を追記"
git log --oneline -2

git diff はステージに載せていない変更を表示し、git diff --staged はステージ済みの変更を表示します。先頭に + の付いた行は追加、- の付いた行は削除です。

記号自体はファイルの内容ではありません。変更する前と後の内容を読み、想定外のファイルが混ざっていないことを確認してからコミットします。

経験者向け補足：一つのコミットには原則一つの目的を持たせます。機能修正と無関係な整形を混ぜないとレビューと切り戻しが容易です。

理解を深める：なぜ変更を小さくコミットするのか

一つのコミットに「商品名変更・割引率修正・ログ整形」をまとめると、割引の不具合だけを調べたいときに差分が読みにくくなります。変更の目的ごとにまとまったコミットにしておけば、レビューや原因調査が容易になります。

反対に1行ごとに機械的に分けすぎても、意図が伝わりにくくなります。

理解を深める：コミットは変更内容と意図を後から確認するための記録にもなる

コミットは、ある時点の変更を履歴として説明可能な形で残すものです。たとえば「商品名の検索条件を修正」と「画面全体の色を変更」を同じコミットにすると、不具合が起きたときに片方だけを検討しにくくなります。

意味のまとまった小さなコミットにしておくと、変更の理由を後から追いかけやすくなります。

この節の独学チェック：04. 変更差分を確認してコミットする

確認問題： git diffとgit statusは何を確認しますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

05. ブランチを作って統合する

この節では main の既存作業を壊さず新しい説明を加えます。

git switch -c feature/stock
'在庫数を表示する' | Add-Content -Encoding utf8 README.md
git add README.md
git commit -m "docs: 在庫表示を追加"
git switch main
git merge feature/stock
git log --graph --oneline --all
git status

git switch -c は新しいブランチの作成と切り替えを同時に行います。git switch main で元へ戻り、git merge feature/stock でその変更を取り込みます。

今回は途中で他の変更がないため Fast-forward と表示される場合があります。新しいマージコミットが作られなくても正常です。README.md に在庫表示の一行があることも確認してください。

理解を深める：なぜ作業ブランチを使うのか

新しい機能の作業途中でmainの動作を壊さないようにするためです。作業ブランチで変更・テストを行い、確認後に統合します。ブランチは「完成するまで誰にも見せない場所」ではありません。チームでは共有・レビューする単位としても使います。

理解を深める：なぜブランチを分けるのか

共有の main に作業途中のコードを直接追加すると、別の担当者が未完成の変更を受け取る可能性があります。機能ごとのブランチで作業すると、レビューや確認が済んでから統合できます。

ただしブランチは完全な安全装置ではなく、コミットしていない変更や誤った操作には注意が必要です。

この節の独学チェック：05. ブランチを作って統合する

確認問題： mainを変更せずに新機能を実装するには何を使いますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

図解：ブランチとマージ

図の読み方：ブランチで作業を分離し、マージで変更を統合します。

06. .gitignore と秘密情報の取り扱い

Mavenの target/、一時ファイル、パスワード、APIキーなどを無条件でコミットしてはいけません。.gitignore は未追跡ファイルをGitの候補から外す設定です。

追跡済みの秘密を安全に消去する機能ではありません。

@('target/','*.log') | Set-Content -Encoding utf8 .gitignore
New-Item -ItemType Directory target | Out-Null
'作成されたファイル' | Set-Content -Encoding utf8 target\generated.txt
git status --short
git add .gitignore
git commit -m "chore: 生成物をGitの対象外に設定"
git status

git status --short に target/generated.txt が出ないことを確かめます。実務のリポジトリでは、秘密情報を誤ってコミットした場合に履歴から単純削除するだけでは不十分です。

速やかに管理者へ報告し認証情報を無効化します。

この節の独学チェック：06. .gitignore と秘密情報の取り扱い

確認問題： .gitignoreにパスワードを追加すれば既にコミットした秘密も消えますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

07. コンフリクトをわざと発生させる

コンフリクトは、別々のブランチで変更した部分をGitが安全に一つへまとめられない状態です。ここでは同じ行を異なる文章に変更します。必ず project の中で実行してください。

'商品状態: 未設定' | Set-Content -Encoding utf8 conflict.txt
git add conflict.txt
git commit -m "docs: 競合練習の基準行を追加"
git switch -c feature/status
'商品状態: 販売中' | Set-Content -Encoding utf8 conflict.txt
git add conflict.txt
git commit -m "docs: 機能側で状態を設定"
git switch main
'商品状態: 在庫確認中' | Set-Content -Encoding utf8 conflict.txt
git add conflict.txt
git commit -m "docs: main側で状態を設定"
git merge feature/status

最後の git merge は、この教材では失敗することが正解です。CONFLICT (content) と表示されても作業をやめず、次の手順へ進みます。

git status を実行すると both modified: conflict.txt のように出ます。

Get-Content conflict.txt
git status

ファイルには次のようなマーカーが入ります（実際のコミットIDやラベルは異なります）。

<<<<<<< HEAD
商品状態: 在庫確認中
=======
商品状態: 販売中
>>>>>>> feature/status

この例の <<<<<<< HEAD 側はマージを実行した現在のブランチ（main）の内容、======= の下は取り込む側の feature/status の内容です。

競合マーカーの表示はマージやrebaseなどの操作で異なるため、ラベルを確認してから判断します。どちらが正しいかはGitでは判断できません。

演習の仕様は「両方の情報を残し、商品状態: 販売中（在庫確認が必要） と表示する」です。マーカーごと編集し、次の1行だけにします。

'商品状態: 販売中（在庫確認が必要）' | Set-Content -Encoding utf8 conflict.txt
git add conflict.txt
git diff --cached
git commit -m "docs: 状態表示の競合を仕様に従って解決"
git status
git log --graph --oneline --all

成功条件は (1) マーカーが残らない、(2) 内容が仕様に合う、(3) working tree clean であることです。

コンフリクト時に ours や theirs を無条件に選ぶと必要な変更を失うことがあります。

理解を深める：コンフリクトはなぜ起こり、どう向き合えばよいのか

同じ箇所を異なる方向に変更した際、Gitが自動でどちらを採用すべきか決められない状態です。人間が仕様と意図を読み、両者の変更を踏まえて解決します。競合マーカーを消しただけでは正しい実装とは限りません。

解消後の動作確認と差分確認まで必要です。

理解を深める：なぜコンフリクトが起きるのか

異なるブランチで同じ場所の変更を行うと、Gitだけでは意図を判定できない場合があります。競合マーカーは「Gitがどちらを残すか判断できなかった場所」です。片方を機械的に選べばよいとは限りません。

仕様を確認し、両方の目的を満たす内容へ人が整理した後、差分とテスト結果を確かめてコミットします。

この節の独学チェック：07. コンフリクトをわざと発生させる

確認問題： 同じ行を2ブランチで違う内容に修正してマージしたら、何が起こりえますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

08. マージを中断して安全に元へ戻す練習

誤った解決を進める前に、マージを取り消してやり直す方法があります。先ほどの競合練習を終えたリポジトリで、新しいファイルを使って次の通り操作します。

'確認待ち' | Set-Content -Encoding utf8 abort-demo.txt
git add abort-demo.txt
git commit -m "docs: 中断演習の基準"
git switch -c feature/abort-demo
'作業者Aの案' | Set-Content -Encoding utf8 abort-demo.txt
git add abort-demo.txt
git commit -m "docs: A案"
git switch main
'作業者Bの案' | Set-Content -Encoding utf8 abort-demo.txt
git add abort-demo.txt
git commit -m "docs: B案"
git merge feature/abort-demo
git status
git merge --abort
git status
Get-Content abort-demo.txt

merge --abort は開始前のマージ状態へ戻すための操作です。この演習のようにマージ前に作業ツリーがクリーンなら安全に確認できます。ただし、マージ前から未コミットの変更がある場合、完全な復元が保証されません。

演習では必ず開始前に git status を確認します。

この節の独学チェック：08. マージを中断して安全に元へ戻す練習

確認問題： コンフリクトを解消せずにマージ作業をやめるには何を使いますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

09. ローカル共有リポジトリで二人の共同開発を模擬する

次は、同じPCに shared.git（共有履歴）、member-a（担当A）、member-b（担当B）の三つを作ります。実務のチームでも考え方は同じですが、今回はネットワークやアカウントは使いません。

既存の project とは別の練習です。

Set-Location "$HOME\java-git-training-08"
git init --bare shared.git
git clone ./shared.git member-a
git clone ./shared.git member-b
Set-Location member-a
git switch -c main
git config user.name "Member A"
git config user.email "a@example.invalid"
'# 商品仕様' | Set-Content -Encoding utf8 PRODUCT.md
git add PRODUCT.md
git commit -m "docs: 共有用の初期仕様"
git push -u origin main

--bare は直接ファイルを編集せず、履歴共有に使うリポジトリを作ります。clone はそれを複製し、origin は複製元に付けられる名前です。

空の共有先からcloneすると警告が出ますが、この直後の初回pushまでは想定どおりです。

Set-Location ../member-b
git fetch origin
git switch -c main --track origin/main
git config user.name "Member B"
git config user.email "b@example.invalid"
Get-Content PRODUCT.md

担当Bのファイルに # 商品仕様 が表示されれば初回共有は成功です。次に担当Aは価格説明を追加します。

Set-Location ../member-a
'価格は税込表示' | Add-Content -Encoding utf8 PRODUCT.md
git add PRODUCT.md
git commit -m "docs: 価格表示の仕様を追加"
git push
Set-Location ../member-b
git pull --ff-only
Get-Content PRODUCT.md

git pull --ff-only は、履歴が素直に進められるときだけ共有先の変更を取り込みます。意図せぬマージコミットを避けられます。担当Bの PRODUCT.md に税込表示の説明が増えたら成功です。

理解を深める：fetch・pull・pushの違い

fetch は他のリポジトリの履歴情報を取り込みますが、通常は作業ブランチを自動で統合しません。pull は一般にfetch後に統合処理を行います（設定によりmergeまたはrebase）。

push は自分のコミットを相手のリポジトリへ送ります。共有元に何があるか確認したいだけならfetchから始めると、意図せぬ統合を避けやすくなります。

この節の独学チェック：09. ローカル共有リポジトリで二人の共同開発を模擬する

確認問題： 2人が別フォルダーで同じ共有リポジトリを扱うとき、最初に何を確認しますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

10. pushの拒否と共同開発での取り込み

実務では、担当Bが編集中に担当Aが先にpushすることがあります。この場合、担当Bのpushが拒否されることがあります。ここでは別々のファイルを追加するため、取り込んだ後は簡単に統合できます。

# member-bにいることを確認
git switch -c feature/b-note
'B: 商品の表示を確認' | Set-Content -Encoding utf8 B_NOTE.md
git add B_NOTE.md
git commit -m "docs: B担当の調査メモ"
git switch main
# mainにはまだ変更しない
Set-Location ../member-a
'担当Aの追加メモ' | Set-Content -Encoding utf8 A_NOTE.md
git add A_NOTE.md
git commit -m "docs: A担当の調査メモ"
git push
Set-Location ../member-b
git fetch origin
git merge --ff-only origin/main
git merge feature/b-note
git push
git log --graph --oneline --all

fetch は共有先の履歴を取得しますが、作業中のファイルを直ちに統合しません。merge --ff-only origin/main でmainを先へ進め、feature/b-note の変更を取り込みます。

ここでは自動的に統合できるはずです。git push で共有先に反映します。先に説明したpush拒否を無理に再現する必要はありません。経験者向けの追加課題で実施します。

この節の独学チェック：10. pushの拒否と共同開発での取り込み

確認問題： pushがnon-fast-forwardで拒否されたとき、強制pushが第一選択ですか。

取り組み方： 解答を見る前に自分の答えを記録してください。

11. Gitコマンドで履歴と変更を確認する

履歴と差分はGit for Windowsだけで確認できます。GUIソフトウェアは必要ありません。

1. PowerShellで $HOME\java-git-training-08\project に移動し、git rev-parse --show-toplevel でリポジトリのルートを確認します。
2. git log --graph --oneline --all -10 でコミットとブランチの関係を確認します。
3. git branch --list で main、feature/stock、feature/status のブランチを確認します（削除済みの場合は先の演習の履歴で確認）。
4. README.md に1行追記し、git diff -- README.md で未ステージの差分を確認します。
5. git add README.md の後に git diff --cached -- README.md でコミット対象を確認します。
6. git commit -m "docs: Gitで説明を追記" で履歴に保存し、git log -1 --oneline と git show --stat HEAD で結果を確認します。

cd "$HOME\java-git-training-08\project"
git status
git log --graph --oneline --all -10
git branch --list
git diff -- README.md
git add README.md
git diff --cached -- README.md
git commit -m "docs: Gitで説明を追記"
git show --stat HEAD

注意： 新しくコミットする前に README.md を自分で変更してください。変更がなければGitはコミットを作成しません。履歴を破壊する git reset --hard や強制pushは使いません。

この節の独学チェック：11. Gitコマンドで履歴と変更を確認する

確認問題： コミット前に①変更ファイル、②ステージ済みの差分、③対象ブランチを確認するコマンドをそれぞれ答えてください。

12. 操作を誤ったときの確認順序

作業が止まったら、最初に状態を読むことが重要です。突然ファイルを削除したり、reset --hard を実行してはいけません。

Get-Location
git status
git branch --show-current
git log --oneline -5
git remote -v

• fatal: not a git repository：今いる場所がリポジトリ外かもしれません。Get-Location から確認します。
• Author identity unknown：git config user.name と git config user.email を設定します。
• nothing to commit：編集したファイルを保存していないか、すでにコミット済みの可能性があります。git diff を見ます。
• pathspec ... did not match：ファイル名・ブランチ名のタイプミスを git status や git branch -a で確認します。
• CONFLICT：競合は学習で想定する状態です。git status を確認し、両者の意図に合う内容を選びます。
• non-fast-forward でpushが拒否：共有先に新しい履歴がある可能性があります。git fetch → git log --graph --all --oneline で差異を確認します。push --force は使用しません。
• 表示された履歴が想定と異なる：git rev-parse --show-toplevel と git branch --show-current で作業場所とブランチを確認します。

共有済みのコミットを打ち消す場合、実務では git revert を検討します。これは履歴そのものを消すのではなく、打ち消す変更を新しいコミットとして記録します。

git restore は未コミット変更を破棄する場合があるため、この章の演習には含めません。

理解を深める：reset・revertをむやみに使わない理由

reset は現在のブランチが指すコミット位置を移動する操作です。オプションによっては作業中の変更を失うおそれがあります。

revert は取り消したいコミットの逆変更を新しいコミットとして残すため、共有済みの履歴を維持しやすくなります。チームの履歴を書き換える操作は、他のメンバーに影響するため勝手に実行しません。

理解を深める：操作する前にstatusで現在の状態を確認する理由

git status で「今どのブランチか」「未コミット変更があるか」を確認してから操作すると、別の課題や作業途中の変更を巻き込む危険を減らせます。

事故が起きた場合も、やみくもに reset --hard を実行せず、状態と履歴を確認します。Gitは命令の暗記よりも変更を失わず意図した差分だけを共有する習慣が重要です。

この節の独学チェック：12. 操作を誤ったときの確認順序

確認問題： Git操作を誤ったとき、最初に何を確認しますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

13. チーム開発の作業手順

実際の開発案件では、(1)依頼内容を読み、不明点を確認、(2)現在のブランチと変更状態を確認、(3)作業用ブランチを作る、(4)コードとテストを修正、(5)差分をレビュー、(6)目的が分かるコミットを作る、(7)チームのルールに従って共有、(8)別の人のレビューとテストを受ける、という順番が基本になります。

Gitはプログラムの正しさ自体を保証しません。履歴がきれいでも、仕様を満たしていなければ修正が必要です。今までの章で学んだJUnitやログの確認とセットで使います。

経験者向け補足：rebase、cherry-pick、interactive rebase、タグ、保護ブランチ、PRなどは現場で使用しますが、この章の初心者演習の必須範囲から外しています。

ブランチ戦略やレビュー方式はチームの規約に従ってください。

この節の独学チェック：13. チーム開発の作業手順

確認問題： 共同開発でレビューしやすいコミットとはどんな単位ですか。

取り組み方： 解答を見る前に自分の答えを記録してください。

14. 理解度チェック

1. git add と git commit は何が違いますか。2. git diff と git diff --staged はそれぞれ何を見るコマンドですか。3. マージ時に同じ行が違う内容ならどのように判断しますか。4. push と pull はどちらへ履歴を送りますか。5. .gitignore は追跡済みのパスワードを消しますか。6. git status の working tree clean は何を意味しますか。7. チームで push --force を安易に行ってはいけないのはなぜですか。

答えは本文で自分で探して説明してください。操作課題は別ファイル exercises/08_git/assignment.md にあります。

理解を深める：演習で説明してほしいこと

• あるコミットにはどの目的の変更が含まれていますか。
• コンフリクトでは二つの変更のうち何を残しましたか。判断の根拠は何ですか。
• マージ後、なぜテストをもう一度実行するのですか。

この節の独学チェック：14. 理解度チェック

確認問題： ブランチとマージの理解度をどう確認しますか。

取り組み方： 解答を見る前に自分の答えを記録してください。

15. 第09章へ進むための合格基準

初回コミットと変更差分、機能ブランチの統合、意図的なコンフリクトの解消、共有用リポジトリを使った二人の作業の反映を、操作履歴と最終ファイルの両方で示してください。

エラーが出たときに git status で調査できることも必須です。Git for Windowsだけで全課題を実行できます。

指導者は git log --graph --oneline --all、git status と各ファイルの内容を確認します。操作を読んだだけでは合格とせず、受講者自身が再現できたかを判断します。

学習内容を振り返るための操作確認

この節は、本文の例題や演習が実行できないときに戻るための案内です。最初にファイルの場所と作業中のツールを確認し、コマンドを貼り付ける前に現在のフォルダーを確認してください。

実行する場所と順序

PowerShellで Get-Location を実行し、章で作成した専用の練習フォルダー内か確認します。職場や他章のリポジトリに対して実行しません。

成功・失敗の判断

git status、git log --oneline、差分を確認します。競合マーカーを消しただけでなく、仕様どおりの内容でコミットできたか確認します。

途中で止まったとき

競合が解決できない場合は変更を消すコマンドをむやみに実行せず、git status に表示される競合ファイルを開いて確認します。

作業記録の書き方

1. 利用環境（OS、Java、必要なツールのバージョン）を記録します。
2. 実際に操作したフォルダー、実行コマンド、入力内容を記録します。
3. 期待した結果と実際の結果を別々に書きます。失敗時にはエラーメッセージの全文を保管します。
4. 修正を加えた場合は変更箇所を記録し、同じ手順で再確認します。
5. 成功を確認できていなければ「未確認」と記載し、成功と推測して次へ進まないでください。

実際の入力、実行結果、原因の説明、演習の提出物がそろって初めて章の学習を完了とします。

この節の独学チェック：15. 第09章へ進むための合格基準

確認問題： 次章の既存システム改修にGitが必要な理由は何ですか。

取り組み方： 解答を見る前に自分の答えを記録してください。