![](https://cdn-ak-scissors.b.st-hatena.com/image/square/910fb9fe70685659ded82077c04d68a80fa6344b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9cmViYXNlJTIwJUU2JTk1JTk5JUUzJTgxJThCJUUzJTgyJTg5JUU4JTg0JUIxJUU5JTgwJTgwJUUzJTgxJTk3JUUzJTgxJUJFJUUzJTgxJTk5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05NDA0M2UzYTVlOWRhYzc1NGQxMTM1NTU5MjQzYWJjMQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBLYWl0b011cmFva2EmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTQyODE3MjI5Njg2NzhiYzMyZmU5ZWJmNDkzMjA4NWJl%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g44Gp44GZ44GT44GE5aG-%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Da3452c5be7870b15c2225dfb173c0075)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント35件
- 注目コメント
- 新着コメント
![mak_in mak_in](https://cdn.profile-image.st-hatena.com/users/mak_in/profile.png)
mak_in
リベースで整えるの完全に諦めてる。この記事にもあるように、事故るから。プルリクで良いじゃん。リベースで整える時間があるなら他のことしていたい。事故や整理時間を気にして開発のスピードが落ちるのも嫌だし
![manimoto manimoto](https://cdn.profile-image.st-hatena.com/users/manimoto/profile.png)
manimoto
SVNの他の人とタイミング調整しないとcommitできない、branch切るのに申請書が必要だったりがGitにより解放されたはずだったのが、Gitもレビュー終わるまでrebaseするなや運用方針議論せよとか起きてて、やはり真の敵は人間
![mon_sat mon_sat](https://cdn.profile-image.st-hatena.com/users/mon_sat/profile.png)
mon_sat
-fではなくgit push --force-with-lease --force-if-includesでforce pushしてる。コメントについてはそのとおりなのでrebaseした旨のコメントを残し、それまでのレビューには対応していることを記している。よりよいやり方あれば知りたい
![nunulk nunulk](https://cdn.profile-image.st-hatena.com/users/nunulk/profile.png)
nunulk
いやー、コミットログはきれいにしてほしいなぁ。ローカルではrebase、いったんプッシュしたらmerge、だけど大事なのはトピックブランチを長期間放置しないこと。rebaseもmergeもしないのがいちばんいいので
![hylom hylom](https://cdn.profile-image.st-hatena.com/users/hylom/profile.png)
hylom
push -fコマンドを使うなルール、チーム開発では絶対ルールだと色々なところで言われていると思うのだが……rebaseを使うこと自体は悪くなくて、fast-forwardじゃない状態を作るのが良くない
![diveintounlimit diveintounlimit](https://cdn.profile-image.st-hatena.com/users/diveintounlimit/profile.png)
diveintounlimit
masterマージミスって事故る率高いので、こういう状況ならrebaseなしは有効打になり得ると思った。マージミスってrebaseして事故ると原因追いかけるのが難しくなる。コメ欄見たが意思疎通できてるのか怪しい感じがする。
![baronhorse baronhorse](https://cdn.profile-image.st-hatena.com/users/baronhorse/profile.png)
baronhorse
コミットログは大事だよ。細切れにするとコンテキスト落ちてそれこそレビュー困難になるしそれなりの粒度のPRならまともな履歴ないとやっぱ読みづらい。書く側は気にしない方が楽だけどその分の負担は読者が負ってる
![atsushieno atsushieno](https://cdn.profile-image.st-hatena.com/users/atsushieno/profile.png)
atsushieno
コミットログの綺麗さから得られるものがお気持ちしか無い、っていう非論理的な主張で片付けられる現状はまずいので、ログの読みやすさには定性的な評価基準が必要そう / 本文にあるやり方で本件は解決している
![hylom hylom](https://cdn.profile-image.st-hatena.com/users/hylom/profile.png)
hylom
push -fコマンドを使うなルール、チーム開発では絶対ルールだと色々なところで言われていると思うのだが……rebaseを使うこと自体は悪くなくて、fast-forwardじゃない状態を作るのが良くない
![HAZI HAZI](https://cdn.profile-image.st-hatena.com/users/HAZI/profile.png)
HAZI
rebaseはレビュー終わったらやってるかな…。訂正もレビューはいったらfixup! つきでコミットして、レビュー後にgit rebase –autosquashするようにしてfixup! , squash!着きコミットはマージできないようにブロックしてた
![objectiveworker objectiveworker](https://cdn.profile-image.st-hatena.com/users/objectiveworker/profile.png)
objectiveworker
これまで一回もrebaseを使った事がない。merge一択。他社でやっていける自信がない。
![nunulk nunulk](https://cdn.profile-image.st-hatena.com/users/nunulk/profile.png)
nunulk
いやー、コミットログはきれいにしてほしいなぁ。ローカルではrebase、いったんプッシュしたらmerge、だけど大事なのはトピックブランチを長期間放置しないこと。rebaseもmergeもしないのがいちばんいいので
![manimoto manimoto](https://cdn.profile-image.st-hatena.com/users/manimoto/profile.png)
manimoto
SVNの他の人とタイミング調整しないとcommitできない、branch切るのに申請書が必要だったりがGitにより解放されたはずだったのが、Gitもレビュー終わるまでrebaseするなや運用方針議論せよとか起きてて、やはり真の敵は人間
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
いまの話題をアプリでチェック!
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
rebase 教から脱退します - Qiita
rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変...
rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は﹁コミットログが見やすく保たれるため﹂です。Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中にブランチ元の変更があったので、git rebase からのgit push -f origin [ブランチ名] やったらレビュアーのコメントが吹き飛びました。 いやー、めっちゃ怒られたよね💦 原因 ﹁レビュー中﹂という状況がまずかった。 コードを共有し
2024/04/21 リンク