第11章次のステップへ¶

この章で学ぶこと ¶

ここまでの操作を自分のスクリプトディレクトリに適用する
ブランチと PR がなぜ必要になるかの予告
さらに学ぶための参考資料

ここまでのおさらい ¶

第 1 章から第 10 章までで、Git と GitHub の基礎的な操作はひと通り身についています。難しそうに見えたコマンドも、実際に手を動かしてみれば「特定の場面で使う、決まった呪文」のようなものだと分かったはずです。ここで一度、身についたことを振り返っておきましょう。

ここまでに身についたこと:

git init で自分のディレクトリをリポジトリ化できる
git add → git commit で変更を履歴に残せる
git log/git diff で過去の変更を追える
git restore/git revert で誤った変更を戻せる
.gitignore で秘匿情報や生成物を除外できる
gh repo create → git push で GitHub に公開できる
gh issue create で TODO・バグを管理できる
gh repo clone → pull/push で複数端末を同期できる

自分のスクリプトディレクトリに適用する ¶

ここまで ~/my-scripts という練習用のディレクトリで操作してきましたが、全く同じ流れがあなたの実際のスクリプトに対しても使えます。

ステップ:

# 1. 自分のスクリプトディレクトリに移動
cd "C:\Users\<あなた>\Documents\my-real-scripts"

# 2. .gitignore を先に作る (.env など秘匿情報を確実に除外)
Set-Content -Encoding utf8 -Path .gitignore -Value @"
# secrets
.env
.env.*

# Windows
Thumbs.db
"@

# 3. リポジトリ初期化
git init

# 4. 最初のコミット
git add .
git status   # ← .env が含まれていないか必ず確認
git commit -m "initial commit"

# 5. GitHub にリモート作成 + push
gh repo create --source=. --private --remote=origin
git push -u origin main

危険

ステップ 4 の git status 確認は最重要です。.env や API キー入りのファイルが Untracked と表示されていないか、new file: に並んでいないかを必ず目視確認してから commit してください。

1 人作業の限界 ¶

ここまでの章では「自分 1 人が、自分のスクリプトを管理する」という前提で進めてきました。実際、最初のうちはこれで十分です。しかし作業を続けていくと、次のような場面に必ずぶつかります。

同僚や友人と一緒に同じスクリプトを編集したくなる
「実験的な変更を独立して試したい」「リリース版と開発版を分けたい」と思う
「他人の変更を取り込む前にレビューしたい」「自分の変更も誰かに見てもらってから本流に入れたい」と感じる

これらが次の段階で必要になる機能です。

ブランチとは (予告)¶

注釈

ブランチは「履歴の枝分かれ」。main ブランチを安定版として保ちつつ、feature-x という別の枝で実験的に開発し、出来上がったら main に取り込む、という運用ができます。

Pull Request (PR) とは (予告)¶

注釈

Pull Request は「自分の枝 (ブランチ) を main に取り込んでください」というレビュー依頼。GitHub 上でコメント・差分確認・承認のやり取りができ、コードレビュー文化の中心です。

次に学ぶと良いこと (推奨順)¶

ブランチ操作 — git branch / git switch / git merge
コンフリクト解決 — 同じファイルを別々に編集した時の対処
Pull Request — gh pr create / gh pr checkout / gh pr review
GitHub Actions — push 時に自動でテスト・デプロイを実行
GitHub Pages — リポジトリから静的サイトを公開

参考資料 ¶

公式ドキュメント https://git-scm.com/doc
Pro Git 本 (日本語訳あり、無料) https://git-scm.com/book/ja/v2
GitHub Docs https://docs.github.com/ja
GitHub CLI マニュアル https://cli.github.com/manual/
git help <command> (CLI のヘルプ、例: git help log)

おわりに ¶

ここまでお疲れさまでした。最初は git と打つたびに「これで本当に大丈夫だろうか」「履歴が壊れたらどうしよう」と不安になったかもしれません。それは自然なことです。Git は強力なツールであり、慣れるまでは少し怖く感じられます。

しかし、毎日の作業のなかで git status → git add → git commit を繰り返しているうちに、必ず手が勝手に動くようになります。コミットメッセージをどう書くか、.gitignore に何を入れるかも、自分の中で自然と基準ができてきます。そうなれば、もう「バックアップを取り忘れた」「上書き保存してしまった」と悩む夜はやってきません。

1 週間後の自分が、今日のあなたに感謝します。 今日コミットした履歴は、未来のあなたを必ず助けてくれる味方です。これからも一歩ずつ、自分のペースで Git と GitHub を使い続けていきましょう。

第11章 次のステップへ¶

第11章次のステップへ¶