はじめに
個人開発で Spring Boot のポートフォリオを進めている最中、こんな違和感がありました。
「ここ数日、ちゃんとコミットして push しているのに、GitHub のプロフィールの草が全然増えない…」
ブランチにはコードは載っている。PR も作った。
転職活動を始めるためにGitHubを整理しようと思い、マージするのがなんとなく怖く感じていたあの頃（笑）のリポジトリも、mainにマージしないと草に反映されないと知り、過去に放置していたプライベートリポジトリも、まとめて main にマージした。
なのに、Contribution graph（いわゆる「草」）は空白のまま。
今更、GitHub の草のルールを理解して、めちゃくちゃショックだった —— その体験を残しておきます。
何が起きていたか
feature ブランチで作業していた
普段の流れはこんな感じでした。
feature ブランチで開発
↓
git add / commit / push
↓
（できたら PR）
feature/skill-record-edit のようなブランチに、学習記録の追加や学習時間の編集機能をコミットしていました。
ローカルでも GitHub のブランチページでも、コミットはちゃんと見えていました。
だから「反映はできている」と思っていた。
main はずっと止まっていた
一方、main ブランチの更新は 1週間以上前 のまま。
草を見ると、あたかも「何もしていない人」に見える。
実際には feature ブランチでかなり作業していたのに。
ここで初めて、「草って main 基準なのかな？」と気づき始めました。
今更知った GitHub の草のルール
調べてみると、草に載る条件は思っていたより厳しかったです。
① コミットは main（デフォルトブランチ）に入ったものだけ
feature ブランチに push しただけでは、草には載らない。
草に数えられるのは、だいたい次のどちらかです。
- リポジトリの デフォルトブランチ（多くの場合
main） -
gh-pagesブランチ
「ブランチに push した ＝ GitHub に反映した」は正しいけど、
「反映した ＝ 草に載る」ではなかった、という話です。
② Squash merge だと、日付ごとの草は埋まらない
PR を作ってマージすれば草に載る——そこまでは理解しました。
でも、マージの仕方 によって見え方が全然違いました。
| マージ方法 | 草の出方 |
|---|---|
| Create a merge commit | 各コミットの 元の日付 で載りやすい |
| Rebase and merge | だいたい各コミットの日付で載る |
| Squash and merge | マージした日の1マス にまとまる |
Squash merge だと、6/28・6/29・6/30 に分散して作業していても、
7/3 にマージしたなら 7/3 の1日分 になりがちです。
空白だった日付は、後から埋まらない。
③ デフォルトが Squash になっていた
リポジトリの Settings → Pull Requests を見たら、
「Squash merge を許可する」にチェックが入っていた。
気づかないうちに Squash merge でマージしていた可能性が高いです。
個人開発だとレビューがない分、緑の「Merge pull request」を押すだけで終わりがち。
そのときデフォルトが Squash だと、毎回こうなる。
④ プライベートリポジトリは表示設定が別
プライベートリポジトリのコミットは、草に 数えられている ことがあっても、
プロフィールに 表示されない ことがあります。
Settings → Public profile → Include private contributions on my profile
ここにチェックがないと、「数えられているのに見えない」状態になります。
⑤ コミットのメールアドレスも大事
コミットに使っているメールアドレスが、GitHub アカウントに 登録・認証 されていないと、
main にマージしても草に出ないことがあります。
確認コマンド:
git log -1 --format='%ae'
で出てきたアドレスが、GitHub の Settings → Emails で Verified かどうかも要チェックです。
一番ショックだったこと
「過去に放置していたプライベートリポジトリも、草を増やすために main にマージしよう」
そう思って、いくつかマージしました。
なのに、空白だった日付の草は埋まらなかった。
たぶん理由はこれです。
- Squash merge だった（マージ日1日分に集約された）
- そもそも feature ブランチのまま で、main に入っていなかった repo もあった
- プライベート repo の 表示設定 が OFF だった
「マージすれば草が生える」は半分正しくて、半分間違いでした。
- main に入る → 草の前提条件 ✅
- 日付ごとに埋まる → Squash だと ❌
- プロフィールに見える → プライベート設定次第
作業そのものが消えたわけではない。
でも 「ぱっと見何もしていない日が数日できている」 という意味では、かなり残念な体験でした。
これからやること
リポジトリ設定
✅ Allow merge commits … ON（これを使う）
❌ Allow squash merging … OFF（押し間違い防止）
✅ Include private contributions … ON（プライベート repo 用）
マージの習慣
- 機能が 動く単位 で PR → Create a merge commit でマージ
- 「草のためだけに壊れた main を作る」のは避ける
- 「1機能できたらマージ」の方が、草も履歴もきれい
心の持ち方
草は モチベーションの可視化 には便利ですが、
学習の成果そのものではありません。
- コミット履歴
- PR
- 動くアプリ
- 本番環境
こっちにはちゃんと残っています。
ただ、ルールを知らないまま損をするのはもったいない ので、
今回の設定変更はしておいて正解だと思います。
まとめ
| 思っていたこと | 実際 |
|---|---|
| push すれば草に載る | ❌ main に入ったコミットだけ |
| マージすれば空白の日が埋まる | ❌ Squash だとマージ日1日分 |
| 過去 repo をマージすれば草が増える | △ マージ方法と設定次第 |
| 作業は GitHub に反映されていない | ❌ ブランチには載っている |
遅れて気づいたけど、これからは merge commit でこまめに main に入れていこう。
同じように「草が増えない…」と悩んでいる人の参考になれば嬉しいです。
おまけ：自分用チェックリスト
マージ前にこれだけ見る。
- デフォルトブランチは main か
- マージ方法は Create a merge commit か（Squash じゃないか）
- コミットメールは GitHub で認証済みか
- プライベート repo なら private contributions 表示は ON か
- アプリは起動する状態か
書いた日: 2026年7月3日
きっかけ: Spring Boot ポートフォリオの feature/skill-record-edit 開発中