Git(SourceTree)で練習ブランチアウトとマージ

【Git練習1】ローカルだけで失敗して、なかったことにする

自分のPC内だけで実験して、失敗したので捨てるパターンです。
サーバーには反映させないので、プッシュはしません。

手順1：ブランチを切る（作成）

1. SourceTree上部の「ブランチ」をクリック。
2. 新規ブランチ名: test-local-only と入力し、「ブランチを作成」をクリック。

手順2：変更する

1. HTMLファイルの数字を 779,704 → 666,666 に書き換えて保存。

手順3：コミットする（プッシュなし）

1. SourceTreeで「コミット」ボタンを押す。
2. コメントを入力（例: 実験）。
3. 【重要】「変更を即座にプッシュする」のチェックを外す（OFF）。
4. 右下の「コミット」をクリック。

手順4：「間違えた！」と気づく（戻る）

1. SourceTree左メニューの master をダブルクリック。
2. （これでPC内のファイルは一瞬で元通りになります）

手順5：ブランチを捨てる

1. test-local-only を右クリック → 「削除」 → 「強制削除」。

---

【Git練習2】サーバーでテストして失敗し、元に戻す

本番サーバーでプレビューしたが、気に入らなかったので採用せずに捨てるパターンです。
サーバーで見たいので、プッシュ（送信）が必要です。

手順1：ブランチを切る

1. SourceTreeで master から新規ブランチ test-server-preview を作成。

手順2：変更＆コミット

1. HTMLファイルの数字を 555,555 に書き換えて保存。

手順3：コミット＆プッシュ（一発送信）

1. 「コミット」ボタンを押す。
2. コメントを入力（例: サーバーテスト）。
3. 【重要】「変更を即座にプッシュする」にチェックを入れる（ON）。
4. 右下の「コミット」をクリック。
5. （これだけでBitbucketにもブランチが作られ、データが飛びます）

手順4：AWSサーバーでプレビュー（PuTTY）

以下のコマンドをコピーしてPuTTYで実行し、サーバーの表示チャンネルをテスト用に切り替えます。

手順5：確認＆却下

1. ブラウザで見て「555,555」になっていることを確認。
2. 「やっぱりこの変更はナシだ！」と判断する。

手順6：元に戻す（復旧）

AWSサーバー（PuTTY）で以下のコマンドを実行し、サーバーを正常な状態に戻します。

手順7：後始末（削除）

1. SourceTreeで master をダブルクリックして戻る。
2. test-server-preview を右クリック削除。
3. 「リモート」 の origin/test-server-preview も右クリック削除。

---

【Git練習3】サーバーでテストして成功したので、本番採用する

プレビューで確信を得てから、正式にマージする「開発の王道」パターンです。

手順1：ブランチを切る

1. SourceTreeで master から新規ブランチ feature-new-design を作成。

手順2：変更＆コミット

1. HTMLファイルの数字を 999,999 に書き換えて保存。

手順3：コミット＆プッシュ（一発送信）

1. 「コミット」ボタンを押す。
2. コメントを入力（例: 数字更新）。
3. 「変更を即座にプッシュする」にチェックを入れる（ON）。
4. 右下の「コミット」をクリック。

手順4：AWSサーバーでプレビュー（PuTTY）

以下のコマンドを実行してテストします。

ブラウザで「999,999」を確認し、「よし、これでいこう！」と決断します。

手順5：マージ（統合）する

1. SourceTree左メニューで master をダブルクリック して移動。
2. feature-new-design を右クリック → 「現在のブランチに feature-new-design をマージ」 → OK。
3. （これでローカルの master が 999,999 になりました）

手順6：本番反映のプッシュ

1. SourceTree上部「プッシュ」をクリック。
2. master にチェックを入れてプッシュ。

手順7：AWSサーバーを本番化（PuTTY）

サーバーを master に戻し、最新状態にします。ここでいつもの「魔法のコマンド」を使います。

手順8：後始末

1. 用済みの feature-new-design ブランチ（ローカルとリモート）を削除して完了です。

【Git練習4】修正を重ねてから本番採用する

一度の変更で満足せず、プレビュー後にさらに修正を加えてから、最後にマージするパターンです。
「同じブランチでの更新」をサーバーに反映させる手順を学びます。

手順1：ブランチを切る

1. SourceTreeで master から新規ブランチ feature-trial-error を作成。

手順2：1回目の変更（999,999）

1. ローカルPCでHTMLファイルを開き、数字を 999,999 に書き換えて保存。

手順3：1回目のコミット＆プッシュ

1. SourceTreeで「コミット」ボタンを押す。
2. コメントを入力（例: 数字変更(仮)）。
3. 「変更を即座にプッシュする」にチェックを入れる（ON）。
4. 「コミット」をクリック。

手順4：AWSサーバーで1回目のプレビュー

まず、サーバーをテスト用ブランチに切り替えて確認します。

【確認】 ブラウザで見て「999,999」になっていることを確認。
しかし、「やっぱり 1,000,000 の方がいいな」と考え直します。

手順5：2回目の変更（1,000,000）

1. ローカルPCで再びHTMLファイルを開き、1,000,000 に書き換えて保存。

手順6：2回目のコミット＆プッシュ

1. SourceTreeで再び「コミット」ボタンを押す。
2. コメントを入力（例: やっぱり100万に変更）。
3. 「変更を即座にプッシュする」にチェックを入れる（ON）。
4. 「コミット」をクリック。
   （これで同じブランチに2つ目の変更が積み上がりました）

手順7：AWSサーバーで2回目のプレビュー（ここが重要！）

サーバーは既に feature-trial-error ブランチにいますが、内容は「1回目」のままです。
「同じブランチの最新版」を取り込むために、ここでは checkout ではなく pull を使います。

【確認】 ブラウザで「1,000,000」になったことを確認。「よし、これで採用！」と決断します。

手順8：マージ（統合）する

1. SourceTree左メニューで master をダブルクリック して移動。
2. feature-trial-error を右クリック → 「現在のブランチに feature-trial-error をマージ」 → OK。

手順9：本番反映のプッシュ

1. SourceTree上部「プッシュ」をクリック。
2. master にチェックを入れてプッシュ。

手順10：AWSサーバーを本番化

サーバーを master に戻し、最新状態にします。いつもの魔法のコマンドです。

手順11：後始末

1. 用済みの feature-trial-error ブランチ（ローカルとリモート）を削除して完了です。