どの Dotfiles を Git にコミットすべきか(そして何を無視すべきか)

複数のマシン間で dotfiles を管理することは、開発者にとってよくある頭痛の種です。シェルの設定、エディタの設定、ツールの設定を完璧に仕上げるのに何時間も費やしてきたでしょう。しかし、どのファイルをバージョン管理に含めるべきでしょうか?さらに重要なのは、機密データを公開したり、メンテナンスの悪夢を作り出したりすることなく、それらを同期する方法です。

この記事では、最も人気のある2つの dotfiles 管理アプローチ(Git bare リポジトリと GNU Stow)を比較し、何をコミットすべきか、何をコミットすべきでないかを決定する重要なセキュリティ上の考慮事項について説明します。

コミットすべきもの:セキュリティ第一のアプローチ

管理方法を選択する前に、dotfiles リポジトリに何を含めるべきかを理解しましょう。黄金律:機密情報は絶対にコミットしない。

コミットしても安全なもの

• シェル設定(.bashrc、.zshrc、.config/fish/)
• エディタ設定(.vimrc、.config/nvim/)
• Git 設定(認証情報を含まない .gitconfig)
• ターミナルエミュレータ設定(.alacritty.yml、.config/kitty/)
• ウィンドウマネージャー設定(.config/i3/、.config/sway/)
• ツール設定(.tmux.conf、.config/starship.toml)

絶対にコミットしてはいけないもの

• SSH 秘密鍵(~/.ssh/id_*)
• API トークンと認証情報
• データベース接続文字列
• ライセンスキー
• ブラウザの Cookie やセッションデータ
• コマンド履歴ファイル(.bash_history、.zsh_history)

公開設定と機密情報が混在する設定ファイルの場合は、テンプレート化を使用するか、機密部分をローカルに保持される別のソースファイルに分離してください。

Git Bare リポジトリ:ミニマリストな方法

Git bare リポジトリアプローチは、ホームディレクトリを作業ツリーとして扱い、.git フォルダで散らかすことはありません。この方法は Git 以外の追加ツールを必要としません。

セットアップ手順

git init --bare $HOME/.dotfiles
alias config='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
config config --local status.showUntrackedFiles no

ファイルの管理

config add ~/.vimrc
config commit -m "Add vim configuration"
config push origin main

メリット:

• Git 以外の依存関係がゼロ
• シンボリックリンクなしの直接的なバージョン管理
• すべての Unix 系システムで同じように動作
• 中間保存場所が不要

デメリット:

• 機密ファイルを誤ってコミットしやすい
• .gitignore の規律が必要
• サブディレクトリ内の他の Git リポジトリと干渉する可能性
• モジュラー設定の整理が直感的でない

GNU Stow:整理されたアプローチ

GNU Stow はシンボリックリンクを通じて dotfiles を管理し、実際のファイルを専用ディレクトリに整理しながら、ホームフォルダ内の期待されるパスを維持します。

ディレクトリ構造

~/.dotfiles/
├── vim/
│   └── .vimrc
├── git/
│   └── .gitconfig
└── shell/
    ├── .bashrc
    └── .zshrc

デプロイ

cd ~/.dotfiles
stow vim git shell  # ~ にシンボリックリンクを作成

メリット:

• アプリケーションごとの明確でモジュラーな整理
• マシンごとの選択的デプロイが容易
• 組み込みの競合検出
• パッケージごとの無視ファイル(.stow-local-ignore)をサポート

デメリット:

• GNU Stow のインストールが必要
• 一部のアプリケーションはシンボリックリンクをうまく処理できない(systemd、特定のエディタ)
• アプリケーションがシンボリックリンクを上書きすると壊れる可能性
• 理解すべき追加の抽象化レイヤー

設定管理戦略の選択

Git bare リポジトリと GNU Stow のどちらを選択するかは、特定のニーズによって異なります:

Git bare リポジトリを使用する場合:

• 依存関係をゼロにしたい
• dotfiles が比較的シンプル
• 直接的なバージョン管理を好む
• Git の内部構造に精通している

GNU Stow を使用する場合:

• 複雑でモジュラーな設定を管理する
• アプリケーションごとの整理が必要
• 異なるマシンに異なる設定をデプロイする
• 視覚的なディレクトリ構造を好む

開発者の生産性のためのベストプラクティス

選択した方法に関係なく、以下のバージョン管理のベストプラクティスに従ってください:

1. .gitignore を積極的に使用する:* から始めて、明示的にファイルを許可する
2. 公開と非公開を分離する:機密設定用の非公開リポジトリを保持する
3. セットアップをドキュメント化する:インストールとデプロイの手順を含める
4. 新しいシステムでテストする:ブートストラッププロセスを定期的に検証する
5. 条件付き読み込みを使用する:OS 固有の設定を適切に処理する

チーム環境では、合理的なデフォルトを持つ別の「公式」設定リポジトリを維持し、ローカルオーバーライドによる個別のカスタマイズを許可することを検討してください。

まとめ

Git bare リポジトリと GNU Stow はどちらも dotfiles 管理の問題を効果的に解決します。選択は複雑さのニーズとツールの好みによって決まります。重要な要素は、どの方法を選択するかではなく、公開設定と機密データの厳格な分離を維持することです。セキュリティ第一の考え方から始め、ワークフローに合ったアプローチを選択すれば、セキュリティを損なうことなく開発者の生産性を向上させる、ポータブルでバージョン管理された環境を手に入れることができます。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.