🤔 状況

• バグがない時点のコミットをnobug1234とする
• バグっている時点のコミットもある

• その技術やフレームワークに疎くて、バグを特定できそうにない

  • （しかも、こういう場合は大抵、簡単な規約に違反している場合である）
• 自動テストがない（自動テストが漏れていた）

👍 方法

1. バグっていないコミットからブランチを作る(ここではbug/masterとする)

   • git branch -b bug/master nobug1234

2. バグっているコミットのHEADに移動する

3. バグがない時点のコミットと比較し、以下の大まかに復活させる呪文を参考に、戻す

   • ここでの目的は、バグのない状態に近づけることで、問題のなさそうなファイルだけは現状（バグのある時点）にしたままに留め置くことにある
   • テストして、うまくいくまで続ける
   • [推奨]次の作業で戻しすぎたときに、戻れるようんい、テストしてうまく行った時点のスクリプトをメモしておく

4. 現代に戻す呪文 を参考にして、bug/master少しずつ現代に戻す（何度か繰り返す）

   • ここでの目的は、問題が起こっているファイルをザックリ絞り込んでいくことにある
   • 絞り込みは、二分法 - Wikipediaを参考に、１つずつではなく、半分くらい戻してみてテスト、またその半分くらい戻してテスト.. としていくと、早い。

5. バグを引き起こしたファイルが３〜５ファイル程度にまで特定できてきたら、 微調整の呪文 を参考に問題のファイルを特定する

   • このときも、success/index.mdのヘッダも含めて消していたことに問題があることがわかりました。内容だけ消せばよかったのね…と気づけました。
   • プログラムを読んで解決する方法もありますが、ちょっと利用したいだけで、そんなに奥に入り込みたいわけでないものは、こうやってデバッグする方法もありかもしれません。

大まかに復活させる呪文

git diff bug/master --name-only  | grep -v content/posts/2019-08 | grep -v content/sample_posts/2017 | grep -v content/sample_posts/draft | xargs git checkout bug/master --

現代に戻す呪文

$ git status | grep file: | cut -d ':' -f 2 | xargs rm
$ git status | grep deleted: | cut -d ':' -f 2 | xargs git rm --

微調整の呪文

$ git checkout HEAD -- content/meta/config.js
$ git checkout HEAD -- content/pages/success/index.md
$ git checkout HEAD -- content/parts/footnote.md

$ git checkout bug/master -- content/meta/config.js
$ git checkout bug/master -- content/pages/success/index.md
$ git checkout bug/master -- content/parts/footnote.md