なぜ数十億ドル規模のプロジェクトがいまだにメールでコードを受け取るのか？
GitHubの「Create Pull Request」ボタンに慣れている人にとって、メールでのコード送信は石器時代に戻ったように感じるかもしれません。しかし、Linuxカーネル（リリースごとに1万件以上のパッチ）、Git、PostgreSQLなどの「巨人」たちは、数十年にわたりメーリングリストを使い続けています。
私が初めてカーネルの小さなモジュールに貢献しようとした時、SMTPサーバーの設定だけで半日を費やしてしまいました。しかし、慣れてくるとその良さが分かります。すべての議論が軽量なメールスレッドに集約されます。重いブラウザを開く必要はありません。また、Git向けTerminal UIを活用すれば、過去の履歴確認もスムーズです。さらに重要なのは、このプロセスにより、開発者がコミットメッセージを丁寧に書かざるを得なくなることです。なぜなら、それが10〜20年後のプロジェクトのコンテキストを維持する唯一の手段だからです。
最初のパッチを送信するために、ゼロからgit send-emailを設定していきましょう。
クイックスタート：5分で最初のパッチを送信する
急いでいる方のために、Gmailをパッチの「中継基地」として使用する最短ルートを紹介します。
ステップ1：ツールのインストール
UbuntuやDebianでは、git send-emailはデフォルトのGitパッケージに含まれておらず、別のパッケージとして提供されています。
sudo apt update
sudo apt install git-emailステップ2：SMTPの設定（Gmailの例）
注意：Gmailのメインパスワードは使用できません。Googleアカウントにアクセスし、**アプリパスワード**を作成してください。その後、Gitに設定を読み込ませます：
git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser [email protected]
# ここで作成したアプリパスワードを使用します
git config --global sendemail.smtppass your-app-passwordステップ3：パッチの作成と送信
# 最後のコミットを.patchファイルに変換
git format-patch -1
# メンテナーにパッチを送信
git send-email [email protected] 0001-fix-something.patch標準的なワークフロー
プロフェッショナルなコントリビューターになるためには、ただ送るだけでは不十分です。メンテナーに貢献を無視されないよう、パッチシリーズ（patch series）の構成方法を理解する必要があります。
1. 価値のあるコミットメッセージを書く
メーリングリストの世界では、コミットメッセージこそが技術文書です。私は「何をしたか」よりも「なぜそうしたか」を説明することに多くの時間を割きます。また、将来のメンテナーが著者や時間でコミットを絞り込みやすくするために、50/72ルールを適用しましょう：タイトルは50文字以内、詳細は72文字で改行します。
subsystem: 変更内容の要約
なぜこの変更が必要なのかについての詳細な説明。
背景、バグレポートのリンク、パフォーマンスへの影響など。
Signed-off-by: Your Name <[email protected]>必須： Signed-off-byの行を決して忘れないでください。これはコミットメタデータを標準化し、ソースコードの著作権に関する法的確認（DCO）を行うためのものであり、Linuxカーネルでは非常に厳格に運用されています。
2. git format-patch の使用
このコマンドは、コミットを標準的なメール形式（RFC 2822）に変換します。5〜10件のコミットがある場合は、--cover-letterフラグを使用してください。これにより、変更の全体像を記述するための0000-cover-letter.patchファイルが作成され、レビュアーが目的を素早く把握できるようになります。
3. –annotate で再確認する
すぐに送信ボタンを押さないでください。私はgit send-emailを実行する際、常に--annotateフラグを使用します。これによりエディタ（Vim/Nano）が開き、メールの内容を確認したり、---行の下にコミット内容に影響を与えずにメモを追加したりできます。
応用：パッチのバージョン管理（リビジョン）
パッチが初回で承認されることは稀です。メンテナーは通常、修正や最適化を要求します。その際、Version 2 (v2)、Version 3 (v3)などを送信する必要があります。この際、Rebase後にコードを正確に「検証」するための手法が非常に役立ちます。
新しいバージョンの送信
ファイル名を手動で修正する代わりに、Gitの-vフラグに任せましょう：
git format-patch -v2 HEAD~1メールの件名は自動的に[PATCH v2] ...に変更されます。これにより、メンテナーのメールフィルタリングツールが自動的にパッチをグループ化できるようになります。
–in-reply-to の使用
会話を継続させるために、v2をv1の返信として送信します。古いメールからMessage-IDをコピーして実行するだけです：
git send-email --in-reply-to="v1のメール[email protected]" v2-0001-fix.patch「血の滲むような」経験と初歩的なミス
メンテナーから何度も指摘を受けた結果、プロフェッショナルでないと判断されないために注意すべき点をいくつかまとめました：
絶対にWebメールでパッチを送らない
パッチファイルの内容をコピーしてGmailやOutlookに貼り付けてしまう人が多いですが、これは致命的な間違いです。ブラウザは自動的に空白を変更したり（タブをスペースにするなど）、勝手に改行（ワードラップ）したりします。スペースが一つ違うだけでパッチは壊れ、メンテナーはgit amコマンドでコードを適用できなくなります。
自動エラーチェックスクリプトを実行する
Linuxカーネルでは、checkpatch.plというスクリプトが用意されています。送信前に以下のコマンドを実行してください：
./scripts/checkpatch.pl 0001-my-patch.patch行末の余計な空白や、不適切なインデント（カーネルはスペースではなくタブを使用します）など、非常に細かいミスを検出してくれます。
おわりに
git send-emailに慣れるまでは最初は面倒に感じるかもしれませんが、Gitを強化する手法を学び、規律ある思考と標準的な技術コミュニケーション能力を養うことは、プロフェッショナルなシステムプログラミングの世界への通行手形です。皆さんの最初のパッチが、世界のコアプロジェクトに無事マージされることを願っています！
