git-maintenance - Gitリポジトリデータを最適化するためのタスクを実行

Gitリポジトリデータを最適化するためのタスクを実行し、他のGitコマンドの高速化とリポジトリのストレージ要件の削減を実現します。

git addやgit fetchなど、リポジトリデータを追加するGitコマンドは、応答性の高いユーザーエクスペリエンスのために最適化されています。これらのコマンドはGitデータの最適化に時間をかけません。なぜなら、このような最適化はリポジトリ全体のサイズに比例するのに対し、これらのユーザーコマンドはそれぞれ比較的小さな操作を実行するためです。

git maintenanceコマンドは、Gitリポジトリを最適化するための柔軟性を提供します。

git maintenanceコマンドは、Gitコマンド実行中のユーザーの待ち時間を最小限に抑えつつ、リポジトリのメンテナンスパターンを簡素化するように設計されています。このプロセスをカスタマイズできるように、様々な設定オプションが用意されています。デフォルトのメンテナンスオプションは、大規模なリポジトリでも迅速に完了する操作に焦点を当てています。

ユーザーは、スケジュールされたメンテナンス・タスクが意図したほど頻繁に実行されないケースがあることに気づくかもしれません。各git maintenance runコマンドは、リポジトリのオブジェクトデータベースにロックをかけ、これにより、同じリポジトリで他の同時実行中のgit maintenance runコマンドが実行されるのを防ぎます。この保護がなければ、競合するプロセスがリポジトリを予測不能な状態にする可能性があります。

バックグラウンドメンテナンススケジュールは、1時間ごとにgit maintenance runプロセスを実行します。各実行は「毎時」タスクを実行します。真夜中には、そのプロセスは「毎日」タスクも実行します。週の最初の日の真夜中には、そのプロセスは「毎週」タスクも実行します。単一のプロセスが、各登録済みリポジトリを繰り返し処理し、その頻度でスケジュールされたタスクを実行します。プロセスは、複数のクライアントが生成する負荷（例えばプリフェッチから）を分散させるために、クライアントごとにランダムな分にスケジュールされます。登録されたリポジトリの数とそのサイズによっては、このプロセスが1時間以上かかる場合があります。この場合、複数のgit maintenance runコマンドが同じリポジトリで同時に実行され、オブジェクトデータベースのロックで衝突する可能性があります。これにより、2つのタスクのどちらかが実行されない結果となります。

メンテナンスウィンドウが完了するまでに1時間以上かかる場合は、メンテナンス・タスクの複雑さを減らすことを検討してください。たとえば、gcタスクはincremental-repackタスクよりもはるかに遅いです。ただし、これはオブジェクトデータベースがわずかに大きくなるという代償を伴います。より高価なタスクの実行頻度を下げることを検討してください。

上級ユーザーは、git maintenance startおよびGit設定オプションで利用できるものとは異なるスケジュールで独自のメンテナンス・タスクをスケジュールすることを検討できます。これらのユーザーは、オブジェクトデータベースロックと、同時実行されるgit maintenance runコマンドの動作を認識しておく必要があります。さらに、git gcコマンドはgit maintenance runコマンドと組み合わせるべきではありません。git gcはオブジェクトデータベースを変更しますが、git maintenance runと同じ方法ではロックを取得しません。可能であれば、git gcの代わりにgit maintenance run --task=gcを使用してください。

以下のセクションでは、git maintenance startによってバックグラウンドメンテナンスを実行するために設けられたメカニズムと、それらをカスタマイズする方法について説明します。

POSIXシステムでバックグラウンドタスクをスケジュールするための標準的なメカニズムはcron(8)です。このツールは、指定されたスケジュールに基づいてコマンドを実行します。ユーザーがスケジュールしたタスクの現在のリストは、crontab -lを実行することで確認できます。git maintenance startによって書き込まれるスケジュールは、以下のようになります。

コメントは、Gitによって書き込まれたスケジュールを示す領域として使用されます。この領域内で行われた変更は、git maintenance stopによって完全に削除されるか、git maintenance startによって上書きされます。

crontabエントリは、実行されるgitコマンドが、PATHとは無関係にgit maintenance startが発行されたものと同じであることを保証するために、git実行可能ファイルのフルパスを指定します。同じユーザーが複数のGit実行可能ファイルでgit maintenance startを実行した場合、最新の実行可能ファイルのみが使用されます。

これらのコマンドは、git for-each-repo --config=maintenance.repoを使用して、マルチバリューのmaintenance.repo設定オプションにリストされている各リポジトリでgit maintenance run --schedule=<frequency>を実行します。これらは通常、ユーザー固有のグローバル設定からロードされます。次に、git maintenanceプロセスは、maintenance.<task>.schedule設定オプションを使用して、各<frequency>で各リポジトリでどのメンテナンス・タスクを実行するように設定されているかを決定します。これらの値は、グローバルまたはリポジトリの設定値からロードされます。

設定値が目的のバックグラウンドメンテナンススケジュールを達成するのに不十分な場合は、独自のスケジュールを作成できます。crontab -eを実行すると、エディタがユーザー固有のcronスケジュールを読み込みます。そのエディタで、独自のスケジュール行を追加できます。前述のデフォルトスケジュールを参考に始めることもできますし、高度なスケジューリング技術についてはcrontab(5)ドキュメントを読むこともできます。スケジュールで正しいバイナリが実行されていることを確認するために、必ずデフォルトスケジュールからのフルパスと--exec-pathテクニックを使用してください。

Linuxはcronをサポートしていますが、ディストリビューションによっては、cronは必ずしもインストールされているとは限らないオプションのパッケージである場合があります。最新のLinuxディストリビューションでは、systemdタイマーがそれを置き換えています。

ユーザーのsystemdタイマーが利用可能であれば、cronの代替として使用されます。

この場合、git maintenance startはユーザーのsystemdタイマーユニットを作成し、タイマーを開始します。ユーザーがスケジュールしたタスクの現在のリストは、systemctl --user list-timersを実行することで確認できます。git maintenance startによって書き込まれるタイマーは以下のようになります。

--schedule=<frequency>オプションごとに1つのタイマーが登録されます。

systemdユニットの定義は、以下のファイルで確認できます。

git maintenance startはこれらのファイルを上書きし、systemctl --userでタイマーを再度開始します。したがって、カスタマイズは、~/.config/systemd/user/git-maintenance@.service.dディレクトリに.confサフィックスの付いたドロップインファイルを作成することで行うべきです。

git maintenance stopは、ユーザーのsystemdタイマーを停止し、上記のファイルを削除します。

詳細については、systemd.timer(5)を参照してください。

macOSは技術的にはcronをサポートしていますが、crontab -eを使用するには昇格された権限が必要であり、実行されるプロセスには完全なユーザーコンテキストがありません。完全なユーザーコンテキストがない場合、Gitとその認証ヘルパーは保存された認証情報にアクセスできないため、一部のメンテナンス・タスクは機能しません。

代わりに、git maintenance startはlaunchctlツールと対話します。これはmacOSで時間指定ジョブをスケジュールするための推奨される方法です。git maintenance (start|stop)を介したメンテナンスのスケジュールには、macOS 10.11以降でのみ利用可能なlaunchctl機能が必要です。

ユーザー固有のスケジュール済みタスクは、XML形式の.plistファイルとして~/Library/LaunchAgents/に保存されます。現在登録されているタスクは、次のコマンドで確認できます。

--schedule=<frequency>オプションごとに1つのタスクが登録されます。XML形式が各スケジュールをどのように記述しているかを確認するには、これらの.plistファイルのいずれかをエディタで開き、<key>StartCalendarInterval</key>要素に続く<array>要素を調べてください。

git maintenance startはこれらのファイルを上書きし、launchctlでタスクを再度登録するため、カスタマイズは独自の.plistファイルを異なる名前で作成することで行うべきです。同様に、git maintenance stopコマンドはlaunchctlでタスクの登録を解除し、.plistファイルを削除します。

バックグラウンドタスクをより高度にカスタマイズする方法については、launchctl.plist(5)を参照してください。

Windowsはcronをサポートしておらず、代わりにバックグラウンドタスクをスケジュールするための独自のシステムを持っています。git maintenance startコマンドは、schtasksコマンドを使用してこのシステムにタスクを送信します。タスクスケジューラアプリケーションを使用して、すべてのバックグラウンドタスクを検査できます。Gitによって追加されたタスクは、Git Maintenance (<frequency>)の形式の名前を持っています。タスクスケジューラのGUIにはこれらのタスクを検査する方法がありますが、タスクをXMLファイルにエクスポートして詳細を表示することもできます。

Gitはコンソールアプリケーションであるため、これらのバックグラウンドタスクは現在のユーザーに表示されるコンソールウィンドウを作成することに注意してください。これは、タスクスケジューラで「ユーザーがログオンしているかどうかに関わらず実行」オプションを選択することで手動で変更できます。この変更にはパスワード入力が必要なため、git maintenance startはデフォルトでは選択しません。

バックグラウンドタスクをカスタマイズしたい場合は、将来のgit maintenance (start|stop)呼び出しがカスタムタスクを上書きしないように、タスクの名前を変更してください。

このセクションのこの行より下はすべて、git-config[1]ドキュメントから選択的に含まれています。内容はそちらにあるものと同じです。

git[1] スイートの一部