poyopoyo0のブログ

poyopoyoのブログ

Web 関連のメモ書きブログです。

【 Git コマンド】commit してしまった変更をなかったことにするには

commit してしまった変更をなかったことにするには、今まで $ git reset ばかり使ってきたけれど、他にも色々な種類があるらしい。

このページ

gitで一度行った変更をなかったことにする方法4つ - TIM Labs

にまとめられているので、参考にしていきたい。

【 Git コマンド】ステージングしたファイルの diff を表示したいときは

$ git diff

で表示される diff は、ステージング前のものに限られる。

ステージングしたファイルの diff を表示したいときは

$ git diff --staged

としてやればいい。

$ git diff --cached

$ git diff HEAD

でも同じ結果が得られる。

テストではなく、通常時の JavaScript にブレイクポイントを挿入したいときは

テスト ではなく、通常時の JavaScript にブレイクポイントを挿入したいときは、 JavaScript 中に debugger と書くことで binding.pry のようにプログラムを止めて JavaScriptデバッグができる。テスト実行時と違い、通常時では Selenium が立ち上がらないので、 Chrome 以外のブラウザを使用しているときは Chrome を手動で起動し、 Chrome Developer Tool を立ち上げておくこと。

参考: yoshitsugufujii.github.io

debugger が働いた状態で F10 をクリックするとステップオーバー、 F8 をクリックすると次のブレイクポイントまでスキップしてくれる。

Selenium で個別テストを実行するときのコマンド

このコマンドが必要になる度に、何度も調べ直しているので、メモ書き。

$ SELENIUM=1 ruby -Itest test/integration/foo_test.rb

と Terminal から打ち込めば、 Selenium で個別テストが実行できる。 テストに binding.pry を入れて実行すると、一行づつテストを進めながら Selenium でブラウザを確認できる。

フロントエンドの JavaScript が絡んでいるときは、 Selenium でテストを実行させ、テストコード中に binding.pry を挿入して実行を止めて Chrome Developer Tool を立ち上げれば、 HTML の状態を調べたり、同 console で JavaScript を実行したりできる ( Chrome Developer Tool の立ち上げショートカットは Command + option + i )。

execute_script と evaluate_script の違いって何だろう

Capybara でテストを実行した際、下記のようなエラーが出てテスト失敗することがある。

1) Error:
TopTest#test_Post_note:
JSON::NestingError: nesting of 101 is too deep
    test/integration/top_test.rb:65:in `block in <class:TopTest>'

テストのソースを見たら evaluate_script で発生しているエラーらしい。

github.com

のコメントに「 evaluate_script でエラーが出るときは execute_script を使ったらいいよ」と書かれていたので、その通りにしたら、テストが通るようになった。

じゃあ、 execute_scriptevaluate_script って何が違うんだろう、と疑問に思ったので、 binding.pry で二つの違いを追っかけてみた。結果は以下の通り。

1. execute_script の動き

capybara-webkit/lib/capybara/webkit/driver.rb

def execute_script(script)
  value = @browser.execute_script script
  value.empty? ? nil : value
end

capybara-webkit/lib/capybara/webkit/browser.rb

def execute_script(script)
  command('Execute', script)
end

capybara-webkit/lib/capybara/webkit/driver.rb

def execute_script(script)
  value = @browser.execute_script script
  value.empty? ? nil : value
end

2. evaluate_script の動き

capybara-webkit/lib/capybara/webkit/driver.rb

def evaluate_script(script)
  @browser.evaluate_script script
end

capybara-webkit/lib/capybara/webkit/browser.rb

def evaluate_script(script)
  json = command('Evaluate', script)
  JSON.parse("[#{json}]").first
end

ここで

JSON.parse("[#{json}]").first

を実行すると

JSON::NestingError: nesting of 101 is too deep
from /vendor/bundle/ruby/2.2.0/gems/json-1.8.3/lib/json/common.rb:155:in `parse'

とエラー(= この記事の冒頭で出ていたエラーと同じ)が出てしまうが、

JSON.parse("[#{json}]").first

の代わりに

JSON.parse("[#{json}]", max_nesting: 101).first

としてやると、エラーが出なくなる( 参考 )。

3. 結論

execute_scriptevaluate_script でやってることは同じだけど、evaluate_script の方は Command の返り値を JSON.parse してて、そこで nest が deep になる…、ということらしい。

テストで返り値を使ってないのであれば、 evaluate_script は使わず execute_script に統一しておいてもいいかも。

GitHub で auto merge できないときは

参考サイトを覚え書き。

GitHub で auto merge できないときは、こちら qiita.com のページを参考に、 $ git merge master を行う。

その際の commit message は Merge branch 'master' into <ブランチ名> とかにしてやれば分かりやすい。

なお $ git merge master 関連でトラブったときは、大抵こちらの記事 yskmanabe.blogspot.jp が役に立つ。

【 Git コマンド】ブランチ名を一度変更した後、再度元に戻したい場合は

$ git checkout -b foo

でブランチを切った後、

$ git branch -m bar

でブランチ名を変更することがあるが、その後で、やっぱり最初のブランチ名に戻したいときがある。そのときは

$ git checkout -

と打てば、ブランチ名を foo に戻せる。

【補足】

ブランチ名を foo から bar に変更した状態で

$ git branch -m foo

と打っても、

fatal: A branch named 'foo' already exists.

とエラーが出てしまうので、そういうときに上記のコマンドを使う。

参考: d.hatena.ne.jp

GitHub に投稿した commit message を修正するには

GitHub に投稿した commit message を修正するのにえらいこと手間取ったので、忘れないように覚え書き。

参考記事:yuzu441.hateblo.jp

1. まず始めに

$ git log --oneline

で過去の commit をterminal に表示させて、修正対象の commit を見つける。

2. 直前の commit の commit message を修正したい際には

$ git rebase -i head~1

と打ち込むと vi エディタが立ち上がる。

3. 立ち上がった画面で pick となっているところを reword と修正して保存(※ この画面で commit message も変更してしまうと、リビジョン番号自体が変わってしまうので、要注意。この画面で修正するのは pick だけ!! )。

4. 次にようやく commit message の修正画面が立ち上がるので、そこで commit message を書き換えて保存すると、commit message の修正が完了する。

5. これだけだとローカルの commit message が修正されただけなので、これを GitHub に反映させるには

$ git push -f origin ブランチ名

のように強制 push してやればいい。

【補足】
ちなみに、 $ git reset head~○○ と打ち込むと、最新の commit から○○番目の commit を無かったことにできるので、便利。もし○○の数字を間違って入力してしまった際には、

$ git reflog

と入力すると、 $ git reset も含めた履歴が表示されるので、

$ git reset --hard HEAD@{1}

としてやると、 $ git reset を取り消せる。

参考記事: Git/git reflog (git resetを取り消す) - yanor.net/wiki

追記:

$ git reset --hard ORIG_HEAD

でも、上と同じ操作ができるとのこと。

参考記事: www.backlog.jp

git はお役立ちコマンドがいっぱいありそうだけど、あり過ぎて混乱気味…。

apt の基本(学習週)

学習週のプラクティスに apt の基本 というのがあって、項目の終了条件が apt についてブログに書く ということだったので、覚え書き。 以下の環境は、さくらの VPS でカスタム OS インストールした直後の Debisn 7 です。

apt コマンドでパッケージをインストールするには sudo コマンドをインストールしておいた方がいいので、su コマンドでスーパーユーザーになった後、

# apt-get update
# apt-get install sudo
# adduser <ユーザー名> sudo

としてやって、スーパーユーザーをログアウト。こうすれば、<ユーザー名> のアカウントが、sudo グループに追加される。 続いて、目的のパッケージを以下のようにインストールする。

$ sudo apt-get install <パッケージ名>

パッケージ名がうろ覚えのときは

$ sudo apt-cache search <パッケージ名>

で探す。パッケージの詳細が知りたいときは

$ sudo apt-cache show <パッケージ名>

インストールしたパッケージをアンインストールしたいときは

$ sudo apt-get remove <パッケージ名>

アンインストールする際に、パッケージの設定ファイルも削除したいときは

$ sudo apt-get purge <パッケージ名>

インストールした際に依存関係で一緒にインストールされたパッケージも一緒にアンインストールしたいときは

$ sudo apt-get autoremove <パッケージ名>

インストールするパッケージを unstable にしたかったり test にしたかったり、その他、デフォルト以外のリポジトリに変更したいときは /etc/apt/sources.listvi などで開いて追加・修正してやればいい。 /etc/apt/sources.listを修正した後は、忘れずに

$ sudo apt-get update

としてやって、リポジトリの更新を反映させること。