【 git rm 】コマンド（応用編その1）――削除したファイルを元に戻す - @IT

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

Linux基本コマンドTips一覧

　本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、基礎編に続き、ファイルを削除してGitの管理対象から外すことができる「git rm」コマンドです。削除したファイルを元に戻す方法について、幾つか例を挙げて解説します。

git／git rmコマンドとは？

　「git」は「Git」という分散型バージョン管理システム用のコマンドです。Gitは元々Linuxカーネルのソースコードを管理するために作られた「バージョン管理システム」で、現在は多くのソフトウェアやWebサイトのソースコード、ドキュメントの管理などに用いられています。

　ソースコードを管理する際、最新版だけを保存するやり方はうまくいきません。開発中のさまざまなタイミングで状態を管理し、必要に応じて比較、参照したり、元に戻したりできるようにする仕組みが「バージョン管理システム」です。

　Gitでは、テスト版など複数に枝分かれした状態も管理できます。複数のメンバーによる開発を前提としており、開発中の各時点におけるコメントや、コメントへの返信なども管理できるようになっています。

gitのサブコマンドと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 [オプション] ファイル名……

※ [ ]は省略可能な引数を示しています。

gitの主なオプション

短いオプション	長いオプション	意味
-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ファイルのパスを表示する

gitのサブコマンド

コマンド	実行内容
clone	リポジトリのクローンを作成する
init	リポジトリを新規作成する、または既存のリポジトリを初期化する
remote	リモートリポジトリを関連付けする
fetch	リモートリポジトリの内容を取得する
pull	リモートリポジトリの内容を取得し、現在のブランチに取り込む（「fetch」と「merge」を行う）
push	ローカルリポジトリの変更内容をリモートリポジトリに送信する
add	ファイルをインデックスに追加する（コミットの対象にする）
rm	ファイルをインデックスから削除する
mv	ファイルやディレクトリの名前を変更する
reset	ファイルをインデックスから削除し、特定のコミットの状態まで戻す
status	ワークツリーにあるファイルの状態を表示する
show	ファイルの内容やコミットの差分などを表示する
diff	コミット同士やコミットとワークツリーの内容を比較する
commit	インデックスに追加した変更をリポジトリに記録する
tag	コミットにタグを付ける、削除する、一覧表示する
log	コミット時のログを表示する
grep	リポジトリで管理されているファイルをパターン検索する
branch	ブランチを作成、削除、一覧表示する
checkout	ワークツリーを異なるブランチに切り替える
merge	他のブランチやコミットの内容を現在のブランチに取り込む
rebase	コミットを再適用する（ブランチの分岐点を変更したり、コミットの順番を入れ替えたりできる）
config	現在の設定を取得、変更する

git rmの主なオプション

短いオプション	長いオプション	意味
	--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」を実施します。

画面1　削除したファイルをコミットする前の時点で元へ戻したところ

インデックスとワークツリーをコミットする前の状態に戻す（リセットする）

　ファイルを削除後、コミットしてしまったとしても、「git push」する前であれば、変更されているのは自分のワークツリーとローカルリポジトリの中だけです。リモートリポジトリにはまだ記録されておらず、他の開発者の環境には何も影響していません。

　もし、削除を含めた今回のコミット全体を「なかったこと」にしてもよいのであれば、「リセット」して、全体を1つ前のコミットに戻してしまうことができます。この場合は「git reset」コマンドを使用します。「git reset」コマンドは主に「git add」を取り消すのに使うコマンドです。

　今回の場合、インデックスの状態だけではなく、ワークツリーのファイルも元に戻したいので「--hard」オプションを使います。

　画面2では、削除からコミットするまでの実行の様子を示しました。

画面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」を指定しても同じ状態になります。

画面3　ワークツリーのファイルを元に戻したところ

削除したファイルだけをコミットする前の状態に戻す

関連記事

Copyright © ITmedia, Inc. All Rights Reserved.

Let's block ads! (Why?)

"応用" - Google ニュース
June 05, 2020 at 03:00AM
https://ift.tt/2Y5M0su

【 git rm 】コマンド（応用編その1）――削除したファイルを元に戻す - @IT
"応用" - Google ニュース
https://ift.tt/2RdYJHB
Shoes Man Tutorial
Pos News Update
Meme Update
Korean Entertainment News
Japan News Update