開発者が知っておくべき5つのGit Dotファイル

ほとんどの開発者は.gitignoreに馴染みがありますが、Gitの設定エコシステムはそれよりもはるかに奥深いものです。ホームディレクトリやプロジェクトルートに散在する、いくつかの重要なGit dotファイルが、リポジトリの動作、コラボレーターがコードベースを体験する方法、そしてGitがマシン間でどれだけ一貫して動作するかを静かに形作っています。これらを理解することで、微妙なバグ、乱雑な履歴、コラボレーションの摩擦から解放されます。

ここでは、よく知っておく価値のある5つのGit設定ファイルを紹介します。

1. .gitconfig — あなた個人のGitアイデンティティと動作設定

配置場所: ~/.gitconfig (グローバル) または .git/config (リポジトリレベル)

.gitconfigは、ユーザーアカウントの主要なGit設定ファイルです。名前、メールアドレス、デフォルトエディタ、エイリアス、動作設定が保存されます。Gitの設定は複数のレベルで存在できます:system、global、local (repository)、そしてオプションでworktreeがあり、より具体的な設定が広範な設定を上書きします。

実際のdotfileセットアップから借用した実用的なパターン:~/.gitconfigを共有設定用に保持し、includeIfディレクティブを使用してマシン固有または仕事固有のオーバーライドを読み込むことで、メイン設定を汚染せずに済みます。

[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig_work

これにより、dotファイルの移植性を保ちながら、マシンごとの違いに対応できます — シンプルなシンボリックリンクアプローチでは綺麗に処理できないことです。条件付き設定の詳細については、公式のGit設定ドキュメントで学ぶことができます。

2. .gitignore — 未追跡ファイルをインデックスから除外する

配置場所: プロジェクトルート、サブディレクトリ、または ~/.config/git/ignore (グローバル)

.gitignoreは未追跡ファイルにのみ影響します。リポジトリに既にコミットされたファイルは削除されません。これは混乱の一般的な原因です — コミット済みファイルの追跡を停止する必要がある場合は、無視ルールが有効になる前に、まずgit rm --cached <file>を実行する必要があります。

グローバルに無視したいファイル — エディタのスワップファイル、.DS_Store、OSのサムネイルなど — については、.gitconfigのcore.excludesFileでグローバル無視ファイルを設定します:

[core]
  excludesFile = ~/.config/git/ignore

これにより、プロジェクトの.gitignoreファイルをクリーンに保ち、各開発者の個人的なエディタ設定で散らかすのではなく、プロジェクト固有の除外に集中できます。Gitの公式gitignoreドキュメントでは、マッチングルールと優先順位について詳しく説明されています。

3. .gitattributes — 改行コード以上のもの

配置場所: プロジェクトルート(リポジトリにコミット)

.gitattributesは、最も活用されていないGit dotファイルの1つです。確かに改行コードの正規化(text=auto)を処理しますが、以下のことも制御します:

• マージ動作 — 特定のファイルタイプのマージ方法を設定
• バイナリファイル処理 — 特定のファイルタイプをdiffやマージしないようGitに指示
• エクスポート動作 — export-ignoreを使用してgit archive出力からファイルを除外(CIアーティファクトに便利)
• diffドライバー — .docxやminify化されたJSなどの形式に人間が読みやすいdiff出力を割り当て

フロントエンドプロジェクトでは、ロックファイルやバンドルされたアセットに適切な属性をマークすることで、不要なマージコンフリクトやdiffノイズを防ぎます。属性と動作の全範囲は、公式のgitattributesドキュメントで説明されています。

4. .git-blame-ignore-revs — フォーマットコミット後のblameをクリーンアップ

配置場所: プロジェクトルート(リポジトリにコミット)

PrettierやESLintのようなフォーマッターをコードベース全体で実行すると、git blameはほとんど役に立たなくなります — すべての行が元の作成者ではなく、フォーマットコミットを指すようになります。

.git-blame-ignore-revsがこれを解決します。blameでスキップしたい完全なコミットSHAをリストアップします:

# Prettier formatting pass
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

次に、これを使用するようGitを設定します:

git config blame.ignoreRevsFile .git-blame-ignore-revs

GitHubはこのファイルを自動的に認識します。コードレビューや履歴の可読性に大きな影響を与える小さな追加です。この動作は公式のgit blameドキュメントに記載されています。

5. .mailmap — コントリビューターのアイデンティティを正規化

配置場所: プロジェクトルート(リポジトリにコミット)

コントリビューターはメールアドレスを変更したり、マシン間で異なる名前を使用したり、Gitを適切に設定する前にコミットを行ったりします。.mailmapを使用すると、プロジェクトの履歴全体でこれらのアイデンティティを正規化できます。

Jane Smith <jane@company.com> <jane@oldmail.com>

git shortlogやgit logなどのコマンドは、基礎となるコミット履歴を変更することなく、修正されたアイデンティティを反映します。この機能は、コントリビューターのアイデンティティが時間とともに進化するオープンソースプロジェクトや長期運用リポジトリで特に有用です。形式と動作は公式のmailmapドキュメントで説明されています。

まとめ

これら5つのGit dotファイル — .gitconfig、.gitignore、.gitattributes、.git-blame-ignore-revs、.mailmap — は、それぞれ実際の開発ワークフローにおける異なる問題を解決します。これらは単なる個人的な好みの問題ではありません。そのうちのいくつかは、リポジトリに直接コミットすることで、チームのすべてのコントリビューターの体験を向上させます。最も差し迫った問題点に対処するものから始めれば、Gitワークフローが目に見えてクリーンになるでしょう。

よくある質問

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.