【Git】業務中になんとなくしている小ワザを並べてみるkwskされたら記事書く
はじめに
対象
- 他の開発者のGitの使い方が気になる方向け。
開発環境
現在メインで作業しているMacの環境では、以下の優先順位でGit関係の作業を行っています。
- GUI Clients (Fork)
- JetBrains IDE付属のツール
- Terminal
OSによって多少順番やクライアントが入れ替わります。Forkで解決するものはForkで、少し面倒なものはJetBrains IDEで、といった具合です。
調査フェーズ
参画直後のプロジェクト全体の把握や、障害時の原因調査、機能開発前の仕様の確認など。
直近の履歴を閲覧する
左が全表示、右が一部のディレクトリとリモートを非表示
- Fork
ブランチをツリー状に表示して、視覚的に確認できるのがいいですね。ForkやSourcetreeのような表示が分かりやすくていいです。スラッシュ区切りのブランチが階層表示されているのもポイントが高い。
特にForkは、
- ピン留め
- お気に入りやブックマークのように、
Branchesより上のPinnedという領域にブランチを表示しておける機能。
- お気に入りやブックマークのように、
- フィルタリング
- 選択したブランチ・ディレクトリを中心に表示する機能。
- 表示・非表示切替
- 選択したブランチ・ディレクトリの表示・非表示を切り替える機能。
の3つの機能が使いやすくて気に入っています。特に表示・非表示切替が強力で、ブランチが沢山あるときは大活躍します。
ブランチの命名規則に裁量があるときは、機能ごとにスラッシュ区切りにしておけば、関連するブランチだけ瞬時にフィルタリングできます。そうでなくても邪魔なブランチをどんどん非表示にしていけば、視界がかなりスッキリします。
ディレクトリ・ファイルごとの履歴を確認する
- JetBrains - Git > Show History
JetBrains製のIDE全部で同じツールが使えるのは便利です。特にファイルごとの履歴を瞬時に確認できるのがいい。別タブに表示される上に、右側にすぐ差分が表示されるのもいい。その表示も細かく設定が変えられてグッド。
クラスに手を加える前に全体の修正履歴を把握したり、フレームワークの設定ディレクトリに対して実行して略歴を調べたり。大雑把に全容を把握したいときが多いですかね。
選択範囲の履歴を確認する
- JetBrains - Git > Show History for Selection...
編集中のファイルの特定の範囲を選択して右クリックからの履歴チェック。これは先述のディレクトリ単位・ファイル単位の履歴だと数が多すぎる場合によく使います。
もしくは最初からバグったポイントが分かっていて、変更の前後を追うようなケースです。どこでやらかしたか事前に把握するときに便利です。Webアプリだと環境を当時の状態にするのも結構面倒なので、大体で目星を付けてから必要だったら行う感じ。
ブランチを比較する
- JetBrains - Log > Compare Branches
Forkでもできないことはないですが、JetBrainsだと専用の画面に各ブランチのコミットを分けて表示してくれるのがグッド。更にその画面の中で複数のコミットを選択してマージした差分を表示できるのが地味に嬉しいです。
開発フェーズ
変更をステージングに追加する
- Fork
別にJetBrains IDEでも同じことができるし、何ならIDEの方が若干優秀かもしれません。それでも私がForkを使っているのは、単純にSourcetreeからの移行先だったのが大きいです。慣れです。
肝心なのは行ごとに取捨選択しながらコミット対象を選べることなので、別のGitクライアントでいいのがあったら、そちらでも良いと思います。
直前のコミットの内容を変更する
- Fork - Amend
鉄板の機能ですね。よく使います。
- 一部の作業済ファイルをコミットしておく。
- 修正の終わったファイルからステージングに追加する。
- 折を見て直前のコミットにアメンドしていく。
IDE側でコミット前のコードは識別できるように色が付くので、コミット前の再チェックができるんですよね。怪しいと思ったらステージングから取り除いてアメンドし、改めて取捨選択をすればよい訳で。
WIPコミットで退避してリセットで戻す
- Fork - Reset 'feature' to Here...
スタッシュを使いこなせた試しがありません。使いこなせれば便利なのかもしれませんが、競合したり存在を忘れたりします。誰か上手い使い方があったら教えてください。
なので私の場合は、作業中のブランチに適当にWIP, wwwなどでコミットしています。プルリクエストのレビューや開発作業など他ブランチでの作業が済んだら、ブランチを戻してそのコミットだけリセットして元の状態に戻して作業続行。
最新のmainブランチにリベースする
- Fork - Rebase on 'main'...
JetBrainsでもできなくはないです。というか編集中のファイルもよしなに退避して、リベースしてから元の状態に戻してくれるので便利っちゃ便利です。Forkを含め多くのGUIクライアントでは、自分でコミットかスタッシュしてくださいと怒られます。
error: cannot rebase: You have unstaged changes.
error: Please commit or stash them.
これは他のリベースを伴う作業でも同様なんですが、競合したときは自分で解決しないといけないので面倒です。うっかり間違ってアボートすると消えます。IDEの機能でLocal Historyというものがあるので、頑張れば復活させられないこともないですが面倒です。
だったら一度、WIPでコミットしてから普通に競合解決した方が安心かなと思っています。
コミットの順番を入れ替える
- Fork - Interactive Rebase
プルリクエスト前になってリンターやフォーマッターを実行したら、漏れていた箇所があったときによく使います。順番を変えてからフィックスアップすれば、対象の修正と同じコミットにできて履歴が綺麗です。「Prettier修正」とかいうコミットメッセージは大昔に卒業しました。
あるいは個別のコミットを見たときに、なんとなく順番を整えることはしますかね。何のためにコミットを整理するかといえば、後からプルリクエストや調査フェーズで読み返したときに、自分やメンバーが読みやすいかなので。頭に入りやすい順番というか。
例えばRailsであればルーティングから始まり、コントローラー・ビュー・他画面へのリンク追加など、ある程度見やすい流れみたいなものに寄せたり。修正自体との関連は薄いが、同じプルリクで対処する場合、コミットを古い方に寄せるとか。
少し前のコミットメッセージを修正する
- JetBrains - Edit Commit Message...
先述の競合の件は、コミットメッセージの変更に限っていえば関係ないです。加えてJetBrainsの場合は余計な操作がほとんどないので、この操作をする場合は常にIDEで行っています。
複数のコミットをまとめる
- Fork - Fixup into Parent...
- Fork - Squash into Parent...
- JetBrains - Squash Commits...
フィックスアップ (Fixup) はForkに軍配が上がります。
スカッシュ (Squash) はJetBrains IDEの方が直感的なのでおすすめ。多くのGUIクライアントはあくまでCLIのGitをベースにしてるので、直後のコミットを親のコミットにくっつけるような導線になりがちですが、JetBrainsだと視覚的にまとめたいコミットを選ぶようになってます。
チェリーピックする
- Fork - Cherry-pick Commit...
Commit the changesのチェックを外すと、コミット前の状態でチェリーピックできるので重宝しています。またAppend origin to commit messageにチェックを付けると、チェリーピック元のリビジョンをコミットメッセージに含めてくれます。
(cherry picked from commit e83e075c38cc030e293c3439ab994bc72a17409f)
雑に実験用のブランチを立てて、何パターンか試してから良さげなものをチェリーピックするのは基本。
また履歴が汚くなるのであまりよろしくないですが、並行開発中の他の作業ブランチのコミットが必要になったときに持ってくるとか。できれば作業的には最初から別プルリクでmainにマージした方がいいですが、チーム開発だと大人の事情で稀によくあります。
コミットを破棄する
- Fork - Drop...
使用頻度は減りますが、リベースした後のゴミを取り除いたり、今回のプルリクに含めないことにした変更を破棄したり。この作業もForkで済ませてしまうことが多いです。
おわりに
もし深堀りして欲しい項目がありましたらリクエストください。かなり感覚で判断している作業が含まれているので、自分でやろうと思ったら上手くいかないことがあるかもしれません。
記憶が怪しくてチェリーピックは結構最後の最後で思い出したので、私が忘れていて聞きたい部分がありましたら気軽にどうぞ。また何か思い出したら追記します。
Discussion