https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25

[karikari1255]

主語がでかい案件。mergeの代わりにrebaseすんな、という趣旨は同意。merge前に手元のブランチをrebaseで整える件には言及されていない。個人的にはよくやっている。

[hatsu_mi]

リベースってローカルブランチに対してのみするものだと思ってた。

[ledsun]

github依存が強すぎて、（多人数開発で）ローカルでmasterブランチを編集してpushする世界観に共感できない…

[FunnyBunnyDizzy]

これ読んでpush前のコミット整理にmerge使う人が発生しないといいな。push前のコミット整理するのにローカルでrebase使うのは良いんだからね。意味レベルでコミットの粒度整えた方がレビュアーに優しいから。

[NOV1975]

リベースをそんな目的で使う人いるんだ

[te2u]

ブランチをなくすようなrebaseはやめるべき、ということなら同感。ブランチはそのときに決めたあるひとまとまりの変更点。残しておけば、変更点の全体として理解しやすいかたまりで参照できる。

[mrkn]

おまえの使い方がおかしいんだろwww って思いましたわ。

[chimerast]

さあ、Mercurialを使うんだ 違

[Magicant]

概ね同意 / ブコメ見てると本文を理解しきらず的外れな批判してる人多い

[megumin1]

この人の職場では共有レポジトリに一度pushしたものに対してrebaseをするひどい同僚がいるというだけのしょうもない話だった...。大迷惑ですのでよい子のみなさんは決して真似しないように。タイトルは主語が大きすぎ。

[hnishi2509]

読んだ

[tettekete37564]

ちょっと何を言っているのか分からない。リベースでコンフリクト起きたらマージする前にテスト通せよ。bisect の結果を判定するのは git じゃなくてテストか人間か。道具の使い方を知らないことを道具のせいにするなよ

[kikiki-kiki]

PRをrebaseしてfast-forwardにする意味あると思うけど、rebaseでconfrictが発生するならrebaseせずにmasterを取り込んで解消コミット残した方がいいと思うし、confrictしなくてもCIのテストを通すとかバグを出さない努力は必要と思う

[shifumin]

最初何を言っているのか分からなかったけど、mergeの代わりにrebaseでmasterに取り込む場合の話でそういう世界もあるのか。

[tanjoin]

“リベースは純粋に審美的な操作”

[moegg]

“私はそれが虚栄心であるという結論に至りました。リベースは純粋に審美的な操作です。きれいな履歴は、開発者としての私たちにとって魅力的ですが、技術的または機能的な観点からは正当化できません。”

[yatmsu]

ブクマしてなかったこれ

[yamadashy]

概ね同意。よくわかってない人に強制すべきじゃない

[ma26lib]

“人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前

[thatblue]

rebaseに憤っている理由がイマイチうまく飲み込めずにドキドキしながらブックマーク見てようやく理解した。あと自分のrebaseの使い方が間違ってなかったことにも安堵した。

[yassan0627]

git使ってrebase好きな人にrebase運用押し切られたけど、rebaseの気持ち悪さは残ってて、その気持ち悪さがまとまっててすごく良かった。rebaseはTPOに応じて使う程度に抑え積極的には使わずに、基本的にはマージにしよう。実際

[tmtms]

git rebase は積極的に使って過去のマズいことを最初からなかったかのように歴史改変しまくってます。

[dot]

「git rebaseをやめるべき」というより「git rebaseは適切に使うべき」では。この人の例のような使い方するのはお作法を知らない新人とかくらい。

[hoppie]

git rebaseはこういうふうには使わない。使い方が悪い話で、実作業としてはgit rebaseをやめる理由にはならない。

[takatama]

まだ遭遇したことがないだけなのか？プルリク出すときにテスト回してる

[kompiro]

merge前に手元のブランチをrebaseで整えるときも upstream の baseブランチが更新されやすいプロジェクトだとコンフリクト=修正の連続=綱渡りになるので気をつけてほしい

[nilab]

なぜ git rebase をやめるべきか - Frasco

[otchy210]

rebase はローカルで。push 後は ff しない。が綺麗で運用にも強くて好き。

[tyru]

つい最近もツイートしたけど自分も同じ意見。コミット沢山ある場合は rebase しんどいので merge して最後に squash する

[K2ICE]

“リベースすることは自分自身とチームに対して嘘をつきます。実際は昨日の別のコミットを元にしているが、そのコミットが今日書かれたふりをします。”

[june29]

えっ、そんな rebase の使い方をしていたの…？という感想だった。ぼくは手元で push 前のコミットたちを整える用途くらいでしか使っていないなあ。pull --rebase はよく使う。というか pull のデフォルトの挙動にしている。

[luccafort]

まず大前提としてgit rebaseして歴史を直線的に保つことの意義がぼくには理解できない。歴史を改ざんするのはよくないとぼくらはSFとドラえもんから学んだはずなんだ。

[hiroomi]

”きれいな履歴は、開発者としての私たちにとって魅力的ですが、技術的または機能的な観点からは正当化できません。”分岐点はいろいろな出来事があるから、消し去る価値以上の何かはありそうだけど。

[uturi]

「リベースはダメだからローカルリポジトリのコミットを整理せずにそのままpushだ！」という勘違いが増えそう。ブランチを消去するためのリベースは辞めたほうがいいという点は同意。

[t_yamo]

主題は正しいけどタイトルと始めの方の図と末尾の煽り文で誤読を誘発してる。主題は「rebaseで生じる2ブランチ間の齟齬（単体ではどちらも正しい）による不具合が単体の不具合と混ざると厄介だから気をつけろ」。

[imo_jo_chu]

merge の代わりに rebase は辞めてくれw　コードレビューをしやすくするために手元の feature ブランチを rebase して整頓するのはよくやってる。

[katzchang]

「開発者たちがブランチをリベースさせる動機は何ですか？ 私はそれが虚栄心であるという結論に至りました。」

[rgfx]

「Git はブランチが分岐するような非直線的な履歴のために作られ、またそれを推奨しています。」

[t2wave]

"コミットが多く連なっている場合、リベース中にコンフリクトを解決することは、しばしば混乱を招き、正しく修正するのが難しく、潜在的なエラーの原因"