- Git 9
248 ：デフォルトの名無しさん[sage]：2014/04/29(火) 13:47:07.80 ID:+oyspTjV - プロジェクトの性質にもよるし、そのブランチで音一連の変更がどの程度の変更量かだったり、変更の意味にもよるし、mergeやrebaseをする人の技量にもよるよな。
merge/rebaseについて検索すると、mergeはログが分岐するから良くない、原則rebaseするべきとかいうブログが出てくるけど、
http://blog.layer8.sh/ja/2013/04/08/best-git-commands-for-the-lonely-programmer/ (ちょっと違う例だけど)
こういうのって、ケースバイケースでしかないのに、mergeは悪！rebaseは正義！みたいに思っていそうで、
しかもこういうのを読んでmergeやrebaseの利点欠点について理解してない人たちがまたmergeは悪！rebaseは正義！と思い込んでしまって、害しかないと思うんだよな。
pullしてマージが発生したら「これでは自分が持っていたコミットの方が正統としているようなものです。origin へ push したのは a と b の方が先なのに…。」とか意味不明もいいとこ。
|
- Git 9
256 ：デフォルトの名無しさん[sage]：2014/04/29(火) 15:48:55.09 ID:+oyspTjV - >>252
rebase && FFが適してるような状況ってのは普通にあると思うよ。
複数人で開発していて、担当者がモジュールごとにほぼ完璧に分かれているような場合でかつ、クライアントがシステムの仕様についての微修正を一度に広範囲にわたって、何回も指示するような場合。
実際には作業分担が発生するから並行した開発が行われ、それによってブランチが分岐するが、それは作業上の都合であって、修正指示と1:1対応しているものではないから、嬉しいブランチの使い方ではないでしょ。
そういうときにはrebase && FFがベストケースだと言えるような気がするけど。
|
- C++相談室 part112
379 ：デフォルトの名無しさん[sage]：2014/04/29(火) 16:20:13.81 ID:+oyspTjV - ケースバイケースだろ。
プログラムの処理目的によっては、fcloseに失敗しようがどうでもいい場合もあるんだから、そういう場合にあえて書かなくたっていいでしょ。
まあ、癖としてエラー処理を書くようにするというのは悪いことではないと思うけど。何が何でも絶対にエラー処理を書かないといけない、みたいな原理主義はよくないでしょ。
|
- Git 9
265 ：デフォルトの名無しさん[sage]：2014/04/29(火) 16:30:46.56 ID:+oyspTjV - >>262
ブランチを明示的に分けなくたって、複数人が同じブランチで作業したら実質的にはローカルブランチの分岐が発生しているわけだから、
pushするためにpullするときにマージが発生するでしょ。
|
- Git 9
289 ：デフォルトの名無しさん[sage]：2014/04/29(火) 23:30:04.09 ID:+oyspTjV - 「履歴が一直線になってわかりやすい！」かどうかって、もはやコミットの順序というものにどういう意味があるかどうかという意味論なのだから、
ケースバイケースでしかないだろう。
アプリケーションの見た目を変更するときにAプランとBプラン、どっちもやってみて、Aプランから20%、Bプランから80%採用、なんてときは履歴が一直線になってないほうがいいだろうし。
(そんな変更をマージコミット一つで済ませてしまうのか、という問題はあるが)
結局、履歴が一直線になってたほうが良い場合もあるし、良くない場合もあるというだけだろ。どっちかが明らかに正しいというもんじゃない。
|