English version

深夜に思いついた小ネタを試して、雑にディレクトリを切って、雑にコードを書いて、雑に寝る。

翌朝になって「昨日のあれ、どこに置いたっけ？」となるのがセットなんですが、これを何度もやると地味にストレスです。プロジェクトは増えるのに、手元のファイルシステムは一向に賢くならない。

このブログのタイトルはFragments of verbose memory（冗長な記憶の断片）なんですが、試行錯誤の断片って、本当に放っておくと消えます。消えるというか、見つからなくなります。

try は、その「見つからなくなる」を減らしてくれるツールでした。実験用ディレクトリの作成・検索・移動がスッと繋がるので、散らかり始める手前で戻ってこれる。作者がShopify のCEO Tobi Lütke というのも面白いところです。

tryとは？ — 「実験用ディレクトリ」に特化した管理ツール

tryは、実験的なプロジェクトディレクトリを一元管理するRuby製のCLIツールです。

公式サイトには明確に「Built for developers with ADHD by developers with ADHD」と書かれており、認知特性を考慮した設計が特徴です。

主な機能:

• ファジー検索（曖昧一致検索）: try poolでredis-connection-poolを即座に発見
• 時間ベースのスコアリング: 最近触ったディレクトリが上位に表示
• 自動日付プレフィックス: 2025-01-19-redis-experimentのように日付付きで整理
• Git worktree連携: try . <name>でdetached HEADのworktreeを作成
• TUI（ターミナルUI）: 矢印キーで直感的に操作

なぜzやautojumpではダメなのか？

既存のディレクトリジャンプツール（z 、autojump 、zoxide ）は「過去に訪れたディレクトリに素早く移動する」ことに特化しています。

一方、tryは「実験用ディレクトリの作成と管理」に焦点を当てています。

つまり、tryは「実験のライフサイクル全体」を管理するツールなのです。

インストール

RubyGems（推奨）

1

gem install try-cli

シェル設定に以下を追加:

1
2
3
4
5

# Bash/Zsh - .zshrc または .bashrc に追加
eval "$(try init)"

# Fish - config.fish に追加
eval (try init | string collect)

Homebrew

1
2

brew tap tobi/try https://github.com/tobi/try
brew install try

インストール後、上記のシェル設定を追加してください。

基本的な使い方

1. 実験ディレクトリの作成

1

try redis-pool

これだけで~/src/tries/2025-01-19-redis-poolが作成され、そのディレクトリに移動します。

2. ファジー検索で既存の実験を探す

1

try

引数なしで実行すると、TUIが起動し、すべての実験ディレクトリが表示されます。

→ 2025-01-18-redis-connection-pool    2h, 18.5
  2025-01-03-thread-pool              3d, 12.1
  2024-12-22-db-pooling               2w, 8.3
  + Create new: pool

• →は現在選択中のディレクトリ
• 2hは2時間前にアクセスしたことを示す
• 18.5はファジー検索のスコア（高いほど関連性が高い）

3. Git worktreeで実験環境を作る（そして消す）

try . は、いまいるGitリポジトリから「追加の作業ディレクトリ」を切り出して、そこにcdする機能です。

Gitのgit worktree （ワークツリー、追加作業ツリー）は、同じリポジトリを複数のディレクトリで同時に開く仕組みです。

• git cloneと違い、.gitの履歴は基本的に共有する
• ディレクトリを切り替えるだけで、別ブランチ（または別コミット）を並行で触れる
• 実験や検証を「物理的に分離」できる（node_modulesやビルド成果物も混ざらない）

tryが作るworktreeは何者？（detached HEAD）

1

try .

tryは、現在のリポジトリを元に日付プレフィックス付きのディレクトリを作り、その中をworktreeとして扱います。

例えば、~/projects/my-appでtry . feature-testを実行すると:

~/src/tries/2025-01-19-feature-test/

が作成されます。

ここで出てくるdetached HEAD（デタッチドヘッド）は、ざっくり言うと「ブランチ名に紐づいていない状態でコミットをcheckoutしている」状態です。

• 良いところ: 実験用には気軽（ブランチを汚さない）
• 注意点: そのままだとコミットが行方不明になりやすい（後述）

実験を残したくなったら（ブランチ化）

detached HEADのままでもコミットはできますが、後で見つけやすいようにブランチにしておくのが安全です。

1

git switch -c feature-test

「深夜2時のひらめき」が翌朝も生き残る確率が上がります。

どのworktreeがあるか確認する

「これ、どのディレクトリがworktreeだっけ？」となったときは、元のリポジトリ側で確認できます。

1

git worktree list

worktreeを消すときは？（おすすめ手順）

worktreeの削除は、単にディレクトリをrm -rfするより、Gitに「外した」と認識させるのが安全です。

1. まずworktree側で未コミットがないか確認します

   1	git status

2. 元のリポジトリ側でworktreeを削除します

   1	git worktree remove ~/src/tries/2025-01-19-feature-test

3. もしディレクトリを先に消してしまった場合は、参照だけ掃除します

   1	git worktree prune

注意点:

• worktree内に未コミット変更があると削除できないことがあります。その場合は、コミットするか、git stashで退避してから消すのが無難です。
• detached HEADで作ったコミットは、ブランチ化しないと後でGC（ガベージコレクション、不要になった参照の掃除）で消える可能性があります。残したいなら、git switch -cしておくのがおすすめです。

補足:

• try自体の削除（Ctrl-D）は、いまのところGitのgit worktree remove相当までは面倒を見ません。単にディレクトリを消すので、元リポジトリ側にはworktreeの参照が残ることがあります。
• とはいえ、「実験用ディレクトリ管理ツールがGitの内部状態まで勝手に触るのは怖い」という感覚も分かるので、このあたりは設計として議論の余地があります（私は今の割り切りもアリだと思います）。

4. GitHubリポジトリをクローン

1

try clone https://github.com/tobi/try.git

これで~/src/tries/2025-01-19-tobi-tryにクローンされます。

「構造が自由をもたらす」— tryの設計思想

公式サイトには「Structure Breeds Freedom（構造が自由をもたらす）」という一見矛盾した表現があります。

これは、整理されたシステムがあるからこそ、思考を自由に飛び回らせることができるという哲学を表しています。

実際、tryを使うと:

• 新しいアイデアを試すハードルが下がる: try new-ideaだけで始められる
• 過去の実験を簡単に振り返れる: ファジー検索で即座に発見
• 失敗を恐れなくなる: すべての実験が日付付きで保存されるため、「失敗も研究」として残る

Rust移植版も登場

オリジナルはRuby製ですが、コミュニティによってRust移植版（try-rs） も開発されています。

1

cargo install try-cli

Ruby版と同じ機能を持ちながら、ネイティブバイナリとして動作するため、さらに高速です。

まとめ: 深夜2時のひらめきを翌朝見つけられるか？

tryは、単なるディレクトリ管理ツールではなく、実験的思考をサポートするための哲学を体現しています。

• すべての実験に居場所を与える: test、test2のような名前は不要
• 時間軸で整理: 日付プレフィックスで自然に整理される
• 失敗を恐れない: すべての試行が記録として残る

「深夜2時のひらめき」を翌朝見つけられるかどうかは、ツールではなくシステムの問題です。tryは、そのシステムを提供してくれます。

興味のある方はぜひ試してみてください。

参考リンク

• try公式サイト
• GitHubリポジトリ
• RubyGems: try-cli
• Rust移植版: try-rs
• Tobi Lütke on X