rebase 教から脱退します - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中に

[parrying]

よほど大規模とかでない限りコミットログの綺麗さから得られるものってお気持ちしかないので基本的にはrebaseするなでファイナルアンサー

[ku__ra__ge]

これは git push -f が悪いのであって、git commit --amend でも同じ問題は発生する。

[mak_in]

リベースで整えるの完全に諦めてる。この記事にもあるように、事故るから。プルリクで良いじゃん。リベースで整える時間があるなら他のことしていたい。事故や整理時間を気にして開発のスピードが落ちるのも嫌だし

[dozo]

force pushはgithub上で無効にしてる。内容整えたければsquashマージとかでいいし、コミットログの読みやすさにあまり意味を感じない

[xenon_abe]

コメントまで見るとはっきりするけど、問題の本質をよくわかってないみたい。参考にしなくて良い。

[manimoto]

SVNの他の人とタイミング調整しないとcommitできない、branch切るのに申請書が必要だったりがGitにより解放されたはずだったのが、Gitもレビュー終わるまでrebaseするなや運用方針議論せよとか起きてて、やはり真の敵は人間

[mon_sat]

-fではなくgit push --force-with-lease --force-if-includesでforce pushしてる。コメントについてはそのとおりなのでrebaseした旨のコメントを残し、それまでのレビューには対応していることを記している。よりよいやり方あれば知りたい

[nunulk]

いやー、コミットログはきれいにしてほしいなぁ。ローカルではrebase、いったんプッシュしたらmerge、だけど大事なのはトピックブランチを長期間放置しないこと。rebaseもmergeもしないのがいちばんいいので

[nakamura-kenichi]

もうちょっと現場でgit運用について話し合ったほうがいいやで。人の話は聞いたほうがええやで。知らんけどｗ。

[hylom]

push -fコマンドを使うなルール、チーム開発では絶対ルールだと色々なところで言われていると思うのだが……rebaseを使うこと自体は悪くなくて、fast-forwardじゃない状態を作るのが良くない

[als_uz]

コミット整えるならレビュー前後 / rebaseはする

[azumi_s]

forceオプションが何故オプションなのかというお話では…。

[kagerouttepaso]

rebaseしてコンフリクトしたら諦めてmergeしてる。自分には100%ミス無くコンフリクトを解消する自信はない。そして共有ブランチをforce pushするな。

[diveintounlimit]

masterマージミスって事故る率高いので、こういう状況ならrebaseなしは有効打になり得ると思った。マージミスってrebaseして事故ると原因追いかけるのが難しくなる。コメ欄見たが意思疎通できてるのか怪しい感じがする。

[onesplat]

記事タイトルに[私は素人です]って書いてくれねえかな。紛らわしいから

[theatrical]

どうでも良いが棄教ではないかと思いつつも、脱退でも間違いではないか？などと思うところ。特定の団体から離れるというより、教えを否定すると考えると棄教が適切に思う

[uva]

一度レビュー状態にしたなら以後はforce push禁止です

[baronhorse]

コミットログは大事だよ。細切れにするとコンテキスト落ちてそれこそレビュー困難になるしそれなりの粒度のPRならまともな履歴ないとやっぱ読みづらい。書く側は気にしない方が楽だけどその分の負担は読者が負ってる

[furu_ichi]

いや、rebaseよりもgit push -f するなよ。

[atsushieno]

コミットログの綺麗さから得られるものがお気持ちしか無い、っていう非論理的な主張で片付けられる現状はまずいので、ログの読みやすさには定性的な評価基準が必要そう / 本文にあるやり方で本件は解決している

[morucy]

それよりもまずforce pushするなが先では？

[renos]

rebaseもうなんもわからん、自分が手入れてないのにすげー差分でるときあるし…

[circled]

物凄く最初の頃に将来のことなんて一切考えずにコミットしてた自分のテスト用ローカルDBのコード直書き環境変数箇所消したいとかあるよね

[oisux]

人に見せるまではrebase、人に見せたらmerge

[strawberryhunter]

rebaseは自己満足。それ以上は無い。

[clairvy]

コンセンサスかな、と思う。個人的にはどっちでもいい。とはいえ、そのレベルの操作できないのはマズイので、ジュニアにはやれと強制すると思う。

[aktkro]

rebaseのせいではなくないか

[HAZI]

rebaseはレビュー終わったらやってるかな…。訂正もレビューはいったらfixup! つきでコミットして、レビュー後にgit rebase –autosquashするようにしてfixup! , squash!着きコミットはマージできないようにブロックしてた

[tomei10]

force pushが原因じゃん

[knok]

自分も好きではないがそういうフローを求められているのでやってる

[objectiveworker]

これまで一回もrebaseを使った事がない。merge一択。他社でやっていける自信がない。

[m50747]

rebaseはプルリクエスト作成されるまでの個人レベルではあり。他のメンバーに共有したら禁止。

[kazkaz03]

レビュー中にforce pushする必要があったら面倒でもプルリク作り直しですね

[tokuniimihanai]

レビューの最中にコードを書き換えるなってだけの話では？レビュー投稿後ならforce pushでもコメント消えないよね？