しまった、さっきのタイポがまだ残っていた!ときに便利な「stash」コマンド
ここまで、ブランチ戦略について書かせていただきました。第1回でも説明したコミットなどを意識し始めると、コマンドを打つ頻度も上がってくるかと思います。ここからは、いくつか便利なコマンドを紹介します。知っているとさらに作業がはかどるはずです。
まずはstash
です。このコマンドを使うと、コミット前の変更を退避(作業中コードから取り除くこと)できます。以下のような状況で役立ちます。
-
しまった! さっきのタイポがまだ残っていた。
いったん今の作業をやめて先にタイポをコミットしたい。 -
作業を始めちゃったけど、大元のブランチに他の人の変更がマージされた。
変更が大きそうなので先に自分のブランチに取り込みたい。
利用方法を簡単に説明します。現在、コードに変更が入った状態だとします。
% git status --short M sum.js % git diff diff --git a/sum.js b/sum.js index 9aba049..7fe92a6 100644 --- a/sum.js +++ b/sum.js @@ -1,3 +1,6 @@ const sum = (a, b) => { + if(a < 0 || b < 0 ) { + return 0 + } return a + b }
このような時にstash
コマンドを利用することで、現在の差分部分を退避できます。
% git stash Saved working directory and index state WIP on main: fa6f190 足し算関数を追加
コードの状態を見てみると、変更は無くなっています。
% git status --short %
退避した変更自体は、stash list
コマンドやstash show
コマンドを利用することで確認できます。
% git stash list stash@{0}: WIP on main: fa6f190 足し算関数を追加 % git stash show -p stash@{0} diff --git a/sum.js b/sum.js index 9aba049..7fe92a6 100644 --- a/sum.js +++ b/sum.js @@ -1,3 +1,6 @@ const sum = (a, b) => { + if(a < 0 || b < 0 ) { + return 0 + } return a + b } \ No newline at end of file
また、退避した変更を戻す際には、stash apply
やstash pop
などのコマンドを利用します。
% git stash apply On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: sum.js % git status --short M sum.js
なお、退避した変更を戻す時には、戻す先のコードが退避時とは変わっている可能性があります。その場合にはコンフリクトが発生することがあります。
ちなみに、変更を戻す際のコマンドstash apply
とstash pop
の違いは、退避していた情報をstash情報から削除するかどうかです。apply
を利用するとコードは復元されますが、stash情報にはそのまま残ります。よって、apply
を実行した後にstash list
を実行すると、退避した情報を確認できます。一方でpop
を利用すると、コードの復元とstash情報からの削除が両方行われます。
一方で、「stashが溜まってしまう問題」もよく聞きます。
まず、不要なstashを作らないように心がけ、復元が終わったらstashのリストから削除することが基本です。筆者がstashした内容を元に戻す際には、基本的にstash pop
を利用しています。 stashする際に-m
オプションを使ってメッセージをつけることもできます。何のためにstashを残しているのか、メッセージとして記録することで、後で扱いやすくなると思います。
もし「実装しかけのコードが溜まってしまう」という場合は、タスクの進め方を見直してみましょう。タスクを完了してから次のタスクに着手する、少なくともコミットできる状態まで進めてから次のタスクに取り掛かるというように、原則に立ち返ってみるのも手です。一人一人状況は異なるため一概には言えることではありませんが、「stashが溜まってしまう問題」を、タスク進行の見直しのきっかけにしてみてください。
多彩なオプションが魅力──「log」コマンドとは
次はlog
です。log
はコミットの履歴を閲覧でき、多彩なオプションが用意されています。ここではoneline
、graph
、path
の3つのオプションを紹介します。
oneline
--online
オプションをつけると、各コミットが1行で表示されます。コミット履歴をさっと確認したい時に便利で、筆者自身もよく使っています。
% git log --oneline f3232e7 (HEAD -> main) Merge branch 'feature/add' 5898241 sub コミット4 7c81f38 (feature/add) add コミット4 69d2f08 add コミット3 e152a6f add コミット2 54b30bd sub コミット3 c6a4432 sub コミット2
graph
--graph
オプションを利用することで、コミットが少しグラフィカルに表示されます。ブランチの分岐も表現されます。
% git log --oneline --graph * f3232e7 (HEAD -> main) Merge branch 'feature/add' |\ | * 7c81f38 (feature/add) add コミット4 | * 69d2f08 add コミット3 * | 5898241 sub コミット4 |/ * e152a6f add コミット2 * 54b30bd sub コミット3 * c6a4432 sub コミット2
pathの指定
--[path]
のように、ファイルのパスを指定することで、指定したファイルに関するコミットだけが表示されます。
% git log --oneline -- add.js 7c81f38 (feature/add) add コミット4 69d2f08 add コミット3 e152a6f add コミット2 b4939bb add コミット1
今回は紹介しませんが、他にもpretty
オプションを指定することで、もっと多彩なフォーマットを指定することができます。興味がある方は調べてみてください。
1行ごとのコミット情報を確認──「blame」コマンドとは
blame
コマンドを利用することで、コードの1行ごとのコミット情報を表示できます。
% git blame count.js ef870571 (chihiro 2024-04-07 16:17:47 +0900 1) const count = (input) => { f1b64e1d (chihiro 2024-04-07 16:21:11 +0900 2) // 異常値の場合は0を返す TODO Errorにするか検討 dd825e81 (chihiro 2024-04-07 16:18:53 +0900 3) if(input == null) { dd825e81 (chihiro 2024-04-07 16:18:53 +0900 4) return 0 dd825e81 (chihiro 2024-04-07 16:18:53 +0900 5) } d636649c (chihiro 2024-04-07 16:20:33 +0900 6) if(typeof input != 'string') { d636649c (chihiro 2024-04-07 16:20:33 +0900 7) return 0 d636649c (chihiro 2024-04-07 16:20:33 +0900 8) } ef870571 (chihiro 2024-04-07 16:17:47 +0900 9) return input.length ef870571 (chihiro 2024-04-07 16:17:47 +0900 10) }
私自身のblame
コマンドの使い所は、「このコード、何のために入っているんだろう?」と疑問に思った時です。blame
コマンドでコミットハッシュを調べて、コミットハッシュからコミットの内容を確認しています。