jjを使っていて驚いた「1つの変更を育てていく」という哲学

jjを使っていて驚いた「1つの変更を育てていく」という哲学 はじめに 前回の記事でjj (Jujutsu) の基本的な使い方を紹介しました。ファイルの変更が自動で記録され、コミットメッセージを後から書けるという便利さに魅了されて使い始めたのですが、使っているうちにもっと根本的な思想の違いに気づいてしまいました。 それは「1つの修正に対して1つの変更単位（change）を使い、説明を上書きしていく」というスタイルです。作業履歴はローカルにとどめ、共有するのは1つのchangeのみ。issueやPRに対してもchangeは1つで、手元の作業履歴をどんどん修正していきます。 つまり、複数のコミットを積み重ねるのではなく、1つの変更を完成するまで何度も更新し続けるのです。まるで盆栽を育てるように、同じ変更を丁寧に育てていくイメージです。 これは、Git/GitHubに慣れた私にとって大きな思想の転

[megumin1]

PRをMergeする前に、squashするのを必須にすれば同じことでしょ。それはGitHubでもはるか昔から可能であり、Gitでもよく見かける"哲学"ですけど、知らなかったのかな？

[snowcrush]

gitって使い方が自由で人によってワークフローが違うしそもそもベストプラクティスの理解も怪しいことが多いのでjjが特定の哲学を強制するツールになってるのはそれはそれで意味があると思うよ

[k12u]

この記事は設計思想と体験が違うという話をしており、『gitではできないだろバーカ』と言ってるわけではないが批判してる人は何と戦ってるの

[toro-chan]

無能側の私としては、1コミットに集中させるのは非効率(というか無理)なのであまり賛同はできない。結局コロコロコードを変えることになるので逆(複数PRを束ねる)の方がありがたい。なのでtagを多用してる。

[igrep]

作業ブランチだったら実際Gitでも既にそれっぽい運用してるんだよなぁ

[closer]

レビュー対応した後の push は force push なのか？再レビューの際にまた全部見直す(追加の差分だけ見れない)のは大変だと思うけど。あとでかいPRは細かくコミットして欲しい

[ropponzo]

jj普段使ってるけど、別にこの「哲学」を強制されたりは全くないよ。jj squashコマンドは使いたい人だけ使うのでは？　単にMercurial代替として使ってる人も多そう。

[nazoking]

マージ時スカッシュは、prブランチを前提として派生prブランチ作ったらとても辛くなるが

[maninthemiddle]

Githubでもお行儀よくやる場合はこうなるようにコミット圧縮とかしますよね。ツール側で強制してくるのは良いかも

[tmatsuu]

「ファイルを編集するだけで、その操作履歴が自動的に記録」でありつつ最終的には1つのchangeに集約と。我々が本当に欲しかったもの感がある。

[tettekete37564]

「履歴」管理という観点ではどうなのかね。リリースコミットしか履歴に残さない思想なんだよね？管理者はそれで良いかもだが長期的保守管理をする&入れ替わりのあるエンジニア視点では疑問が残るなあ

[kahlua-dane]

PRレビュー中にその変更を含んだブランチを作る時とかはどうなるのかなぁ gitの理論であればmainからの変更差分であるべきなのだけど、状態を持ったものはbranch_a（PR中）から作ったbranch_bのPRとか必要になるからなぁ

[zgmf-x20a]

呪術廻戦の影響は？w

[fashi]

rcs/cvsに戻っただけでは？

[abstruct3431]

要するに「規約を守れないおバカさんたちのために規約を強制するシステム」ってだけでしょ？少なくともシステムを理解できてないであろう初学者に与えるべきではなく、そこを卒業したらこのツールはただの足かせ

[everybodyelse]

squash mergeと考え方的には同じなのかね。それを標準にしてるというのは面白いけども。

[yn3n]

マージする時にsquashさせるとこもさせないとこもあるけど、個人的にはsquashあんま好きじゃないんだよなあ。多少コミット履歴が汚くなっても歴史が残ってた方がいい。

[myr]

jujutsu気になっているけどまだ導入できていない...

[ibukichi_jp]

Gitでもできるが、Jujutsuには1チケット＝1コミットにして将来のコード<->チケットの検索の易化を目指すGerritの哲学を実践しやすくする機能が用意されてる感じか。ほう。ならPRの単位はサブタスクで調整かしら？

[clairvy]

結果にコミットする

[sailoroji]

コミットを絶対に remote にプッシュしないといけないと思っているのか？そんなこと誰もやってないだろ。

[moke222]

呪術？頂上は同じで、登り方が違うだけ。自分に合う方で。自分の意識の外から考え方が飛んでくると驚くのはわかる。自動コミットはそれだけで価値があるかも

[kobito19]

まあ(筆者の理解が合ってるのなら)コメントに書いてることが全てだよなあ。squashが必要と感じてるかどうかだけ

[mkusaka]

Zennの記事で、ツールjjを使って筆者が驚いた『1変更1コミット』という哲学について、経験や印象を中心に記した解説記事です。筆者の感想と考察をまとめている。

[atsushieno]

github flowでやっていても普通なのでは。1つの変更を複数のゴミコミットで永続的に残されても後から問題追跡するとき邪魔でしょ。 / 「批判」はまともなgitユーザーならそもそも「驚く」はずはない、というものが大半では

[hylom]

「1変更1コミット」ではなく1つのissueに対して1コミットですよね、これを1つのissueに対して1つのpull requestと言い換えれば普通の話なのでどこにフォーカスするかと言うだけの話

[swdrsker]

哲学としては新しくないけどchange-idとして仕組みとして用意してるのは面白い

[naka-06_18]

jjだと履歴操作が楽ってことかな

[yarumato]

“作業履歴はローカルにとどめ、共有するのは1つのchange（jjではコミットのことをchangeと呼ぶ）のみ。重要なのは、同じコミット（1つの論理的なchange）のまま、内容だけを修正、更新し続ける。ブランチを使わずにすむ”