同僚へ渡した集計ツールに不具合が見つかったとき、どのコードを配ったのか分からないと調査が難しくなります。Gitのタグを配布時のコミットへ付けておけば、そのとき記録したコードを名前から確認できます。
タグは配布ファイルを自動で作ったり相手へ送ったりするものではありません。「どのコミットを配るか」を固定し、実際に渡すファイルとREADMEのバージョンを照合するために使います。
配布前の変更をコミットする
タグが指すのはコミットです。作業中の変更や、まだGitへ追加していないファイルは、タグを付けるだけでは含まれません。練習用リポジトリでgit status --shortを見て、配布する変更を記録してから進めます。
次はv0.1.0という注釈付きタグを、その時点のコミットへ作る例です。既存のタグと同じ名前を使う操作ではありません。利用者の既存リポジトリではなく、練習用の履歴で確かめてください。
git status --short
git tag --list 'v0.1.0'
git tag -a v0.1.0 -m 'First practice release'
git show --stat v0.1.0
git rev-parse 'v0.1.0^{commit}'
最初の一覧に同名タグが出た場合は、新しく作る手順を止めます。-fを付けて既存タグを動かすと、同じ名前が以前と違うコードを指すため、配布済みの記録と食い違います。別のバージョンが必要なら新しい名前で残します。
注釈とコミットIDを照合する
-aは注釈付きタグを作る指定です。タグの説明を残せるので、コード変更のコミットメッセージとは別に、何を配布したかを記録できます。git show --statでタグの説明と対象の変更を読みます。
git rev-parse 'v0.1.0^{commit}'は、タグが指すコミットを確認するための指定です。このIDをREADMEや配布記録と対応させると、名前だけで取り違えていないかを調べられます。画面に出る実際のIDはそのリポジトリの履歴によって変わります。
タグを付けたあとにコードを修正した場合、その変更は元のタグへ自動で加わりません。新しいコードをコミットし、新しい配布名を決めてから、別のタグとして残します。タグ名だけ変え、未記録のファイルを同梱する運用は避けます。
実行環境は別に記録する
タグから同じPythonコードを取り出せても、依存ライブラリ、設定、入力ファイル、外部APIの状態まで同じになるとは限りません。READMEには対応するPythonのバージョン、必要な設定名、起動方法、試験用入力と期待結果も残します。
秘密を含む設定や顧客データを、再現性のためという理由でGitへ追加しないようにします。設定例と実際の値を分け、配布先で必要な情報をどこへ用意するかを説明します。タグは環境全体のバックアップの代わりではありません。
配る前に戻して動かす
配布予定のタグから取り出したコードを、別の練習場所で起動できるか確認します。普段の作業フォルダーにだけ存在するファイルへ依存していると、タグを残していても受け手の環境では動かない場合があります。
この例では隔離した練習用のコミットへタグを付け、参照するIDと説明を確認します。外部へのプッシュやファイル配布は行いません。実際に共有する際は、共有先、渡すファイル、バージョン、確認結果を一組で記録してください。
関連する記事
GitでPythonスクリプトを管理する基本｜戻せる作業環境を作る
Pythonスクリプトを配布する前に見ること｜設定ファイルとREADME
