Q&A
回答ありがとうございます。
もちろんこの場合、プルリクした側が直すのは当たり前だと思うのですが、なぜ「このままではmergeできないので、conflictを修正して、もう一回PUSHしてください」ではなく、「このままmergeできないので、rebaseしてもういっかいPUSHしてください」なのかが知りたいです。
qiitaのgit rebase記事をよんでいて、
PullRequestを送りました報告をしたら
このままmergeできないので、rebaseしてもういっかいPUSHしてくださいと言われました。
とあるのですが、これってどんな場合でしょうか。
mergeできない理由がconflict以外にあると思うのですが、developブランチにmasterブランチをrebaseした場合のcommit Eと、mergeしたときのcommit Eのファイル内容は異なるということでしょうか。
回答3件
0
このままmergeできないので、rebaseしてもういっかいPUSHしてくださいと言われました。
「このままmergeしたくないので」という意味かもしれないですね。
1ヶ月前のコミットから派生させたブランチのPR送られると「おいおいマジかよコミットグラフがびよーんと伸びるからやめてくれよ」と思う人は多そうですよね。Gitにはコミット履歴直線の宗派の人達もいるみたいですし。
投稿2016/09/12 01:17
総合スコア759
0
ベストアンサー
OSSの場合、それが作者に対する礼儀です。
せっかくの提案なのですから、原作者に余計な手間をかけさせないように、コードの整理、そのままマージできるようにする準備などは一通り済ませておきましょう（状況によっては、先に入ったコミットとの関係上、自分の側でコード修正が必要になることもありえます）。
投稿2016/09/12 00:37
総合スコア145184
プルリクを作った時点でのmasterから、オリジナルのmasterが進んでいた場合、そのままmergeしてしまうと、コミットの流れが複雑になってしまいます。そういうことで、masterをオリジナルに合わせるのも、依存関係などをはっきりさせるために推奨されます。
http://qiita.com/ganezasan/items/f7ca66f47bc8067988cf
rebase と merge どちらが良いかは人によって好みがあるので、相手に合わせるのが良いかと思います。
topic ブランチに master を merge した場合はマージコミットのみレビューすればよいですが、rebase してしまうと新しい変更が入り込む余地ができてしまうため、PR 全体をレビューし直すことになります。そのため好まない人もいます。
>maisumakunさん
有用なURLを貼っていただき、ありがとうございました。rebaseすることで、featureブランチが常に最新のコミットとなって履歴がすっきりして、merge担当者は混乱することなく、hotfixできるということですね。
>thincaさん
回答ありがとうございます。私も、mergeで十分じゃないか？とずっと思っていたので、「バグが見つかりました。修正版をマージしてください」の方が直感的で好きですね。ただ、rebaseのメリットもわかったので、よかったと思っています。
0
これってどんな場合でしょうか。
conflict している場合です。
mergeできない理由がconflict以外にあると思うのですが
なぜこのように思ったかわかりませんが、このまま merge できない場合と言うのは conflict している場合になります。
投稿2016/09/11 15:44
総合スコア1864
回答ありがとうございます。それだと、conflictを解消してmergeすれば済むだけな気がするのですが。
それでも問題ありません。必ず rebase する必要はなく、どちらでも大丈夫です。
ただしプロジェクトによっては方針がある場合があるので、もしある場合は従うのが良いと思います。参照された例では、リポジトリオーナーに rebase してくれと言われたので rebase したのだと思います。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/09/12 11:15