2022/03/22 10:36
takatama
developブランチなら、git rebaseでログを綺麗にするのはメリット大。バグフィックスとかとは分けて考えるべき
2022/03/22 14:13
cartman0
rebaseは改変のイメージ強いな
2022/03/22 15:40
kobito19
conflict 起きたときの解消方法を考えると、むしろ rebase しない merge の方が改変感強い/自分もレビュー始まったらコミット動かすな派だったけど、やってみたら別に問題なかった/ブコメで squash機能と勘違いしてる奴いてそう
2022/03/22 16:10
rryu
pushしていないブランチでブランチ元に追い抜かれたら普通にrebaseするけどpush済みのやつが悩ましい。綺麗さを取るならリモートブランチを消してrebaseして再pushだが…
2022/03/22 16:36
endo_5501
自分もrebaseする方が好み
2022/03/22 16:46
noritada
ブコメの派閥の多様さ…。自分は、記事のケースに限ればmerge派。ブランチの共有やPRの前にローカルでrebaseやsquash、複数ブランチへの分割などの整理は必ずする。レビュー開始後のコミットハッシュ変更は避けている。
2022/03/22 16:58
otchy210
最初に教わったのが rebase だったから、というのもあるだろうけど、「ローカルの」rebase はぜんぜん抵抗ないな。リモート側でやったら歴史改変だけど、ローカルでやる分には自分だけ世界線移動した感じじゃない？
2022/03/22 17:08
tyhe
rebase はコミットが積み上がった状態でやって初期にコンフリクトが発生してたりすると芋づる式にコンフリクトが続いてシンドいとか、その間に解消ミスが発生して予期せぬ不具合が紛れ込むとかあるから苦手。
2022/03/22 17:20
sechs
rebase時にはrerere機能trueが必須。一度コンフリクト解消したら次は同じところでコンフリクトでない。
2022/03/22 17:38
for-my-internet-demo
mergeに戻ってしまった
2022/03/22 17:51
turanukimaru
intellij で develop からローカルに rebase してコミットしてプルリク、で一動作として覚えてるからそこはあまり考えてない。どうせコンフリクトは解消しなきゃだし。merge 使うメリットなんかあったっけかな…？
2022/03/22 17:58
daichirata
少なくとも PR 出す前の手元なら rebase してる
2022/03/22 18:24
lHMaUyzK
「git fetch ; git rebase develop」origin/developじゃないとダメな気が
2022/03/22 18:32
rkosaka
マージするのが普通なリポジトリでもマージする直前にrebase masterしてテスト通るか試したりする。
2022/03/22 18:45
w1234567
プロジェクトの初期にはrebaseちゃんとやろうよではじめて結局mergeになるパターンばっかだったので最近は諦めた
2022/03/22 19:19
Wafer
csvからsubversionはスムーズに移行できたがsubversionからgitは悪戦苦闘してrebaseが何かすらさっぱり理解できてないのでmerge一択
2022/03/22 19:20
gfx
ブログ主の「rebaseは歴史改変だから不安」こそが正しい認識だと思うけど…。
2022/03/22 19:28
daigo0117
散々やっちゃ駄目だと教えられて来たので、いまだに心理的ハードルが高い。
2022/03/22 19:29
kazuhooku
圧倒的merge派。git logが綺麗でうれしいことはないけど（ツリーをたどりつつ、当該コミットで変更の理由を見ればそれで十分だから）、PRレビューしたあとにrebaseされるとレビューした文脈が消えるのが辛すぎる
2022/03/22 19:45
zkzi3254
push -fはあまりやりたくない
2022/03/22 19:47
Nobkz
どうでもいい。
2022/03/22 20:05
yug1224
forkしてrebaseしてsquashしてPR出して欲しいけど、merge commitは作りたい派
2022/03/22 20:07
lesamoureuses
log graphよく見るからレビュー前ならmaster rebaseしてforce pushしてわかりやすくしちゃうし、レビュー中ならレビュー内容消えないようにmergeする。デザイナがレビュー出すときは簡単だからmergeしてって言うことが多い。
2022/03/22 20:18
remonoil
維持できないものに価値は無いと思うのでmerge派。rebase派って後任の後任がmerge派だったらどうするの？
2022/03/22 20:34
ryousanngata
merge派。あとバックアップブランチを作るところ、要は作業前のコミットに戻したいという事だと思うので、多分reflogを知れば幸せになれる。
2022/03/22 20:34
programmablekinoko
マージする前の単一ツリーでリベースなら許す派
2022/03/22 20:50
nilab
あなたはmerge派？rebase派？綺麗なGitログで実感したメリット - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
2022/03/22 20:59
perl-o-pal
merge派かなあ。ローカルでrebaseしないこともないけど、それ目的ならmergeでいいんじゃん。//logを整理することがバグを減らすことに繋がるのか、そのへんを詳しく知りたい。
2022/03/22 21:01
marshi
1のビルド通らないかもしれない不安を消すためであればブランチ運用よりCI回すのがいいように思う。
2022/03/22 21:36
alfe1025
git merge developしてからSquash and merge派。1プルリク1コミットになって誰が何のために何をしたのかわかりやすくなる。
2022/03/22 21:48
geerpm
宗教だから正解ないと思ってるけど、バグが起きにくいというのは同意しづらい。コンフリクトはrebaseでも起きて解消が必要。まあ自分はmerge派なので色眼鏡はあります。
2022/03/22 21:53
amwm
PR出す前はrebaseで、後は必要不可欠なmergeだけしてくれ派
2022/03/22 21:53
yimajo
日常的なコマンドに取り返しのつかない操作が1個でもあってそれを選ばないで済むなら、自分ならマージコミットを作るなあ
2022/03/22 22:07
Jinmen
時と場合によると思う。数人しかリポジトリを見ないならmergeの方が細かい履歴が残るし、リポジトリに関わる人数が多いならローカルブランチで出たバグとかレビュー修正なんか知らんからrebaseしてから持ってこいとなる
2022/03/22 22:08
htsign
push --force は怖いので、どうしてもエラーが出てしまう場合を除いて極力 push --force-with-lease --force-if-includes にしている
2022/03/22 22:11
assaulter
手元rebase、他の人が触るようになったらmergeかな…
2022/03/22 22:22
stilo
rebase派。というかrebaseしか経験したこと無いし、rebase地獄を見てきた者だ。 #Git
2022/03/22 22:28
BOOOOOOOON
logが綺麗でよかった！！！　って試しがないのよね～　だからmerge
2022/03/22 22:33
n314
ダメじゃんと書こうと思って、読んだらこの方式ならアリというか推奨？って思いつつブコメ読んだらリモート…？push -f は無しだよ！rebaseかmergeかの前に、まずpush -f 派を分けなきゃ。
2022/03/22 22:54
Bryntsalov
なんでもいいから、俺に強制するな派。
2022/03/22 23:04
moromoro
rebaseに1票
2022/03/22 23:30
justgg
PRベースの開発をしていればログが綺麗で嬉しいことってないから、rebaseっていらないんじゃないかとすら思ってる。
2022/03/23 00:27
chinpokomon_master
レビュー出す前にrebaseしてくれや派
2022/03/23 00:27
ryer
ぼくの commit log には wip wip wip と延々並んでいるので、PR出すまえにはrebase必須なんです。テキトーでごめんなさい。（PR出したあとはちゃんとlog書きます）
2022/03/23 00:32
yamadadadada2
rebaseして綺麗なコミットツリーを守っていくという文化をチームで厳格にできていると強い。そこまで含めての技術力でありコミュニケーションなのでは
2022/03/23 00:41
yn3n
タイプする機会が多すぎてrebase origin/master をromってアライアスにしてる
2022/03/23 00:49
redreborn
チーム開発ならmerge、オレオレならrebase
2022/03/23 02:23
ed_v3
このフローならfeatureブランチからdevelopにマージするときにsquashじゃないかな。featureのサイズによるけど。とりあえずレビュー始まってからのrebaseは辞めてほしい。
2022/03/23 02:28
i178inaba
自分しか該当ブランチ触ってないときはrebase、他の人も見る・触るようになったらmergeにしてる。
2022/03/23 02:42
lbtmplz
rebaseやめろルールがあったな…
2022/03/23 03:39
atsuououo
対応内容によって最適解が異なると思うけど、管理側としては内容に応じてやり方を変えるのは難しいか。／小粒の対応ならrebaseで良いけど、大きな対応ならmergeの方が良いと思う。どのみち影響確認は必要。
2022/03/23 04:02
degucho
ミスも含めてログだからrebase否定派。ツイ消しとか増田削除と同じようなもん
2022/03/23 05:04
hatakazu93
技術
2022/03/23 05:08
azzr
手元では雑commit、雑merge。PR出すときはsquashしてrebaseして、適度に切り分けた後に提出。review後はtrunkへmergeする派。
2022/03/23 06:31
omega314
私もこの記事に書いてある感じでrebase使う派。
2022/03/23 07:04
lalupin4
push する前に rebase してから merge すればいいんだっけ（俺はしないけど）？
2022/03/23 07:28
h_taiji
試してもいいのかも？
2022/03/23 07:43
koseki
開発中にコミットに言及しないのかな。一度リモートに出したコミットIDが変わるのナシだと思うけど。
2022/03/23 07:53
mayumayu_nimolove
自動化できるといいんだけど
2022/03/23 08:43
chiroruxx
Squash merge派です
2022/03/23 08:59
diveintounlimit
ログがきれいで助かる事が特にないのでrebaseでもmergeでも好きにしたら良い
2022/03/23 09:16
Fushihara
gitの次のバージョン管理システムが出来るとしたら、このへんのログの見やすさを重視してほしいところ
2022/03/23 09:35
tekmak
mergeしてsquashは既存の履歴が消えるので許されない
2022/03/23 09:37
tattyu
rebaseでコンフリクトするとマジで死ぬので嫌いだわ。dev取り込んでからコミットでええやろ。
2022/03/23 09:39
tettekete37564
rebase はマージの一種のはずなんだけど。/ 単純に手順の話か
2022/03/23 09:48
buhoho
ローカル作業は基本リベース。リモートリポジトリ追加はマージ一択
2022/03/23 09:50
NOV1975
ローカルブランチのログとかいる？って聞いた答えで決めるべきかな。まあ規模次第だよね。
2022/03/23 10:01
toshihiko150
私は2の方法をつかっている。1は良くないし、3はなんか怖いのもわかる。
2022/03/23 10:55
hatenyamo
リベースはコミットの途中で思わぬ挙動になっていることがあるので、マージのほうがそれぞれの歴史で正しく動いていたという意味で安心感がある。作業意図の整理の意味でのローカルリベースは使う
2022/03/23 11:22
Chisei
レビュー前なら rebase 派。レビューに入ったら以降は merge 派。
2022/03/23 11:24
eichisanden
プルリク出す前にdevelopは取り込んで欲しいが、個人のgit力の差があるのでrebaseかmergeかは任意にしてる。あとpush -fは最終手段なのであまりやらないが、1人で開発してるブランチにpush -force-with-leaseはカジュアルにやる
2022/03/23 11:36
rjge
自分の手元だけならrebaseでレビューとか他の人が絡んだらmerge派。git logが綺麗でよかったというか汚くて辛い目にあったのでせめて自分は人が見る前に整えるくらいはしたい
2022/03/23 15:11
Syunpei
この記事をおすすめしました:
2022/03/23 15:49
hayashikousun
６人だからできるのかな？メンバーが６０人居たらリベース終わった頃にはまた別のブランチがマージされていそう。