【 Git コマンド】commit してしまった変更をなかったことにするには
commit してしまった変更をなかったことにするには、今まで $ git reset
ばかり使ってきたけれど、他にも色々な種類があるらしい。
このページ
gitで一度行った変更をなかったことにする方法4つ - TIM Labs
にまとめられているので、参考にしていきたい。
【 Git コマンド】ステージングしたファイルの diff を表示したいときは
$ git diff
で表示される diff は、ステージング前のものに限られる。
ステージングしたファイルの diff を表示したいときは
$ git diff --staged
としてやればいい。
$ git diff --cached
や
$ git diff HEAD
でも同じ結果が得られる。
【 Git コマンド】ステージングしたファイルをアンステージングするには
$ git add foo.txt
でステージングしたファイルをアンステージングしたいときは
$ git reset HEAD foo.txt
としてやれば、アンステージングできる。
参考: d.hatena.ne.jp
テストではなく、通常時の JavaScript にブレイクポイントを挿入したいときは
テスト ではなく、通常時の JavaScript にブレイクポイントを挿入したいときは、 JavaScript 中に debugger
と書くことで binding.pry
のようにプログラムを止めて JavaScript のデバッグができる。テスト実行時と違い、通常時では Selenium が立ち上がらないので、 Chrome 以外のブラウザを使用しているときは Chrome を手動で起動し、 Chrome Developer Tool を立ち上げておくこと。
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
で発生しているエラーらしい。
のコメントに「 evaluate_script
でエラーが出るときは execute_script
を使ったらいいよ」と書かれていたので、その通りにしたら、テストが通るようになった。
じゃあ、 execute_script
と evaluate_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_script
と evaluate_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.list
を vi
などで開いて追加・修正してやればいい。
/etc/apt/sources.list
を修正した後は、忘れずに
$ sudo apt-get update
としてやって、リポジトリの更新を反映させること。