EvanのJujutsuチュートリアル

 (evmar.github.io)
1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • Git の利用経験者が、シンプルでありながら強力なバージョン管理システム Jujutsu(jj) を簡潔に学べるよう構成されたチュートリアル
  • 学習前に Jujutsu を使う理由が気になる読者のために、別途 Jujutsu 紹介記事を用意
  • 会話調の入門書、詳細な公式ドキュメント、バージョン管理初心者向け資料など、読者のレベルに合った代替資料も案内
  • テーマの選定と省略、配置順を慎重に決めるため、Evan Martin が自ら執筆
  • 本文の執筆には AI を使わず、ほとんど完成した後に 誤りチェックのみに AI を活用

対象読者と学習ルート

  • Jujutsu はシンプルでありながら強力なバージョン管理システムであり、このチュートリアルでは以降 jj と表記
  • Git に慣れた読者を対象に、要点に集中した簡潔な学習フローを提供
  • すぐに学び始めるなら チュートリアルを始める に進め、導入理由から確認したいなら Jujutsu 紹介記事 を参照可能

読者別の代替資料

  • このチュートリアルの進め方が合わない場合は、経験レベルや好みに応じて次の資料を選択可能

自筆執筆と AI 利用範囲

  • 全文は Evan Martin が自ら執筆しており、何を含め何を省くか、どの順序で配置するかを人間が慎重に決定
  • 本文の作成に AI は使用しておらず、大部分を書き終えた後に誤り確認の用途でのみ活用

関連記事

1件のコメント

 
GN⁺ 1 일 전
Lobste.rs のコメント

  • 正直、評判を賭けて言うなら、jjを1週間ほど使ってみたものの、結局 Git を直接扱う苦痛を減らすために LLM に助けを求めることになり、既存のワークフローを十分に置き換えられるとも感じなかった
    普段は git checkout、git add、git commit、git push 程度しか使わず、宣伝文句で語られるインデックス、スタッシュ、複数種類のリセット、進行中のリベース、一貫性のない取り消しの問題もほとんど経験しておらず、モノレポもあまり使わない
    Jujutsu の主な対象ユーザーは誰なのか、また jj を使いこなせるようになるまでどれくらいかかったのかが気になる。次は少なくともそのくらいの期間は投資してみたい

    • LLM には具体的にどんな作業を手伝ってもらっているのか気になる
      自分も Git では基本作業以外は避けがちで、スタッシュしてからブランチを切り替える代わりにリポジトリを別の場所に再クローンし、関連する変更だけを選んでコミットする代わりに git add --all で全部コミットするか、エディタで変更を戻してからコミットし、再度適用していた
      職場で Mercurial を7年使っていたので jj に慣れやすい背景はあったが、今ではコミットの移動と複数の変更管理が簡単になり、以前なら本能的に迂回していた複雑な作業も積極的にやるようになった
    • バージョン管理システム（VCS）を何のために使うかによって見方は変わる
      線形に開発したコードをときどきスナップショットとして残す程度なら、そのコマンド群で十分だし、完全な VCS は過剰で Dropbox だけでも足りるかもしれない
      自分にとって VCS は、コードとその階層についてどう考えたかを示す物語を構築する道具であり、主な読者は同僚、副次的な読者は10年後の自分だ。jj はそれをはるかに摩擦なく扱えるようにしてくれる
    • LLM に助けを求めても問題ないし、自分も必要な基本コマンドを覚えるまではそうしていた
      用語と機能の基礎をつかむためにいくつかのガイドを最初から最後まで読み、個人プロジェクトで数日間継続して使ったところ、基本作業はかなりこなせるようになり、VCS の見方も変わった
      リファクタリングや大きな機能を開発するときは、まず最終目標まで実装し、その後、レビューしやすく、それぞれの根拠が明確になるように「すべての eslint 警告を修正」「関数公開のためのリファクタリング」「呼び出し元 A を新しい関数へ移行」「新機能を追加」といった小さな変更に分ける。jj split はこの作業に完璧で、この機能ひとつだけでも jj を使う理由として十分だ
      一方で git stash は複数のスタッシュを扱いにくく、衝突時に保存したコードを失う可能性もある危険なユーザビリティ上の罠が多い。下位のコミットに PR フィードバックを反映してから上位のコミットや PR をリベースする作業も、特にスタック型 PR では進捗表示がなく、途中で止めたり積み直したりしにくいため、悪夢に近い。だからスタック型 PR の管理には今でも Graphite を使っている
    • jj で最も大きく得られた利点はリベースの扱い方だ
      有機化学専攻の大学院生が、論文作業用ブランチを4年間マージもリベースもせずに開発し、main より数千コミット遅れた状態で、学位審査を前にマージしなければならなかった。ほぼすべてのコミットで衝突が起きるため Git では1〜2週間かかり、3日目に緊急バグが入るとリベースを中断してバグを直し、最初からやり直さなければならず、3週間後に終わった頃には最新の main に合わせるためにまたリベースが必要だった
      jj ではマージ衝突が第一級オブジェクトなので、余裕のあるときに解決でき、途中で新しいコミットへ移動して緊急バグを直しても進捗を失わない。Git なら1週間かかるリベースを1日で終えられたし、あるときはマージしても何も変わらない連続した200個のコミットを見つけ、数万行の衝突を2日かけて処理していた作業を1分もかからず丸ごと捨てられた。リベース中でも main を更新し、作業中のブランチを最新の main の上へ移せる

  • Git に慣れきっていて、たまにコマンドを調べる程度の自分にとっても、この記事 は初めて面白いと感じたJujutsu の紹介記事だ
    以前の記事は主に「ひどい Git コマンドラインインターフェイスから抜け出せる」という話から始まっていたが、Git の独特な点や他の人たちの苦労は理解していても、そうした表現のせいで Jujutsu をロマンス小説やビーフビンダルーのように自分とは無関係なものだと見なしていた

    • jj の楽しさを説明しにくい理由は、あらゆる VCS に当然あると思っていた暗黙の性質が実際にはそうではなく、原子的な操作がはるかに単純だからだ
      良い宣伝文句を作るのが難しいため、結局「Git ではない」という言葉が説明のすべてを占めてしまうし、自分もこれをうまく説明できないほうだ
    • Git では Sublime Merge の GUI といくつかのユーザー定義コマンドを使えば、ここで言われている問題のほとんどは解決できる
      他の Git GUI と違い、実際の Git コマンドをできるだけそのまま踏襲しつつ、難解な構文だけをメニューやボタンに置き換え、各操作に対応するコマンドも隠さずステータスバーに記録してくれる。Sublime JJ が出たらすぐ乗り換えるつもりだ
    • 自分に jj を試してみたいと思わせた表現は、常に対話的リベース状態にある Gitだった