あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」

BIGLOBEの開発現場の様子や、developブランチにrebaseで綺麗なコミット履歴を作る方法をご紹介します。 はじめまして！ GitHubを中心に仕事がまわる開発現場 Git logが綺麗だとバグが起こりにくい？ developブランチを綺麗に保つGit操作（マージ編） 1. そのまま気にせずdevelopにマージする。 2. 最新のdevelopをfeature/Bブランチに取り込んでからdevelopにマージする 3. 最新のdevelopにrebaseしてからマージする ﾘﾍﾞｰｽ ｺﾜｸﾅｲｮ 最後に はじめまして！ 基盤本部（開発部門）の江角です。 2021年8月にSIerからBIGLOBEに転職し、半年が経過しました。 転職期間中はもちろんコロナ禍で、カジュアル面談も面接も全てオンラインでした（多分今もそうだと思います）。 入社日当日は出社しましたが、入社してから半年の

[kazuhooku]

圧倒的merge派。git logが綺麗でうれしいことはないけど（ツリーをたどりつつ、当該コミットで変更の理由を見ればそれで十分だから）、PRレビューしたあとにrebaseされるとレビューした文脈が消えるのが辛すぎる

[daichirata]

少なくとも PR 出す前の手元なら rebase してる

[otchy210]

最初に教わったのが rebase だったから、というのもあるだろうけど、「ローカルの」rebase はぜんぜん抵抗ないな。リモート側でやったら歴史改変だけど、ローカルでやる分には自分だけ世界線移動した感じじゃない？

[kobito19]

conflict 起きたときの解消方法を考えると、むしろ rebase しない merge の方が改変感強い/自分もレビュー始まったらコミット動かすな派だったけど、やってみたら別に問題なかった/ブコメで squash機能と勘違いしてる奴いてそう

[gfx]

ブログ主の「rebaseは歴史改変だから不安」こそが正しい認識だと思うけど…。

[sechs]

rebase時にはrerere機能trueが必須。一度コンフリクト解消したら次は同じところでコンフリクトでない。

[BOOOOOOOON]

logが綺麗でよかった！！！　って試しがないのよね～　だからmerge

[Jinmen]

時と場合によると思う。数人しかリポジトリを見ないならmergeの方が細かい履歴が残るし、リポジトリに関わる人数が多いならローカルブランチで出たバグとかレビュー修正なんか知らんからrebaseしてから持ってこいとなる

[tyhe]

rebase はコミットが積み上がった状態でやって初期にコンフリクトが発生してたりすると芋づる式にコンフリクトが続いてシンドいとか、その間に解消ミスが発生して予期せぬ不具合が紛れ込むとかあるから苦手。

[w1234567]

プロジェクトの初期にはrebaseちゃんとやろうよではじめて結局mergeになるパターンばっかだったので最近は諦めた

[vottie]

私はmerge派ですと言えるようになりたい。

[hayashikousun]

６人だからできるのかな？メンバーが６０人居たらリベース終わった頃にはまた別のブランチがマージされていそう。

[Syunpei]

この記事をおすすめしました:

[rjge]

自分の手元だけならrebaseでレビューとか他の人が絡んだらmerge派。git logが綺麗でよかったというか汚くて辛い目にあったのでせめて自分は人が見る前に整えるくらいはしたい

[eichisanden]

プルリク出す前にdevelopは取り込んで欲しいが、個人のgit力の差があるのでrebaseかmergeかは任意にしてる。あとpush -fは最終手段なのであまりやらないが、1人で開発してるブランチにpush -force-with-leaseはカジュアルにやる

[Chisei]

レビュー前なら rebase 派。レビューに入ったら以降は merge 派。

[toshihiko150]

私は2の方法をつかっている。1は良くないし、3はなんか怖いのもわかる。

[NOV1975]

ローカルブランチのログとかいる？って聞いた答えで決めるべきかな。まあ規模次第だよね。

[buhoho]

ローカル作業は基本リベース。リモートリポジトリ追加はマージ一択

[tettekete37564]

rebase はマージの一種のはずなんだけど。/ 単純に手順の話か

[tekmak]

mergeしてsquashは既存の履歴が消えるので許されない

[Fushihara]

gitの次のバージョン管理システムが出来るとしたら、このへんのログの見やすさを重視してほしいところ

[diveintounlimit]

ログがきれいで助かる事が特にないのでrebaseでもmergeでも好きにしたら良い

[chiroruxx]

Squash merge派です

[mayumayu_nimolove]

自動化できるといいんだけど

[koseki]

開発中にコミットに言及しないのかな。一度リモートに出したコミットIDが変わるのナシだと思うけど。

[h_taiji]

試してもいいのかも？

[lalupin4]

push する前に rebase してから merge すればいいんだっけ（俺はしないけど）？

[omega314]

私もこの記事に書いてある感じでrebase使う派。

[azzr]

手元では雑commit、雑merge。PR出すときはsquashしてrebaseして、適度に切り分けた後に提出。review後はtrunkへmergeする派。

[hatakazu93]

技術

[degucho]

ミスも含めてログだからrebase否定派。ツイ消しとか増田削除と同じようなもん

[lbtmplz]

rebaseやめろルールがあったな…

[i178inaba]

自分しか該当ブランチ触ってないときはrebase、他の人も見る・触るようになったらmergeにしてる。

[ed_v3]

このフローならfeatureブランチからdevelopにマージするときにsquashじゃないかな。featureのサイズによるけど。とりあえずレビュー始まってからのrebaseは辞めてほしい。

[kenkenpa198]

わかりやすい！！コメントも参考になる

[yn3n]

タイプする機会が多すぎてrebase origin/master をromってアライアスにしてる

[yamadadadada2]

rebaseして綺麗なコミットツリーを守っていくという文化をチームで厳格にできていると強い。そこまで含めての技術力でありコミュニケーションなのでは

[chinpokomon_master]

レビュー出す前にrebaseしてくれや派

[ryer]

ぼくの commit log には wip wip wip と延々並んでいるので、PR出すまえにはrebase必須なんです。テキトーでごめんなさい。（PR出したあとはちゃんとlog書きます）