はじめに
Gitで開発していると、作業中に別ブランチを確認したくなることがあります。
例えば次のような場面です。
- 作業中にコードレビュー依頼が来た
- 別ブランチの実装を確認したい
- 過去のバージョンを動かして確認したい
このようなとき、通常は次のような操作をします。
git stash
git checkout 別ブランチしかしこの方法だと、現在の作業を一度中断する必要があります。
そこで便利なのが git worktree です。
git worktree を使うと、同じリポジトリを別ディレクトリに展開し、複数のブランチを同時に作業できます。
普段の対応（stashを使う方法）
開発中にコードレビュー依頼が来ることがあります。
私はこれまで次のような方法で対応していました。
git stash push -m "q"
git checkout review-branch作業中の変更を一旦 stash し、レビュー対象のブランチへ移動します。
レビューが終わったら、元の作業ブランチに戻って stash を戻します。
git checkout feature-branch
git stash popちなみに私はレビュー対応のとき、簡単に q（quick の意味）という名前で stash することがあります。
この方法でも問題なく対応できます。
ただし、この方法にはいくつかデメリットがあります。
- stash が増えると管理が大変
- stash を戻すときにコンフリクトが起きる可能性がある
- 作業中の状態を一度中断する必要がある
git worktree を使う
git worktree を使うと、現在の作業を中断せずに別ブランチをチェックアウトできます。
例えばレビュー用のブランチを開きたい場合です。
git worktree add ../review review-branchすると次のような構成になります。
project/
review/project→ 現在作業しているブランチreview→ レビュー対象のブランチ
これにより
- 作業中のコードはそのまま
- 別ディレクトリでレビュー
という使い方ができます。
複数人からレビューをもらうときにも便利
git worktree は、複数人からレビューをもらう場合にも便利です。
例えば、レビューを依頼すると次のような流れになることがあります。
- Aさんからレビューコメント
- Bさんからレビューコメント
- 修正後に再レビュー
通常の方法だと、そのたびにブランチを移動して確認する必要があります。
しかし git worktree を使うと、レビュー用のブランチをディレクトリとして管理できます。
git worktree add ../review feature-branchディレクトリ構成は次のようになります。
project/
review/レビュー対応中は review ディレクトリをそのまま残しておきます。
修正が入った場合は、そのディレクトリで更新します。
cd review
git pullこれで修正内容をすぐ確認できます。
その間、自分は元のディレクトリで開発を続けることができます。
project → 自分の作業
review → レビュー確認このように レビュー対応と自分の作業を並行できるのがgit worktree の大きなメリットです。
過去バージョンを確認する
タグや過去コミットでも worktree を作成できます。
例えば過去のタグを確認する場合です。
git worktree add ../v1 v1.2.0ディレクトリ構成は次のようになります。
project/
v1/これにより、現在の作業を止めずに
過去バージョンの動作確認ができます。
worktree を削除する
不要になった worktree は削除できます。
git worktree remove ../review現在の worktree 一覧は次のコマンドで確認できます。
git worktree listどんなときに便利？
git worktree が便利なのは次のようなケースです。
- 作業中にレビュー対応する
- 複数ブランチを同時に確認する
- 過去バージョンを並行して動かす
- stash をあまり使いたくない
特に レビュー対応が多い開発ではかなり便利です。
まとめ
git stash を使った方法でも問題ありませんが、
ブランチを頻繁に行き来する場合は git worktree がとても便利です。
特に
- 作業を中断しない
- 複数ブランチを同時に開ける
という点が大きなメリットです。
レビュー対応が多いプロジェクトでは、git worktree を使うと良いと感じました！！
コーヒー1杯分の応援をいただけると励みになります！
