SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Git中級者への第一歩

【Git中級者への第一歩】リリースプロセスの品質を上げるブランチ戦略、開発をもっと便利にするコマンドとは

Git中級者への第1歩 第2回

  • X ポスト
  • このエントリーをはてなブックマークに追加

しまった、さっきのタイポがまだ残っていた!ときに便利な「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 applystash 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 applystash popの違いは、退避していた情報をstash情報から削除するかどうかです。applyを利用するとコードは復元されますが、stash情報にはそのまま残ります。よって、applyを実行した後にstash listを実行すると、退避した情報を確認できます。一方でpopを利用すると、コードの復元とstash情報からの削除が両方行われます。

 一方で、「stashが溜まってしまう問題」もよく聞きます。

 まず、不要なstashを作らないように心がけ、復元が終わったらstashのリストから削除することが基本です。筆者がstashした内容を元に戻す際には、基本的にstash pop を利用しています。 stashする際に-mオプションを使ってメッセージをつけることもできます。何のためにstashを残しているのか、メッセージとして記録することで、後で扱いやすくなると思います。

 もし「実装しかけのコードが溜まってしまう」という場合は、タスクの進め方を見直してみましょう。タスクを完了してから次のタスクに着手する、少なくともコミットできる状態まで進めてから次のタスクに取り掛かるというように、原則に立ち返ってみるのも手です。一人一人状況は異なるため一概には言えることではありませんが、「stashが溜まってしまう問題」を、タスク進行の見直しのきっかけにしてみてください。

多彩なオプションが魅力──「log」コマンドとは

 次はlogです。logはコミットの履歴を閲覧でき、多彩なオプションが用意されています。ここではonelinegraphpathの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コマンドでコミットハッシュを調べて、コミットハッシュからコミットの内容を確認しています。

次のページ
コマンドに好きな名前を登録する「alias(エイリアス)」とは

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Git中級者への第一歩連載記事一覧

もっと読む

この記事の著者

藤澤 千尋(フジサワ チヒロ)

 ソフトウェアエンジニアとして約10年働いており、最近は主にフロントエンド開発を担当しています。最近、筋トレを始めました。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/19413 2024/06/05 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング