はじめに
CARTA ZERO でエンジニアをしている25卒のtoyamaです!
この記事はCARTAアドベントカレンダー2025の24日目の記事です。
自分はdotfilesと呼ばれるホームディレクトリ直下に.から始まるファイル群を普段からGitHubで管理しています。今回は2025年にdotfilesにどんな変化があったのかコミット履歴を元に振り返ってみました!
TL; DR
- 社会人1年目の生活リズムとdotfilesのコミット数の相関を分析
- Nixの導入、Neovimでのgithubの操作や起動速度改善などのアップデートを行った
コミット数と月分布
基本的なコミット数や各月の推移をコミットログから調べてみました! 2024年のコミット数が446件に対して2025はそれよりも多かったのが驚きでした。 社会人になって平日の業務と休日のオンオフ境目がよりはっきりしてオフに集中してdotfilesの改善に取り組めるようになったのも要因な1つな気がしてます。 4~6月,10月は環境の変化に慣れなかったり忙しかった時期で、dotfilesのコミット数にもそれが反映されている気がしますね。?
2025年 総コミット数: 505件 月別コミット推移 Jan ████████████ 57件 Feb █████████████ 61件 Mar ████████ 40件 Apr ███████ 33件 May ███████ 33件 Jun ████ 20件 Jul ████████████ 59件 Aug ███████████ 55件 Sep ████████ 38件 Oct █████ 27件 Nov ████████ 41件 Dec ████████ 41件 ------------ 2024年 総コミット数: 446件
2025年の主な変化ポイント
コミットログを見ると年間を通して様々な変更を行ったのですが、 その中でも主用な変化ポイントをいくつか紹介できたらと思います！
Nixの導入
dotfilesの環境構築にNixという純粋関数型パッケージマネージャーを導入しました。 Nixの特徴として再現性の高さと宣言的な環境管理があります。 従来のパッケージマネージャーでは、 システム上のライブラリ、環境変数、グローバルな設定など 開発環境にたまたま存在していた要素に暗黙的に依存し、 「手元では動くが他の環境では動かない」という問題が起こり得ます。 一方、Nixはビルドプロセスをサンドボックス内で実行し、 必要な依存関係（ライブラリ、ビルドツール、その依存関係まで）を すべてハッシュ値付きの独立したパスで管理します。 これにより暗黙的な依存が発生せず、高い再現性が保証されます。
また環境の状態を宣言的に管理できます。 自分は普段Mac 2台とLinux 1台の計3台のPCを仕事とプライベートで使っているのですが、 Nixで設定を書いておけばコマンド一発で統一した環境を再現できます。 OS固有のツールやGUIアプリケーションなど一部OS依存の部分は 設定ファイルを分けることで、それぞれの環境に適した構成が反映されます。
使って特に便利だと思ったのがnix-darwinです。 これを使うとMacのシステム設定をコードで宣言的に管理できます。 例えばキーリピートの速度、Dockに表示するアプリケーション、 スクリーンショットの保存先などをすべてコードで管理できるようになりました。 nix-darwinのマニュアルを 眺めている中で「こんな設定もできるのか」という発見も多く、 自分の知らなかった設定に出会えたのも良かった点です。
Neovimの起動速度の高速化
自分は普段からNeovimというテキストエディタを常用しています。 ターミナルで特定のディレクトリに移動してエディタを起動という流れを 1日に何回か行うため、起動速度は速ければ速いほど嬉しいです。 使い始めて約1年が経ちプラグインが100個以上になった頃、 起動に0.4秒ほどかかるようになっていました。 この時間は地味に気になりました。
そこでプラグインマネージャー lazy.nvimの 遅延ロード機能を使って高速化に取り組みました。 まずどのプラグインのロードに時間がかかっているかを特定し、 起動直後には不要なプラグインを遅延ロードするよう設定を変更していきました。 ただしプラグインAを遅延ロード設定しても起動時ロードのプラグインBがAに依存している場合、 Aも起動時に読み込まれてしまいます。 どのプラグインが何に依存しているのかどれが起動時ロードされているのかを調べながら、 依存関係を整理していく作業は少し手間がかかった覚えがあります。
結果的に起動時間を0.4秒から0.1秒未満にまで短縮できました。 体感でも結構速くなっているのを感じられました。 まだ最適化の余地はあると思うのでもっと速くしていきたいですね。
GitHubをNeovim上で操作する
入社してからGitHubのIssueを書く機会がかなり増えました。 チームでは作業ログをIssueに残すのを基本としているため日々Issueの作成や書き込みを頻繁に行います。 NeovimでGitHubのIssueやPRを快適に書ければもっと効率が上がるのではと思い、 プラグインの導入や設定のカスタマイズを行いました。
上記を実現するためにNeovim上でGitHubのIssueやPRを操作できるプラグインOcto.nvimを導入しました。
Octo.nvimはghコマンドを経由してGitHub APIと通信します。
内部でGraphQLクエリを使ってIssueやPRのデータを取得し、
それをNeovimのバッファ上で編集可能な形式に変換して表示します。
主に以下のような機能があります。
- Issue/PRの一覧表示、作成、編集
- コメントの追加・削除
- レビュー機能
- リアクションの追加
Octo.nvimを活用して Issue,PRのタイトルに絞り込んで検索を行うキーマップなどを設定しています。 以下がその例です。
vim.keymap.set("n", "<leader>oit", function() local query = vim.trim(vim.fn.input("Search in title: ")) if query == "" then vim.notify("Search query cannot be empty.", vim.log.levels.ERROR) return end local result = vim .system({ "gh", "repo", "view", "--json", "nameWithOwner", "-q", ".nameWithOwner", }, { text = true, }) :wait() if result.code ~= 0 then vim.notify("Error getting current repo: " .. result.stderr, vim.log.levels.ERROR) return end local current_repo = vim.trim(result.stdout) vim.cmd("Octo search repo:" .. current_repo .. " " .. query .. " in:title") end, { desc = "Octo: Search by title" })
他にも色々設定をしていたんですがそれはまた別の記事で書けたらと思います!
おわりに
振り返ってみて結果的にNeovimの設定に結構寄ってしまったのを感じました笑。 dotfilesは「環境をすぐに再現できる」という側面もありますが、 フィードバックサイクルを回せる側面もあるのかなと思っています。 日々作業の中で「ここが不便だな」と気づき、設定を変更して改善しまた使う。 今回は比較的大きめ変更をいくつか取り上げましたが、 shellの設定ファイルへのエイリアスの追加やキーマップの追加のような小さな改善も気軽にできます。 自分自身がユーザーとなってフィードバックサイクルを回せるのもdotfilesのいい所かなと思います。 継続的にフィードバックサイクルを回し改善を続けるのは、 dotfilesに限らず働いていく上でも重要だと思っているので 2026年も日々の小さな改善を積み重ねていきたいです!
