【 git revert 】コマンド（応用編その2）――マージされたコミットを取り消す：Linux基本コマンドTips（406）

Linux基本コマンドTips一覧

　本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回はコミットを取り消す「git revert」コマンドの応用編です。連載第403回と連載第405回に引き続き、削除したファイルを元に戻す場合を例に挙げて説明します。

　なお、「git revert」コマンドを使わずに削除したファイルを元に戻す方法については、「git rm」コマンドの応用編を参照ください。

git／git revertコマンドとは？

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

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

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

gitのサブコマンドとGitの仕組み

　gitコマンドはほとんどの場合、「サブコマンド」と組み合わせて利用します（本連載ではgitとサブコマンドの組み合わせをコマンドとして紹介します）。

　今回紹介する「git revert」コマンドは、「コミットの内容を取り消すためのコミット」を行うコマンドです。コミットの記録を残した上で、ファイルの変更を元に戻すことができます。

　gitコマンドでは「リポジトリ（repository）」を使ってバージョンを管理します。リポジトリにはソースコードや変更履歴、コメントなどを一括して保管します。リポジトリには、自分のPC上に作る「ローカルリポジトリ」と、「GitHub」などのWebサービス上に作る「リモートリポジトリ」があり、両者を連携させることで複数の開発者による開発を1本にまとめることができます。

　また、ローカルリポジトリのみで運用することも可能です。そのような運用をしているリポジトリにリモートリポジトリを追加したり、逆に、リモートリポジトリを削除したりするには、「git remote」コマンドを使用します。「git remote」コマンドには、さらに「add」や「remove」などのサブコマンドがあります。

　既存のリポジトリ（リモートリポジトリ）にあるソースコードなどを入手したい場合は、まず、「git clone」（連載第381回）でリポジトリを自分の環境に複製します（※1）。リモートリポジトリの内容がバージョンアップされたら「git pull」（連載第382回）で最新版を取得します。開発に参加するのではなく、単に最新版を取得したいという場合は、「git clone」と「git pull」を利用すればよいでしょう。

　保管場所であるリポジトリに対し、ファイルの編集などを行う場所を「ワークツリー」「ワーキングエリア」「作業ツリー」などと呼びます。「git clone」や「git pull」で取得した最新版のファイルはワークツリーに配置されます。つまり「作業ディレクトリ」です。

　ワークツリーで編集した結果をリポジトリに反映する操作を「コミット」と呼びます。「git add」（連載第384回）コマンドでコミットしたいファイルを「インデックス」あるいは「ステージングエリア」と呼ばれる領域に追加します。インデックスにはファイルの変更箇所などが記録されます。

　インデックスの内容は「git commit」コマンドでローカルリポジトリにコミットされ、「git push」コマンドでローカルリポジトリの内容をリモートリポジトリに反映します。従って、「git add」や「git commit」などを行わなければ、自分の環境で編集した内容がリポジトリに影響を与えることはありません。自由に編集し、テストできます。なお、ワークツリーのファイルを過去の任意のコミット状態に戻すことも可能です。

　Gitには、この他、開発中のソースコードやドキュメントを、「テスト版」「○○版」……のように枝分かれさせたり、それらを合流させたりする機能もあります。枝分かれしたそれぞれのバージョンを「ブランチ」（branch）と呼び、ブランチを合流させることを「マージ」（merge）と呼びます。

　コミットには「タグ」と呼ばれる名前を付けることができます。その際には「git tag」コマンドを使います。

gitの主なオプション

gitのサブコマンド

git revertの主なオプション

マージされたコミットを取り消す

　2つの変更を取り込んだコミットを「マージコミット」と呼びます。マージコミットを取り消したい場合、どのコミットに戻すかを「-m 番号」で指定する必要があります。

　画面1〜3では連載第396回で作成したローカルリポジトリとリモートリポジトリを使用しています。連載第398回で「hello.txt」の変更を「git commit」「git push」した後の状態から始めています。

　画面1ではまず、「git log」コマンドでコミットログを確認しています。今回は、3行目にある「7c514ca」のコミットを取り消すことにしました。

　次に「-m」オプションを付けずに「git revert --no-edit」でコミットの取り消しを試みましたが、「7c514ca」はマージコミットであるため、エラーメッセージが表示されました。

　「git show」コマンド（連載第389回）を使ってコミットの内容を確認したところ、「Merge: e51d1d0 2525f8d」という行があり、2つのコミット（e51d1d0と2525f8d2）をマージしたことが分かりました。それぞれのコミットで編集しているのはいずれも「hello.txt」なので、最後にコミット時点での内容を「git show コミット:ファイル名」（連載第390回）で確認しました。

画面1,画面1　マージしたコミットを取り消そうとしたところ　「-m」オプションを使わなかったため失敗した

　画面2では1つ目のコミット（e51d1d0）の状態に戻すために「-m 1」を指定しました。

　その後「hello.txt」の内容を確認すると、画面1で確認した1つ目のコミット（e51d1d0）の「hello.txt」に戻っていることが分かりました。

画面2　コミットの番号を指定してマージしたコミットを取り消したところ

マージされたコミットを取り消した直後に操作をやり直す

　画面3では画面2で実行した「git revert」を取り消して2つ目のコミットに戻そうとしています。

　「git revert」の直後でまだ「git push」を実行していないため、画面2のコミットそのものを「なかったこと」にします。最初の「git reset --hard HEAD^」で、現在のコミットの1つ前の状態にリセットしました。「HEAD^」は「HEAD」の1つ前のコミットという意味です。「--hard」は、インデックスとワーキングツリーをリセットするというオプションです。

　リセットの後は画面2とほぼ同じ処理ですが、今度は「-m 2」で2つ目のコミットの状態に戻しています。

画面3　直前に実行した「git revert」を取り消してもう一方のコミットに戻したところ