http://blog.inouetakuya.info/entry/20130602/1370173582

[at_yasu]

最近はfeatureで作業用ブランチを大量に切り分けて、develop を事実上のmasterにしてる。

[matsubobo]

べつに、git mergeだけが答えじゃないから、表記を何とかして欲しい。鵜呑みにする人居るはず。

[ruedap]

基本的に同意で同じようにやってるけど、チームによってはrebaseでコミットログ重視だったり、masterマージ前にsquashで1個にまとめたり、とかのお作法もありそう

[ichi2410]

slideshareって途中のスライドから貼付けられるのか...

[neotag]

rebase そのものは全然よいのであって、 rebase がなぜ悪いかわからない状態のほうが怖いなと思いました。

[Lian]

rebaseしてた……。masterに再mergeするときはよしなにしてくれるんだろか

[satojkovic]

サーバにpushしてないブランチはrebaseでもいいんかな？

[m4i]

「rebase しちゃってた」とのコメントが多いけどそれで良い。push してなければ rebase の方が良いケースが多いと思う。

[honeybe]

rebaseとmergeの使い分けは難しいです＞＜(月並みな感想

[l08084]

memo2

[ryota-murakami]

安心した

[hs_hachi]

これではまった

[tasogare30]

むう、そうだったのか。

[gkojax]

「以前、チーム内で Subversion を使っていた時期は、リリース直前に、作業用ブランチを trunk にマージすると、盛大にコンフリクトが発生して死亡、というケースが散見されていました。」

[WhatAmILookingFor]

こまめにマージすると、pull request取り込む側の人がレビュー時に「差分がよくわからん」とか言うんだよなぁ・・

[k-holy]

重要なのはトピックブランチの目的から外れた履歴をmasterに残さないことかなー

[h5y1m141]

そもそも一人でもくもく開発してるだけなので、この状況にそもそも出会えない。どうでもいいけどこのブログの人はペパボの人だったことに今更気づいた

[redhornet96]

やってみた

[asonas]

トピックブランチで開発してるのが1人ならrebase使う。複数人でコミットしてるならmerge。状況に応じて使い分る。そもそもトピックブランチにmergeコミットが連なるのはそのブランチの本質ではないしログ見ていて邪魔

[kfujieda]

こういう疑問を抱くことなく使える人だけがGitを使う世の中だったらよかったのに。

[te2u]

mergeであってもrebaseであっても、その言葉の意味以上のことをしないように気をつけている。/変更点を管理するという点でとても参考になった記事 → http://d.hatena.ne.jp/tanaka51/20120530/1338386845

[UDONCHAN]

ある

[a2ikm]

ため息漏らさせたことがあるので反省してる

[indication]

おお、やばい、rebaseしまくってた

[ysakmrkm]

Git の疑問。トピックブランチで作業中に、master ブランチで重要な変更が加えられた。どうすればよい？ - 彼女からは、おいちゃんと呼ばれています

[gologo13]

Rebase 一択だも思った

[dai_air]

見てれぅ：Git の疑問。トピックブランチで作業中に、master ブランチで重要な変更が加えられた。どうすればよい？ - 彼女からは、おいちゃんと呼ばれています

[aklaswad]

おお、こういう時はrebaseするもんだと思い込んでた。

[lizy]

svnでもまずはtrunk->branchにマージしてコンフリクトを解決してから、branch->trunkにreintegrateするのでは

[invent]

Git の疑問。トピックブランチで作業中に、master ブランチで重要な変更が加えられた。どうすればよい？ - 彼女からは、おいちゃんと呼ばれています