個人プロジェクトだからってGithubのメッセージを適当に書いていませんか？実は、恥ずかしながら自分も「一人でやるから大丈夫」と思って、適当にPushしたり、メッセージを書いたりしていました。でも、いざ誰かにGithubを共有する場面になると、「もっとちゃんと書けばよかった…」とかなり恥ずかしく感じました。
特に、面接や履歴書でGithubを共有している場合、コードだけではなくコミットメッセージまで見られている可能性があります。そう考えると、「fix」「test」「aaa」みたいな適当なメッセージは、もしかしたらマイナスな印象になっていたのかもしれません。
もちろん、個人開発なので自由ではあります。ただ、Githubは「どんな風に開発しているか」が見える場所でもあるので、コミットメッセージを少し意識するだけでも印象はかなり変わると思います。自分もまだ完璧ではありませんが、これからは他の人が見ても分かりやすいメッセージを意識して管理していきたいと思います。
- Githubとは何か
- Repository / Branch などの基本用語
- 開発でよく使う基本コマンド
- コミットメッセージの書き方
- Pull RequestとMergeの流れ
- 共同開発で意識したいポイント
Githubとは
GitHubは、コードを保存・管理・共有できるサービスです。簡単に言うと、「開発履歴を管理する場所」です。
例えば、
- いつ変更したか
- どこを修正したか
- 誰が修正したか
などを履歴として残すことができます。
また、Githubを使うことで、
- バックアップ
- バージョン管理
- チーム開発
- コード共有
なども簡単に行えます。
自分も最初は「コードを保存する場所」くらいの認識でしたが、実際に使ってみると「どんな風に開発しているか」を見せる場所でもあると感じました。
Githubの基本用語
Repository（レポジトリ）
プロジェクトを保存する「貯蔵庫」です。新しいプロジェクトを始める際は、まずレポジトリを作成しましょう。
レポジトリの簡単な作成方法
以下、Githubサイトから直接レポジトリの作成が可能です。
- 右上の「＋」ボタンを押下 → 「New repository」をクリック。
- Repository name を入力。
- Visibility を 「Public（公開）」または「Private（非公開）」から選択。
- 「Initialize this repository with a README」にチェックを入れると、プロジェクト説明用のファイルが自動生成されるのでおすすめです。
Branch（ブランチ）
メイン（main/master）で直接作業をすると、コードが壊れた際の復旧が難しくなります。常に新しいブランチを作成して、その上で作業を進めるのが開発の流れです。
git checkout -b ブランチ名 //作成と移動Clone（クローン）
リモートにあるレポジトリを、自分のPC（ローカル）にコピーすることです。
git clone <レポジトリのURL>レポジトリのURLは該当のレポジトリの「<>Code」ページから 右上の「<>Code」を押下して確認できます。
開発の基本サイクル
レポジトリを作成して、ローカル環境とGithubの連携ができましたら新しいブランチを作成して作業を進めます。その際に必要なサイクルをまとめました。
基本的に1つ作業に１つのコミットをすることがお勧めです。（細かすぎる場合は、add .だけでもしておくと、修正や作業の確認などがスムーズです）
１. add
変更したファイルをステージングエリア（保存準備）に上げます。
git add .2. Commit（コミット）
変更内容にメッセージを添えて保存します。
git commit -m "fix:ログインエラー処理" // ""の中にメッセージを入力3. Push（プッシュ）
ローカルの変更をGithubのリモートレポジトリに送信します。
git push origin <ブランチ名> // ex) git push origin feature/new-deatil-page4. Pull Request（プルリクエスト）
自分の作業をメインブランチ（main又はmaster）に反映してもらうようリクエストを送る機能です。コミットした作業を全てプルリクエストを送ります。これはコマンドではなく、Githubの公式サイト上で行います。
- Githubのリポジトリページを開くと表示される「Compare & pull request」ボタンをクリック。
- 変更内容を分かりやすくタイトルと説明に記入。
- 「Create pull request」をクリックして完了！
5. Merge（マージ）
別のブランチで進めていた作業を、メインブランチ（main又はmaster）に合体させる操作のことです。プルリクエストの最終段階といえます。
基本的にはGithubの画面上にある 「Merge pull request」 ボタンをクリックするだけで完了します。これにより、自分が新しく作った機能がプロジェクトの「本番コード」として統合されます。
6. Pull（プル）
Merge が完了した後は、自分のローカル環境も最新状態へ更新しておきます。特に共同開発では、他の人が main ブランチへ追加した変更内容を取得するためにも pull は非常に重要です。
git checkout <ブランチ名> //ブランチを<ブランチ名>に変更
git pull origin <ブランチ名> //<ブランチ名>にプル開発の基本的な流れ
基本的な開発の流れは以下のようになります。
main を pull
↓
新しい branch 作成
↓
作業・修正
↓
add → commit
↓
push
↓
Pull Request 作成
↓
Merge
↓
main を pull して最新化
共同開発では、作業前にpullをして最新状態を確認することがかなり重要です。もし他のメンバーが main ブランチを更新していた場合、古い状態のまま作業を進めるとConflict(競合)の原因になることがあります。
そのため、
- 作業前に
mainをpull - Merge後も最新状態を
pull
する習慣を付けるのがおすすめです。
コミットメッセージの書き方
他の人が見ても一目で内容がわかるように、「タイプ：内容」の形式で書くのが一般的です。
タイプ・内容
| タイプ | 内容 | 説明 |
| feat | 新機能追加 | 新しい機能を追加したとき |
| fix | バグ修正 | 誤字やプログラムのミスを直したとき |
| style | デザイン修正 | UIの調整やCSSの変更など |
| refactor | リファクタリング | コードを綺麗に書き換えたとき（機能変化なし） |
| docs | ドキュメント修正 | READMEやコメントの修正 |
| chore | 細かい修正・設定変更 | 設定変更やライブラリの更新など |
| test | テスト関連 | テストコードの追加や修正 |
| rename | ファイル名変更 | ファイル名の変更 |
| remove | 削除 | ファイルなど削除 |
作成例
例: feat: タイマー停止機能の実装 / fix: ログイン時のエラーを修正共同開発（Collaborator）と注意点
Githubの Settings → Collaborators からメンバーを追加すれば、複数人で開発が可能です。共同開発では以下のルールが非常に重要になります。
- Branchを必ず分ける: 自分の作業領域を確保する
- Pull Requestを出す: 他のメンバーに確認してもらう
- Conflict（競合）の解決: 同じ箇所を同時に編集すると発生します。お互いに相談しながらコードを統合しましょう。
- READMEを丁寧に書く: このプロジェクトが何なのか、どうやって動かすのかを明記します。
終わりに
Githubは単なる保存場所ではなく、「自分がどのように考え、どのように開発を進めてきたか」を証明するポートフォリオそのものです。メッセージ一つひとつを少し意識するだけで、エンジニアとしての信頼度は格段に上がります。
見て分かるだけでなく、「口に出して説明できる・人に見せられる」管理を心がけていきましょう
