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プロセスを実行します。各実行では、「hourly」タスクが実行されます。真夜中になると、そのプロセスは「daily」タスクも実行します。週の最初の日の真夜中になると、そのプロセスは「weekly」タスクも実行します。単一のプロセスは、登録された各リポジトリを繰り返し処理し、その頻度に対するスケジュールされたタスクを実行します。登録されているリポジトリの数とそれらのサイズによっては、このプロセスは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 実行可能ファイルの完全パスを指定して、実行された git コマンドが、PATH に関係なく、git maintenance start が発行されたものと同じであることを保証します。同じユーザーが複数の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 でタイマーを再度開始するため、カスタマイズは、.conf サフィックスのファイルを ~/.config/systemd/user/git-maintenance@.service.d ディレクトリに作成することによって行う必要があります。

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ファイルの1つをエディターで開き、<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]スイートの一部