【Git】git archiveとは？使い方や活用例を初心者向けに解説

Web開発•2025/2/20

Git

はじめに

Gitを使ってチーム開発や個人開発を進めている皆さんは、リポジトリの内容をどのように共有しているでしょうか。

一般的にはGitHubなどのリモートリポジトリを使ってメンバー同士でコードを共有することが多いかもしれません。

しかし、クライアントなど社外の方にソースコードの一部だけを渡したい場合や、バージョン管理フォルダを含めずにコードをまとめたい場合があるのではないでしょうか。

そんなときに役立つのが git archive です。

git archiveを使えば、リポジトリの状態を圧縮ファイルとしてまとめることができます。

この仕組みを理解しておけば、状況に応じて柔軟にソースコードを配布できるようになります。

ここでは、初心者の方にもわかりやすいように、git archiveの基本的な使い方から、実務での活用シーン、注意点までを解説します。

短いコマンドで完結できるため、慣れてしまえば簡単です。

ぜひ参考にしてみてください。

この記事を読むとわかること

git archiveの基本的なコマンドの使い方
特定のブランチやコミットをまとめて圧縮する方法
実務で役立つ活用シーンの例
注意点やトラブルシューティングの考え方

git archiveとは？

git archiveは、Gitリポジトリの指定した状態をzipやtarといった形式でまとめる機能です。

リポジトリをそのままzipにする方法としてはOSの右クリックメニューや外部の圧縮ツールもあります。

しかし、そうした方法では.gitフォルダが含まれたり、特定ディレクトリだけを抜き出すのが面倒だったりすることがあります。

一方でgit archiveを使うと、バージョン管理情報（.gitフォルダなど）を含めずに特定のブランチやコミットのソースコードだけを抽出できます。

これにより、外部に渡すファイルの取り扱いがシンプルになるのがメリットです。

たとえば、リポジトリ内の不要なディレクトリを除外しながら圧縮できることもあります。

それによって、共有相手に必要以上の情報を渡さずに済む場合があります。

また、環境設定ファイルや機密情報を意図せず含めないようにするための工夫もしやすいです。

初心者の方には、まずリポジトリの状態を安全にまとめたい場合に活用しやすいコマンドとして覚えていただけるとよいでしょう。

git archiveの基本コマンド

ここでは、git archiveの基本的な使い方を確認します。

操作方法そのものはシンプルですが、いくつかオプションがありますので順番に見ていきましょう。

全体をtar形式でまとめる

まずは、現在のブランチ（例えばmainブランチ）の最新コミットを、tarファイルとしてまとめる例です。


git archive --format=tar --output=output.tar HEAD

--format=tar はtar形式でアーカイブを作成するオプションです。
--output=output.tar は出力先のファイル名を指定しています。
HEAD は現在チェックアウトしているブランチの最新コミットを表します。

このコマンドを実行すると、mainブランチ（作業中のブランチ）の内容がoutput.tarにまとめられます。

中にはGit管理情報が含まれないので、純粋にソースコードや必要なファイルだけがtar形式のアーカイブになります。

zip形式でまとめる

zip形式のファイルにしたい場合は、--format=zip と指定すればOKです。


git archive --format=zip --output=output.zip HEAD

tarとzipの使い分けは、受け取り側の環境や慣れに合わせるとよいでしょう。

Windowsユーザーの場合、zipが扱いやすいことも多いです。

特定のコミットやタグを指定

実務でしばしばあるケースとして、「少し前のコミットの状態を圧縮して共有したい」ということがあるかもしれません。

その場合、HEADの代わりにコミットのハッシュ値やタグ名を指定します。


# 例: コミットハッシュ(頭数文字)を指定
git archive --format=zip --output=old_version.zip 3f2a9c

# 例: タグを指定
git archive --format=tar --output=release_v1.tar v1.0

タグを使えば、特定バージョンのソースコードをまとめることが簡単です。

リポジトリ内のサブディレクトリだけをアーカイブ

リポジトリ内の特定フォルダだけをまとめたい場面もあります。

プロジェクトが大きくなってくると、全体ではなく一部を抽出したいこともあるでしょう。

そんなときは、tree-ishの形式を使います。


git archive --format=zip --output=frontend_only.zip HEAD frontend/

HEAD frontend/ のようにフォルダを指定することで、frontend ディレクトリだけを抽出したzipが生成されます。

これにより、プロジェクトの一部だけを相手に渡したい場合などに便利です。

余計なファイルやフォルダを含めたくないときには有効でしょう。

実務での活用シーン

git archiveが活きるのは、外部への安全なコード共有や一部フォルダの抽出をしたいときです。

ここでは具体的にどんなシーンが想定されるか、一例を紹介します。

クライアントへの納品

ウェブサイトなどの制作を請け負っていると、完成後にソースコードをクライアントへ納品しなくてはならない場合があります。

ただし、リポジトリの中にはテスト用のファイルや機密情報を含むディレクトリがあるかもしれません。

そんなときにgit archiveを使って、必要部分だけを圧縮すれば、クライアントが混乱するような余計なファイルを含めずに済みます。

別のチームとの連携

同じ組織であっても、開発チーム以外の人にソースコードを渡す場面では、.gitフォルダまで含む完全なクローンでは扱いづらいことがあります。

git archiveを使って渡したい内容だけをまとめれば、相手が必要なところだけを簡単に確認できるでしょう。

リポジトリの一部を分割して新プロジェクトに流用

リポジトリの一部だけを別プロジェクトに流用したい場合もあるかもしれません。

フォルダ構造をそのまま別の場所に複製しようとすると、不要なファイルが混在することがあります。

git archiveで特定のディレクトリだけをアーカイブにしておけば、余計なゴミを含まない状態で移行できます。

.gitattributesを使った特定ファイルの除外

git archiveは、.gitattributes ファイルを使ってさらに細かい制御を行えます。

たとえば、アーカイブから除外したいファイルがある場合、.gitattributes でエクスポート対象外に設定が可能です。

以下は例です。

secret.env export-ignore
docs/* export-ignore

このように書いておくと、secret.env や docs フォルダ配下のファイルは、git archiveの結果には含まれなくなります。

設定ファイルを用いて制御できるため、チーム全員がルールを共有しやすいのが利点です。

また、外部に公開してはいけないAPIキーや機密情報などが含まれたファイルをうっかり含めるリスクを減らすことにもつながるでしょう。

git archiveとgit cloneの違い

初心者の方の中には「リポジトリをまとめるなら、圧縮する前にgit cloneすればいいのでは？」と感じる方もいるかもしれません。

もちろん、git cloneでもリポジトリを丸ごと複製できますが、以下のような差があります。

git clone
- .gitディレクトリを含む
- 全ての履歴データを取得する
- 受け取り側がそのままバージョン管理を続けられる
git archive
- .gitディレクトリを含まない
- 選択したコミットやサブフォルダのみを圧縮して出力
- 受け取り側はアーカイブを解凍すれば、その瞬間のソースコードだけを入手できる

開発に参加する人に渡すのであれば、git cloneのほうが適しているケースもあるでしょう。

しかし、単にコードを確認するだけのケースや、納品用として履歴を含めずに配布したいケースでは、git archiveを使うメリットが大きいです。

状況によって使い分けることが大事です。

トラブルシューティング

git archiveはシンプルに使える一方、オプションの指定を間違えたり、意図せず必要ファイルが除外されてしまうなどのトラブルが起きる可能性があります。

ここでは、ありがちなトラブル例を挙げてみます。

アーカイブ後のファイルが足りない

「必要なディレクトリを指定し忘れていた」「.gitattributesでexport-ignoreを設定していた」などの理由で、ファイルが足りないケースが考えられます。

この場合は、.gitattributes やコマンドオプションの指定を再確認してください。

binaryファイルの取り扱い

バイナリファイルが混ざっているリポジトリをarchiveすると、元のサイズが大きくなることがあります。

また、エディタによってはバイナリの扱いが異なる場合もあります。

この点はgit archive自体の問題ではありませんが、圧縮後のファイルサイズを確認し、zip形式など適切なフォーマットを選ぶなどの対処を検討するとよいでしょう.

パーミッションの扱い

tar形式でまとめた場合には、LinuxやMacのような環境でファイル権限（読み書き実行）がそのまま反映される場合があります。

ただし、zip形式だとWindows環境ではパーミッション情報が無視されることがあります。

運用環境によっては注意が必要です。

もしパーミッションが重要なシステムファイルを扱うケースでは、アーカイブ形式がファイル権限をどう扱うかチェックしてみてください。

注意点

git archiveを実務で使うとき、いくつか留意すべきポイントがあります。

大きすぎるリポジトリでは時間がかかる

リポジトリが非常に大きい場合、アーカイブに要する時間も増えます。

ソースコードや静的ファイルの量が増えすぎると、意図せず容量の大きなアーカイブになってしまうかもしれません。

アーカイブを作る前に、本当に必要なファイルだけをまとめるかをあらかじめ決めるとよいでしょう。

コミットの選び間違いに注意

git archiveでは、コミットハッシュやタグ、ブランチ名などを正しく指定する必要があります。

慌ててタグ名を間違えると、想定とは異なるバージョンをアーカイブしてしまうことがあるかもしれません。

履歴が必要な場合はcloneを検討する

git archiveは、履歴情報を含まない状態の圧縮です。

過去のコミット履歴やブランチ構造を一緒に渡す必要がある場合は、やはりgit cloneによってリポジトリ全体を受け渡す方が適しています。

どちらが必要かは、作業の目的によって判断するのがよいでしょう.

さらに安全に共有する方法

ソースコードを外部に渡すときは、機密情報が含まれたファイルをうっかり残していないか注意を払いたいところです。

以下のように、初歩的なチェックはこまめに行うと安心できます。

リポジトリ内で APIキー や 認証情報 が管理されているファイルがないか
.gitignore や .gitattributes の設定で除外するはずのファイルが含まれていないか
アーカイブを解凍した後のサイズ・ファイル数に異常がないか

また、git archiveはあくまでコードをまとめる方法です。

もし重要度の高い情報が混ざっていそうなら、アーカイブ前にそれを除去する仕組みや、アクセス権の管理を徹底することも検討してください。

秘密のトークンやAPIキーをコード内にハードコーディングしている場合、export-ignoreなどの設定をしても管理がしきれない可能性があるので要注意です。

まとめ

git archiveを使うと、リポジトリの状態を指定した形式（tarやzip）でまとめて取り出すことができます。

.gitフォルダを含めないので、不要なバージョン管理情報を外部に渡すリスクを軽減できる
特定フォルダや特定のコミットだけを抜き出せるため、柔軟に共有が可能
.gitattributes との組み合わせで、秘密情報や不要ファイルのエクスポートを簡単に除外できる

実務では、クライアントへのソースコード納品や、リポジトリの一部を別の場所で再利用する際に便利なテクニックです。

ぜひ、必要に応じて活用してみてください。