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

[西村めぐみ，＠IT]

Linux基本コマンドTips一覧

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

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

目次

git revertコマンドの概要 | 書式| オプション一覧

実行例

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

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」を利用すればよいでしょう。

※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 revert [オプション] コミット……

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

目次に戻る

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	ファイルをインデックスから削除し、特定のコミットの状態まで戻す
revert	指定したコミットを取り消すコミットを実行する
status	ワークツリーにあるファイルの状態を表示する
show	ファイルの内容やコミットの差分などを表示する
diff	コミット同士やコミットとワークツリーの内容を比較する
commit	インデックスに追加した変更をリポジトリに記録する
tag	コミットにタグを付ける、削除する、一覧表示する
log	コミット時のログを表示する
grep	リポジトリで管理されているファイルをパターン検索する
branch	ブランチを作成、削除、一覧表示する
checkout	ワークツリーを異なるブランチに切り替える
merge	他のブランチやコミットの内容を現在のブランチに取り込む
rebase	コミットを再適用する（ブランチの分岐点を変更したり、コミットの順番を入れ替えたりできる）
config	現在の設定を取得、変更する

git revertの主なオプション

短いオプション	長いオプション	意味
	--no-edit	コミットメッセージを編集しない（本文を参照）
-e	--edit	コミットメッセージを編集する（デフォルト動作）
-m 番号	--mainline 番号	マージコミットの場合、どのコミットに戻すのかを指定する（本文を参照）
-n	--no-commit	ワークツリーを元に戻すための変更だけを行い、コミットは実行しない

目次に戻る

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

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

コマンド実行例

git revert --no-edit コミット

（指定したコミットの内容を取り消す際にデフォルトのメッセージ「Revert "元のコミットメッセージ"」を使用する）

git revert -m 1 --no-edit コミット

（指定したコミットの内容を取り消して、マージ元の1つ目のコミットに戻す。その際、デフォルトのメッセージを使用する）

git revert -m 2 --no-edit コミット

（指定したコミットの内容を取り消して、マージ元の2つ目のコミットに戻す。その際、デフォルトのメッセージを使用する）

　画面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」を取り消してもう一方のコミットに戻したところ

目次に戻る

筆者紹介

西村 めぐみ（にしむら めぐみ）

元々はDOSユーザー。ソフトハウスに勤務し生産管理のパッケージソフトウェアの開発およびサポート業務を担当、その後ライターになる。著書に『図解でわかるLinux』『らぶらぶLinuxシリーズ』『[新版 zsh&bash対応] macOSコマンド入門』『Accessではじめるデータベース超入門［改訂2版］』など。地方自治体の在宅就業支援事業にてMicrosoft Officeの教材作成およびeラーニング指導を担当。会社等の"PCヘルパー"やピンポイント研修なども行っている。