Git の Squash マージをやめた話 - Mobile Factory Tech Blog

こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f

[dorapon2000]

書きました。

[shingo-sasaki-0529]

Squash の簡潔さが大好きだし、途中経過のコミットなんてなんの役にも立たないどころかノイズとまで思ってる。コミットを既に積んでる feature ブランチから孫ブランチを切る運用を避けられると嬉しいんだけど。

[tagomoris]

マージコミット多いのを気にする気持ちがいまだに全くわからない、べつにいいじゃん、と思ってsquashしたい気持ちに全然ならないんだよな

[yukiyan_w]

Squashマージを使う場合は、trunk-based-developmentもセットなのが大前提なのでブランチの生存期間が長い時点で破綻しやすいんじゃないかな。

[benok]

自分はちゃんと意味のある単位でコミットして、プルリク出す前に自己レビューで美しい差分・コミットログにするべく心がけているのでsquashマージなんてありえないと思う。それを皆に求めるのは困難だが目指すべきかと

[k0kubun]

Squashマージ強制だと、PRにPRをネストしてベースのPRをマージすると、ネストしてたPRが必ずコンフリクトするという問題もある

[nazoking]

わかるー。そもそもがgithubのコミット履歴が見にくすぎるのが良くないだけでgithubのuiのせい(含まれるプルリクエストだけ見せてほしい

[hase0510]

no-ffマージの履歴が見づらいという人、log --first-parentじゃダメなの？

[yamadadadada2]

コミットを綺麗に積んでいけば問題にならないし、そもそもPRの粒度が大きすぎる説かも / そんなことはわかってるけどできねえんだよ！という話なのかも。それはそれでわかる。なんとかやっていくしかない

[NetPenguin]

featureブランチが大きくなりすぎていたり、寿命が長くなり過ぎていたりすると、コンフリクト祭りになりやすいよね。 他の人のコメントにある、github uiのせいというのはおおいに同意。

[ropponzo]

アプリ側の努力でSquashマージに見えるよう折り畳み表示すればいいんじゃないの？

[tmatsuu]

Squashマージがよくないのは同意として、mainからfeature/BへのNon FFマージはrebaseでもいいんじゃないかと思いました（自分がよくわかってない可能性はある）。

[miau]

（略）手元で適切な strategy でマージしたら解決したりしないかな？（自信なし） https://git-scm.com/docs/merge-strategies / と書いていたのだけど勘違いしてたっぽい。この運用なら C をマージすべきではないような

[raamen07]

いろんな知見が集まっていてこの記事の価値が高くなっている

[anoncom]

"fix"とか"merge"みたいやつまらないコミットが並ぶならsquashして意味のあるものにしてほしいけど、変更の履歴がまとまりすぎるのは分かりづらくなるからsquash mergeはなぁという気持ちと。適切な粒度でできたら良いけどね

[fuyu77]

GitHubでSquashマージ運用するのってロマンある（コミットの粒度を個別の開発者の性質に依らずに平準化できる）けれど、実際やってみると厄介な問題があるのか。

[nemoba]

そもそもOSSの本質がパッチ駆動などけでそれ理解せず導入しただけでは？

[threewaygood]

人類はいつまで成果物の価値に何ら関係のないバージョン管理のためにこんな辛い思いをし続けるのか…

[onesplat]

squashマジで筋悪よな。元々あったものを無かったことにするから種々の問題が起きるわけで。コミットログを綺麗にしたいなら各自が手元でやればいいだけだしマージコミットが邪魔とか意味わからんしな

[MzdA0w73tg]

"Squash マージのデメリットである「詳細なコミット履歴が失われる」がコンフリクトという形で問題になりました。この状況によるコンフリクトを Squash コンフリクトと命名" なるほど。

[Magicant]

そりゃ squash と non-fast-forward マージを混ぜて使ったらコンフリクトするやろ

[yositosi]

うちもSquashマージにしてこれ困ったけど、スタッフにgit rebase --ontoを教えても解決したよ

[perl-o-pal]

一つのリポジトリを使うのは1枚のピザを分け合える人数までにするとか、別視点のアプローチがいるのかもしれない。

[hiro_curry]

「気合でコンフリクトを解消する」の選択肢があることがgitの柔軟性を担保してると思ってるんで、こういう問題とは付き合い続けないといけないんだろうな。

[atsushieno]

開発ブランチが伸びすぎてしかも内容が雑になりすぎたときは別ブランチで意味のあるコミット単位に再編しながら再構成してsquashはせずにmainに突っ込む、雑すぎなければそのまま、が今の方針だなあ（個人開発）

[nakag0711]

見た目だけの問題でわざわざ履歴の切り捨てなんてする必要ないのでは。まあレポジトリを他所にも公開するとかならともかく…

[peketamin]

やっぱ素朴なのが一番よね

[akymrk]

"main から feature/α ブランチ (子) を切る", “feature/α から feature/β ブランチ (孫) を切る”

[taguch1]

ブランチが伸びる運用はそもそも嫌い。

[wata88]

枝から枝を生やすような使い方を避けてるな

[Funyapu]

PRの修正時にはcommitに--squashしてまとめたりしてる。が、マージ前にrebaseしなきゃなのがだるい

[t10471]

きれいなコミットログを残す苦労よりもシンプルなPRを作った方が良いと思うから、マージコミットの方が好き

[twotiger]

sqaushしてコミット履歴が消えても構わないというのは、開発期間を短くして頻繁にmainブランチにマージするってこと？

[saiid]

“プルリク内のコミットは単一のコミットにまとめられてスッキリする” ←別にスッキリしない件

[queeuq]

わかりみ

[junjun777]

私もsquashやめた。自分一人なら良いけど、まあ、（自分も含め）うっかりさんがいるので、コミットログが長くなるデメリットの方がマシ。

[yamkazu]

Cからrebase -iしてBだけ残せばいいのだよ