コマンドの暗記より、変更を説明できること
GitとGitHubは何を練習する？応募前に見せられる変更履歴の作り方
Gitは変更履歴を管理する道具、GitHubはその履歴を共有・レビューする場です。はじめは小さな架空の制作物で「変更する→記録する→別の変更を試す→確認して取り込む」を一周させましょう。公開すること自体が目的ではありません。
求人票の「Git使用」が意味する作業を聞く
求人にGitと書かれていても、一人で履歴を残すだけなのか、チームで変更を確認するのかでは求められる経験が違います。募集要項の「コードレビュー」「ブランチ」「プルリクエスト」といった語を確認し、記載が曖昧なら選考で仕事の流れを尋ねます。自分の練習は、その作業に近い最小単位にします。
GitHubの公式入門では、リポジトリ、コミット、ブランチ、プルリクエストの関係を一つの制作例で説明しています。まずこの四つを自分の言葉で説明できれば、細かなコマンド一覧より進み具合を確かめやすくなります。
一つの課題で練習すること
| 段階 | 行うこと | 残す説明 |
|---|---|---|
| 保存 | READMEと小さな制作物を記録する | 何を作るか、どう動かすか |
| 変更 | 一つの目的ごとに変更を分けて記録する | なぜ変えたか |
| 分岐 | 別ブランチで試し、元の版を保つ | 試した内容と結果 |
| 確認 | 差分を見てプルリクエストにまとめる | 確認方法と残った課題 |
共同作業をしたことがなければ、レビュー経験を作り話にしません。自分の変更を自分で差分確認した範囲を示せば十分です。
練習用リポジトリを小さく完成させる
- 公開してよい架空の題材を選ぶ簡単なメモアプリ、表の集計例、静的ページなどにします。
- READMEに使い方を書く何を作ったか、実行手順、動作確認方法を記します。
- 目的ごとに変更を分ける修正前後を見比べ、意味の分かる変更説明を付けます。
- ブランチとプルリクエストを試す変更理由、確認結果、注意点を書き、差分を見直します。
公開前に氏名、メールアドレス、勤務先の資料、APIキー、他人の作品を含んでいないか必ず確認します。非公開リポジトリでも機密情報を置いてよいわけではありません。
応募時に説明できるかを確認する
- 制作物の目的と自分の担当範囲を言える
- 変更を目的ごとに分け、差分を示せる
- 動作確認をREADMEまたは変更説明に残した
- 公開情報に秘密値や実務データがない
- 共同開発未経験なら、その点を明確にしている
コードを見せる前に、応募先が何を確かめたいかを確認します。SQLの練習成果など別の題材でも、この流れを使えます。学ぶ内容全体の選択はデジタルスキル標準で職種から整理できます。
操作の確認先
確認日：2026年9月30日