【Git練習1】ローカルだけで失敗して、なかったことにする
自分のPC内だけで実験して、失敗したので捨てるパターンです。
サーバーには反映させないので、プッシュはしません。
手順1：ブランチを切る（作成）
- SourceTree上部の「ブランチ」をクリック。
- 新規ブランチ名:
test-local-onlyと入力し、「ブランチを作成」をクリック。
手順2：変更する
- HTMLファイルの数字を
779,704→666,666に書き換えて保存。
手順3：コミットする（プッシュなし）
- SourceTreeで「コミット」ボタンを押す。
- コメントを入力（例:
実験）。 - 【重要】「変更を即座にプッシュする」のチェックを外す（OFF）。
- 右下の「コミット」をクリック。
手順4：「間違えた！」と気づく（戻る）
- SourceTree左メニューの
masterをダブルクリック。 - （これでPC内のファイルは一瞬で元通りになります）
手順5：ブランチを捨てる
test-local-onlyを右クリック → 「削除」 → 「強制削除」。
【Git練習2】サーバーでテストして失敗し、元に戻す
本番サーバーでプレビューしたが、気に入らなかったので採用せずに捨てるパターンです。
サーバーで見たいので、プッシュ（送信）が必要です。
手順1：ブランチを切る
- SourceTreeで
masterから新規ブランチtest-server-previewを作成。
手順2：変更＆コミット
- HTMLファイルの数字を
555,555に書き換えて保存。
手順3：コミット＆プッシュ（一発送信）
- 「コミット」ボタンを押す。
- コメントを入力（例:
サーバーテスト）。 - 【重要】「変更を即座にプッシュする」にチェックを入れる（ON）。
- 右下の「コミット」をクリック。
- （これだけでBitbucketにもブランチが作られ、データが飛びます）
手順4：AWSサーバーでプレビュー（PuTTY）
以下のコマンドをコピーしてPuTTYで実行し、サーバーの表示チャンネルをテスト用に切り替えます。
|
1 2 3 4 5 6 7 8 9 10 |
cd /var/www/html/ruling # 1. 最新のブランチ情報を取り寄せる git fetch # 2. テスト用ブランチに切り替える git checkout test-server-preview # 3. 確実に反映させるために再起動 sudo systemctl restart gunicorn |
手順5：確認＆却下
- ブラウザで見て「555,555」になっていることを確認。
- 「やっぱりこの変更はナシだ！」と判断する。
手順6：元に戻す（復旧）
AWSサーバー（PuTTY）で以下のコマンドを実行し、サーバーを正常な状態に戻します。
|
1 2 3 4 5 |
# 本番チャンネル(master)に戻す git checkout master # 念のため再起動して元通りか確認 sudo systemctl restart gunicorn |
手順7：後始末（削除）
- SourceTreeで
masterをダブルクリックして戻る。 test-server-previewを右クリック削除。- 「リモート」 の
origin/test-server-previewも右クリック削除。
【Git練習3】サーバーでテストして成功したので、本番採用する
プレビューで確信を得てから、正式にマージする「開発の王道」パターンです。
手順1：ブランチを切る
- SourceTreeで
masterから新規ブランチfeature-new-designを作成。
手順2：変更＆コミット
- HTMLファイルの数字を
999,999に書き換えて保存。
手順3：コミット＆プッシュ（一発送信）
- 「コミット」ボタンを押す。
- コメントを入力（例:
数字更新）。 - 「変更を即座にプッシュする」にチェックを入れる（ON）。
- 右下の「コミット」をクリック。
手順4：AWSサーバーでプレビュー（PuTTY）
以下のコマンドを実行してテストします。
|
1 2 3 4 5 6 7 8 |
# 1. 情報を更新 git fetch # 2. テスト用ブランチに切り替え git checkout feature-new-design # 3. 再起動して確認 sudo systemctl restart gunicorn |
ブラウザで「999,999」を確認し、「よし、これでいこう！」と決断します。
手順5：マージ（統合）する
- SourceTree左メニューで
masterをダブルクリック して移動。 feature-new-designを右クリック → 「現在のブランチに feature-new-design をマージ」 → OK。- （これでローカルの
masterが999,999になりました）
手順6：本番反映のプッシュ
- SourceTree上部「プッシュ」をクリック。
masterにチェックを入れてプッシュ。
手順7：AWSサーバーを本番化（PuTTY）
サーバーを master に戻し、最新状態にします。ここでいつもの「魔法のコマンド」を使います。
|
1 2 3 4 5 6 |
# 1. まずmasterに戻る git checkout master # 2. 魔法のコマンド（プル・コピー・再起動を一気に実行） git pull && python3 manage.py collectstatic --noinput && sudo systemctl restart gunicorn |
手順8：後始末
- 用済みの
feature-new-designブランチ（ローカルとリモート）を削除して完了です。
【Git練習4】修正を重ねてから本番採用する
一度の変更で満足せず、プレビュー後にさらに修正を加えてから、最後にマージするパターンです。
「同じブランチでの更新」をサーバーに反映させる手順を学びます。
手順1：ブランチを切る
- SourceTreeで
masterから新規ブランチfeature-trial-errorを作成。
手順2：1回目の変更（999,999）
- ローカルPCでHTMLファイルを開き、数字を
999,999に書き換えて保存。
手順3：1回目のコミット＆プッシュ
- SourceTreeで「コミット」ボタンを押す。
- コメントを入力（例:
数字変更(仮)）。 - 「変更を即座にプッシュする」にチェックを入れる（ON）。
- 「コミット」をクリック。
手順4：AWSサーバーで1回目のプレビュー
まず、サーバーをテスト用ブランチに切り替えて確認します。
|
1 2 3 4 5 6 7 8 9 10 |
cd /var/www/html/ruling # 1. 情報を更新 git fetch # 2. テスト用ブランチに切り替え git checkout feature-trial-error # 3. 再起動して確認 sudo systemctl restart gunicorn |
【確認】 ブラウザで見て「999,999」になっていることを確認。
しかし、「やっぱり 1,000,000 の方がいいな」と考え直します。
手順5：2回目の変更（1,000,000）
- ローカルPCで再びHTMLファイルを開き、
1,000,000に書き換えて保存。
手順6：2回目のコミット＆プッシュ
- SourceTreeで再び「コミット」ボタンを押す。
- コメントを入力（例:
やっぱり100万に変更）。 - 「変更を即座にプッシュする」にチェックを入れる（ON）。
- 「コミット」をクリック。
（これで同じブランチに2つ目の変更が積み上がりました）
手順7：AWSサーバーで2回目のプレビュー（ここが重要！）
サーバーは既に feature-trial-error ブランチにいますが、内容は「1回目」のままです。
「同じブランチの最新版」を取り込むために、ここでは checkout ではなく pull を使います。
|
1 2 3 4 5 |
# 1. 最新の変更（2回目のコミット）をダウンロードして適用 git pull # 2. 再起動して確認 sudo systemctl restart gunicorn |
【確認】 ブラウザで「1,000,000」になったことを確認。「よし、これで採用！」と決断します。
手順8：マージ（統合）する
- SourceTree左メニューで
masterをダブルクリック して移動。 feature-trial-errorを右クリック → 「現在のブランチに feature-trial-error をマージ」 → OK。
手順9：本番反映のプッシュ
- SourceTree上部「プッシュ」をクリック。
masterにチェックを入れてプッシュ。
手順10：AWSサーバーを本番化
サーバーを master に戻し、最新状態にします。いつもの魔法のコマンドです。
|
1 2 3 4 5 |
# 1. まずmasterに戻る git checkout master # 2. 魔法のコマンド（反映・コピー・再起動） git pull && python3 manage.py collectstatic --noinput && sudo systemctl restart gunicorn |
手順11：後始末
- 用済みの
feature-trial-errorブランチ（ローカルとリモート）を削除して完了です。
