- Git 12©2ch.net
494 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:19:59.27 ID:MjY1jVeQ - >>482
＞数秒で終わらないのが困るのなら、大量にあるコミットが
＞ある状態で、rebaseとかどうするのさ？
だから、「間を飛ばしたコミットまとめをしない」って言ってるんじゃないのか？
A→B→C→Dの順にコミットされてるなら、連続したBCやBCDをまとめるのは
コンパイルや自動テストに問題ないから。
|
- Git 12©2ch.net
496 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:49:40.28 ID:MjY1jVeQ - その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが
なんでfeatureブランチの各コミットを直接masterにつなごうとするのかがよく分からない
このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
|
- Git 12©2ch.net
499 ：デフォルトの名無しさん[sage]：2015/05/20(水) 22:58:20.56 ID:MjY1jVeQ - 何となくだが、
＞master(1) → master(2)
＞ ＼AC→B→D
これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
これが許されるチームなら、各メンバーが自由にコミットをまとめても、たしかに問題ないな。
|
- Git 12©2ch.net
502 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:19:51.82 ID:MjY1jVeQ - >>500
AとCをまとめますか？の回答には「そう思う」だが、
AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。
AとBとDはブランチを分けるな。
もしブランチを分けとけば、レビュー前？Push前？にAのバグに気付いても、AとCのコミットは連続してるだろうからな。
逆に、レビュー後？Push後？に問題に気付いたなら、自分の負けを認めてバグ修正のコミットを残す。
一方、後になって「コミットが連続しない、AとBとDをブランチに分けておけば良かった〜」なんてなるようなら、自分の腕のなさを呪ってブランチを切りなおす？？？かな。
|
- Git 12©2ch.net
503 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:21:45.30 ID:MjY1jVeQ - >>501
＞そんなのすぐに終わる。たった2回（ACとB）じゃないか？
「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
|
- Git 12©2ch.net
507 ：デフォルトの名無しさん[sage]：2015/05/20(水) 23:39:45.06 ID:MjY1jVeQ - 例えばC言語だったらヘッダファイルを書き換えれば多くのソースファイルに影響するし、
自動テストのテストケースの中には「アプリケーションの再起動」が含まれていることもあるかもしれない。
例えばWebサイトの開発とかでは、そういうのほとんどないだろうし、ぶっちゃけ過去より今が大事なのかもしれない。
（過去の状態が「Webサイトの純然たる作りかけ」とかだったら、そのスナップショットを完全に残すことに価値はないだろうし）
だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
その方が、短期的な効率は出るだろうしさ。
|