本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回はファイルを削除してGitの管理対象から外すことができる「git rm」コマンドです。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、基礎編に続き、ファイルを削除してGitの管理対象から外すことができる「git rm」コマンドです。削除したファイルを元に戻す方法について、幾つか例を挙げて解説します。
「git」は「Git」という分散型バージョン管理システム用のコマンドです。Gitは元々Linuxカーネルのソースコードを管理するために作られた「バージョン管理システム」で、現在は多くのソフトウェアやWebサイトのソースコード、ドキュメントの管理などに用いられています。
ソースコードを管理する際、最新版だけを保存するやり方はうまくいきません。開発中のさまざまなタイミングで状態を管理し、必要に応じて比較、参照したり、元に戻したりできるようにする仕組みが「バージョン管理システム」です。
Gitでは、テスト版など複数に枝分かれした状態も管理できます。複数のメンバーによる開発を前提としており、開発中の各時点におけるコメントや、コメントへの返信なども管理できるようになっています。
gitコマンドはほとんどの場合、「サブコマンド」と組み合わせて利用します(本連載ではgitとサブコマンドの組み合わせをコマンドとして紹介します)。
今回紹介する「git rm」コマンドは、ファイルをGitの管理対象から外します。インデックス(ステージングエリア)に追加したファイルの削除や、ワークツリーからの削除などを実行できます。
gitコマンドでは「リポジトリ(repository)」を使ってバージョンを管理します。リポジトリにはソースコードや変更履歴、コメントなどを一括して保管します。リポジトリには、自分のPC上に作る「ローカルリポジトリ」と、「GitHub」などのWebサービス上に作る「リモートリポジトリ」があり、両者を連携させることで複数の開発者による開発を1本にまとめることができます。
また、ローカルリポジトリのみで運用することも可能です。そのような運用をしているリポジトリにリモートリポジトリを追加したり、逆に、リモートリポジトリを削除したりするには、「git remote」コマンドを使用します。「git remote」コマンドには、さらに「add」や「remove」などのサブコマンドがあります。
既存のリポジトリ(リモートリポジトリ)にあるソースコードなどを入手したい場合は、まず、「git clone」(連載第381回)でリポジトリを自分の環境に複製します(※1)。リモートリポジトリの内容がバージョンアップされたら「git pull」(連載第382回)で最新版を取得します。開発に参加するのではなく、単に最新版を取得したいという場合は、「git clone」と「git pull」を利用すればよいでしょう。
※1 特定のファイルだけが欲しい場合、例えばGitHub(github.com)にあるリポジトリであれば「Raw」というボタンで表示されるURLを使い、「wget」コマンドなどを使ってダウンロードできる。この他、プロジェクト全体をダウンロードするためのリンクも用意されている([Clone or download]ボタン→「Download ZIP」)。
保管場所であるリポジトリに対し、ファイルの編集などを行う場所を「ワークツリー」「ワーキングエリア」「作業ツリー」などと呼びます。「git clone」や「git pull」で取得した最新版のファイルはワークツリーに配置されます。つまり「作業ディレクトリ」です。
ワークツリーで編集した結果をリポジトリに反映する操作を「コミット」と呼びます。「git add」(連載第384回)コマンドでコミットしたいファイルを「インデックス」あるいは「ステージングエリア」と呼ばれる領域に追加します。インデックスにはファイルの変更箇所などが記録されます。
インデックスの内容は「git commit」コマンドでローカルリポジトリにコミットされ、「git push」コマンドでローカルリポジトリの内容をリモートリポジトリに反映します。従って、「git add」や「git commit」などを行わなければ、自分の環境で編集した内容がリポジトリに影響を与えることはありません。自由に編集し、テストできます。なお、ワークツリーのファイルを過去の任意のコミット状態に戻すことも可能です。
Gitには、この他、開発中のソースコードやドキュメントを、「テスト版」「○○版」……のように枝分かれさせたり、それらを合流させたりする機能もあります。枝分かれしたそれぞれのバージョンを「ブランチ」(branch)と呼び、ブランチを合流させることを「マージ」(merge)と呼びます。
コミットには「タグ」と呼ばれる名前を付けることができます。その際には「git tag」コマンドを使います。
git [オプション] サブコマンド [サブコマンドごとのオプションや引数]
git rm [オプション] ファイル名……
※ [ ]は省略可能な引数を示しています。
短いオプション | 長いオプション | 意味 |
---|---|---|
-C パス | カレントディレクトリではなく指定したディレクトリで実行したものとする | |
--bare | リポジトリを「bareリポジトリ」(ワーキングツリーが存在しない、管理だけを目的としたリポジトリ)として扱う | |
-c 設定=値 | 設定値を指定する(設定は「git config」で確認可能) | |
-p | --paginate | 全ての出力を「less」コマンドまたは環境変数PAGERで指定されたコマンドで表示する |
-P | --no-pager | 「less」コマンドで表示しない(「-p」の指定を打ち消す) |
--exec-path=パス | gitの実行ファイルのパスを指定する(「--exec-path」のみの場合、実行ファイルのパスを表示する) | |
--html-path | gitのHTML形式のドキュメントがインストールされたパスを表示する | |
--man-path | gitのmanファイルのパスを表示する | |
--info-path | gitのinfoファイルのパスを表示する | |
コマンド | 実行内容 |
---|---|
clone | リポジトリのクローンを作成する |
init | リポジトリを新規作成する、または既存のリポジトリを初期化する |
remote | リモートリポジトリを関連付けする |
fetch | リモートリポジトリの内容を取得する |
pull | リモートリポジトリの内容を取得し、現在のブランチに取り込む(「fetch」と「merge」を行う) |
push | ローカルリポジトリの変更内容をリモートリポジトリに送信する |
add | ファイルをインデックスに追加する(コミットの対象にする) |
rm | ファイルをインデックスから削除する |
mv | ファイルやディレクトリの名前を変更する |
reset | ファイルをインデックスから削除し、特定のコミットの状態まで戻す |
status | ワークツリーにあるファイルの状態を表示する |
show | ファイルの内容やコミットの差分などを表示する |
diff | コミット同士やコミットとワークツリーの内容を比較する |
commit | インデックスに追加した変更をリポジトリに記録する |
tag | コミットにタグを付ける、削除する、一覧表示する |
log | コミット時のログを表示する |
grep | リポジトリで管理されているファイルをパターン検索する |
branch | ブランチを作成、削除、一覧表示する |
checkout | ワークツリーを異なるブランチに切り替える |
merge | 他のブランチやコミットの内容を現在のブランチに取り込む |
rebase | コミットを再適用する(ブランチの分岐点を変更したり、コミットの順番を入れ替えたりできる) |
config | 現在の設定を取得、変更する |
短いオプション | 長いオプション | 意味 |
---|---|---|
--cached | インデックスからの削除だけを実行する(ワークツリーのファイルは保持する) | |
-f | --force | コミット前やインデックスに追加する前のファイルであっても削除する |
-r | ディレクトリを再帰的に削除する | |
-q | --quiet | 実行時のメッセージを減らす |
--ignore-unmatch | 対象のファイルが存在しなくても、エラーメッセージを表示しない | |
-n | --dry-run | 実行せずに実行する内容だけを表示する |
「git rm ファイル名」でGit管理下にある削除したファイルを元に戻すには、コミットしていない段階であれば、「git checkout」(連載第391回)を使うのが簡単です。例えば、最終のコミット(HEAD)から戻したいのであれば、「git checkout HEAD ファイル名」のようにします(※2)。
※2 「git checkout コミット ファイル名」で指定したコミットからファイルを取得できる。最終のコミットから戻す場合は「git checkout -- ファイル名」としてもよい(「--」以降の指定は全てファイル名と見なされる)
以下の画面1〜4では、「ワークツリーで複数のファイルを編集している中で、あるファイルを削除してしまった」というケースを見るために、削除するつもりがない「index.html」も書き換えています。
いずれの画面も連載第396回で作成したローカルリポジトリとリモートリポジトリを使用しています。連載第398回で「hello.txt」の変更を「git commit」「git push」した後の状態から始めています。
画面1では「git checkout」を使ったファイルの復元を試しています。なお、画面1で「†」を付けたコマンドラインで「index.html」の編集をコミットするには「git add index.html」(連載第384回)でインデックスに追加した後に、「git commit」を実施します。
ファイルを削除後、コミットしてしまったとしても、「git push」する前であれば、変更されているのは自分のワークツリーとローカルリポジトリの中だけです。リモートリポジトリにはまだ記録されておらず、他の開発者の環境には何も影響していません。
もし、削除を含めた今回のコミット全体を「なかったこと」にしてもよいのであれば、「リセット」して、全体を1つ前のコミットに戻してしまうことができます。この場合は「git reset」コマンドを使用します。「git reset」コマンドは主に「git add」を取り消すのに使うコマンドです。
今回の場合、インデックスの状態だけではなく、ワークツリーのファイルも元に戻したいので「--hard」オプションを使います。
画面2では、削除からコミットするまでの実行の様子を示しました。
画面3では「git reset」に先立ち、現在の状態を確認しています。
「git log」(連載第386回)でコミットのログを確認すると、リモートの最新(origin/master)に対しコミットが1つ追加されている様子が分かります。
「ls」でワークツリーの状態を見ると、「hello.txt」がありません。また、「tail」コマンドで「index.html」の末尾を見ると、画面1で追加した「test」という行が入っています。
この状態で「git reset --hard HEAD^」を実行します。
「--hard」はワークツリーのファイルも元に戻すためのオプション、「HEAD^」は「HEADの1つ前のコミット」という意味です。今回の場合、「git log」で表示されている「5668829」や、「origin/master」を指定しても同じ状態になります。
削除したファイルだけを戻す方法は2つあります(※3)。第1の方法は、「git checkout」でファイルを取得し、あらためて、「git add」(今回の例では「git add hello.txt」)を実行してからコミットします。
第2の方法では「git reset」を使って画面4のように実行します。画面4は画面2の直後から始まっています(※4)。第1の方法に比べると幾分複雑です。
※3 この他、元に戻したくないファイルを「git stash」コマンドで退避しておくという方法もある。
※4 画面3と同じ操作をした後の場合、あらためて「echo test >> index.html」「git rm hello.txt」「git add index.html」「git commit -m メッセージ」を実施すると、画面4と同じ操作が可能になる。
今回の場合、「HEAD^」(HEADの1つ前のコミット)から「hello.txt」を戻したいので「git reset HEAD^ hello.txt」のようにします。
なお、「git reset」でファイルを指定する、つまり、コミットの一部だけ戻すという場合、ワークツリーも同時に元に戻す「--hard」オプションは使えません。
そこで、「git checkout hello.txt」で「hello.txt」を取得してから、再度コミットしています。
西村 めぐみ(にしむら めぐみ)
元々はDOSユーザー。ソフトハウスに勤務し生産管理のパッケージソフトウェアの開発およびサポート業務を担当、その後ライターになる。著書に『図解でわかるLinux』『らぶらぶLinuxシリーズ』『[新版 zsh&bash対応] macOSコマンド入門』『Accessではじめるデータベース超入門[改訂2版]』など。地方自治体の在宅就業支援事業にてMicrosoft Officeの教材作成およびeラーニング指導を担当。会社等の"PCヘルパー"やピンポイント研修なども行っている。
Copyright © ITmedia, Inc. All Rights Reserved.