みなさん、こんにちは！
SourceTreeのキャプチャを撮りまくってますタカハシ(@ntakahashi0505)です。
引き続き非エンジニアのGit初心者向けにGitクライアントツールSourceTreeを使ったバージョン管理の方法をお伝えしていきたいと思います。
前回はSourceTreeの使い方と、リポジトリやコミットなどのGitの基本的な部分ついて、こちらの記事でお伝えしました。
さて、いよいよファイルのバージョンを戻してみたいと思います。
一般的にファイルコピーでのバージョン管理ですと、ファイルの中身を見て戻りたいファイルを見つけて…といった作業になりますが、面倒くさいですよね。
今回の記事では、SourceTreeによるGitバージョン管理で瞬時に目的のバージョンに戻すリセットの方法についてお伝えします。
またGitのリセットにはHard、Mixed、Softと3種類ありますので、その使い分けについても簡単に説明をします。
SourceTreeで2回目のコミット
では前回の状態から続きを進めていきますね。
最初のコミットが完了した状態
Test1と1行だけ書いたsample.txtというテキストファイルを作成してコミットした状態がこちらです。
ファイルに変更を加えてステージングに上げる
ここで、sample.txtにこのように変更を加えてみます。
Test2という1行を追加しました。
SourceTreeの作業コピーに変更が反映されますので、チェックして「Indexにステージしたファイル」に移動します。
すると右側の箇所に変更箇所が表示されます。
ピンクが削除された行、緑が追加された行という見方ですね。
今回はTest2を追加しただけですが、Test1もいったん削除されて再度追加されたという解釈をしているようです。どっちでもいいですけど。
ステージされたファイルをコミットする
ここでコミットメッセージ「Text2を追加」などとして「コミット」しますと
このように2つ目のコミットが表示されました。
この画面でもこのコミットでどこが変更されたかと見ることができます。
ちなみにこの変更箇所の確認はコンソールでは
git diff
などとするそうです。
同様にファイルの更新とコミットを繰り返すと、この樹形図の欄に都度コミットが追加されていくことになります。
もうコミットについては慣れましたかね？
前のコミットにバージョンを戻す方法
Gitではバージョンを元に戻すことをリセットと言います。いよいよですが、以前のコミットにリセットをしていく方法をお伝えしていきます。
Hardにコミットをリセットをする
まず、「ブランチ」→「Master」の画面で戻りたいコミットを選択します。この場合は「Test1を追加」に戻りたいと思います。
そこで右クリックをして、メニューから「現在のブランチをこのコミットまでリセット」を選択してください。
すると「コミットにリセット…」というウィンドウが開きますので「Hard-全ての作業コピーの変更を破棄する」を選択して「OK」。
警告のウィンドウが出ます。
何が起きるかわかっていますね？
と、空前の衝撃的なメッセージがありますが、遠慮なく「Yes」！
コミットがリセットされたことを確認する
「ブランチ」→「Master」の画面を確認しますと、「Test2を追加」のコミットが消えていることが確認できます。
sample.txtも確認してみますと
このようにText2の行が消えているのが確認できます。
ちなみにですが、これをコンソールで実行する場合は
git reset –hard コミットID
と書きます。コミットIDは
これです。
直前のコミットに戻る場合は「HEAD」をつけて
git reset –hard HEAD
と書くそうです。
使うときが来るかどうかわかりませんが念のため…。
Mixedでコミットをリセットする
ではHardではないリセットをするとどうなるのでしょうか。やってみましょう。
ここで「Mixed-作業コピーの変更はそのままにす」を選択して「OK」。
あの恐ろしいメッセージは出ることなく、コミットのリセットが行われます。
Hardのときと違うのは「コミットされていない変更があります」との表示。
「ファイルステータス」→「作業コピー」を確認してみますと
変更がコミットされた直前の状態に戻っていることがわかります。
Mixedの場合は「作業コピーの変更はそのままにする」との説明の通り、作業ファイルは更新された状態ですが、コミットだけが取り消されてその直前の状態に戻る、ということになりますね。
ちなみにコンソールの場合で
git reset
と、オプションを指定しない場合は、デフォルトでmixedのリセットが適用されるようです。
GitでのHard・Mixed・Softの違い
Hard、Mixedとありますので、当然Softというのもあります。
Softでリセットした場合は
このように変更がステージングにアップされた状態にリセットされます。本当に直前ですね。
それぞれどのように使い分けるかということなんですが
- コミットメッセージだけ修正してコミットし直したい→Soft
- 変更内容を追加してコミットし直したい→Mixed
- コミット自体なかったことにしたい→Hard
という使い分けが良さそうです。
なのですが、Gitのバージョン管理は全ての履歴を残したほうが良いという概念のもと、Hardのリセットは極力使わないほうが良いという意見もあります。あのメッセージ、おっかないですしね。
では前のバージョンに戻したいときはどうするかということなんですが、ブランチを切るという方法があります。
これについてはまた別の機会にお伝えできればと思います。
まとめ
SourceTreeを使った初心者でもわかる非エンジニア向けGitバージョン管理、今回は2回目以降のコミットおよびコミットのリセットの方法についてお伝えしました。
リセットにもSoft、Hard、Mixedと種類がありますので、本記事を参考に都度適したリセットの方法をチョイスして頂ければと思います。
次回はこちらの記事です。
バージョン履歴を分岐させるブランチ、また分岐したバージョン履歴を統合するマージについてお伝えしています。さらに便利にGitバージョン管理が実現できますよ。
どうぞお楽しみに！
連載目次：非エンジニアの初心者向けSourceTreeによるGitバージョン管理
- 非エンジニアのためのバージョン管理Git～メリットと導入前の準備
- 非エンジニアでもSourceTreeを使えば超簡単にGitでのバージョン管理ができる
- SourceTreeでGit管理しているファイルのバージョンをリセットする方法
- SourceTreeでバージョン履歴を分岐したりマージしたりする方法
- コンフリクトって！？Gitバージョン管理でマージしたときに発生した衝突を解決する
- 非エンジニアのためのGitバージョン管理～BitbucketとかGitHubって何？
- 非エンジニアのためのGitバージョン管理～Bitbucketの登録とはじめてのプッシュ
