[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

228users がブックマーク コメント 43

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

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

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント43件

  • 注目コメント
  • 新着コメント
オーナーコメントを固定しています
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マージに見えるよう折り畳み表示すればいいんじゃないの?

その他
オーナーコメントを固定しています
dorapon2000
オーナー dorapon2000 書きました。

2023年11月29日 リンク

その他
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はなぁという気持ちと。適切な粒度でできたら良いけどね

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

2023年11月30日 リンク

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

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

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

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

2023年11月30日 リンク

その他
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に突っ込む、雑すぎなければそのまま、が今の方針だなあ(個人開発)

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

2023年11月30日 リンク

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

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

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

2023年11月30日 リンク

その他
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だけ残せばいいのだよ

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「Git の Squash マ...」が注目されています。

気持ちをシェアしよう

ツイートする

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

こんにちは!ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかった... こんにちは!ブロックチェーンチームでエンジニアをしている 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

ブックマークしたユーザー

  • urahsam2024年09月26日 urahsam
  • nekonado2024年06月26日 nekonado
  • techtech05212024年06月20日 techtech0521
  • hajimepg2024年04月01日 hajimepg
  • katsukiniwa2024年03月08日 katsukiniwa
  • knj29182023年12月22日 knj2918
  • shirokurostone2023年12月17日 shirokurostone
  • toshi-toma2023年12月09日 toshi-toma
  • hush_in2023年12月06日 hush_in
  • fkshom2023年12月06日 fkshom
  • s_hiiragi2023年12月04日 s_hiiragi
  • donotthinkfeel2023年12月03日 donotthinkfeel
  • k_wizard2023年12月03日 k_wizard
  • kumokaji2023年12月03日 kumokaji
  • tmatsuu2023年12月03日 tmatsuu
  • takehirohattori2023年12月03日 takehirohattori
  • mikage0142023年12月02日 mikage014
  • lugecy2023年12月01日 lugecy
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /