- Git 11©2ch.net
686 ：デフォルトの名無しさん[sage]：2015/03/01(日) 10:32:38.67 ID:Lvi8ZCHX - >>678
20個前のコミットのメッセージを1個書き換えるだけじゃなくて20個全部書き変えたいってことでいい？
git commit は-Fでエディタを立ち上げずにコミットメッセージを書いたファイルを指定できるから予め20個編集済みのファイルを用意しとくか、
既存のメッセージを機械的に書き換えられるなら git showのオプションを調整してログメッセージだけ表示させたやつを
perlなりsedなりで書き換えた後git commit -F - --amend にパイプで食わせるようにするとかで一気に行けそうだが。
|
- Git 11©2ch.net
687 ：デフォルトの名無しさん[sage]：2015/03/01(日) 10:50:10.22 ID:Lvi8ZCHX - 手間を考えると >>684 の書いてるようにTODOリストで r (reword) 使うのが一番楽だな
|
- Git 11©2ch.net
709 ：デフォルトの名無しさん[sage]：2015/03/01(日) 20:58:42.01 ID:Lvi8ZCHX - Git本家のやり方は良いよね。
俺もあの考え方をベースに単純化して運用してる。
|
- Git 11©2ch.net
715 ：デフォルトの名無しさん[sage]：2015/03/01(日) 22:14:43.93 ID:Lvi8ZCHX - >>712 解説乙。
bisectについて補足する。
「new_featureブランチ（全部履歴残す版）」だと
bisectが止まったコミットが本当にmasterのHEADに影響してるか信頼できない。
(bisectが止まったコミットを調べて原因発見したと思っても、
後の修正コミットで何度も試行錯誤されて変更されたりしてると、
最終的にHEADで問題を引き起こしてる原因とは違ってたなんてことがおこる)
逆にトピックブランチのコミットを全部ひとつにスカッシュしてしまうと
bisectで止まったときに見ないと行けない変更量が必要以上にでかくて調べるのが面倒。
「new_featureブランチ（rebase版）」くらいの
ひとつひとつは意味のある単位で、かつできるだけ小さい粒度の複数のコミット
にまとめるのが妥当な落とし所って感じ。
もちろんbisect以外に「あのトピックでどうなってたっけ？」みたいに見直すだけの時も、
そのトピックの成立がわかりやすいストーリーになってるほうが読み解くのに効率が良い。
(むしろこっちのほうがシチュエーションとしてはよくある)
|