うちのブログの 前回の更新 が man の話だったので、更新せざるを得ない。
tldrコマンド、今初めて存在を知ったけどめっちゃ便利や、これがほしかった pic.twitter.com/SxV0KWXZYK
— hnkz (@hnkz1015) May 3, 2021
ということで、これめちゃくちゃ便利ですね。
https://tldr.sh が公式ページです。
GitHubを見てみると、 かなりの数のコマンド が対応しています。
日本語 も結構対応していっていますね。
manよりもコミュニティドリブンなところがハマった人がすぐに貢献できそうで、tipsが貯まる感じになりそうで良さそうです。
例えば、 ls をとってみると、、、
$ tldr ls
ls
List directory contents....
最近はVSCodeなどのIDEが開発に使う言語に問わずハイスピードで普及して、フロントエンドエンジニアでもバックエンドエンジニアでもコマンドを叩くことが少なくなってきたように思います。
若干老害トーク感がありますが、僕が新卒の頃は必ずサーバーにログインして何らかの作業を誰もが当たり前のようにやっていました。
それでも、少なくなったとはいえ、全くコマンドを叩かずに済むエンジニアはいないでしょう。まだ今日のGUIやその他のインターフェースは、CLI(Command line interface)より優れた部分はあれど、全てが優れているわけではありません。
多くのCIはshellをサポートしていますし、Dockerでもやはりコマンドを使うことがあります。また、コマンドはコピペして簡単に再現できるので、まだwikiや手順書にこの順番でコマンドを実行してくださいと書かれることも多いでしょう。
wikiの中にわからないコマンドがあり、意味を知りたい場合はどうしましょう？
例えば $ ls -ltr の意味がわからなかったとしましょう。 $ ls の意味はわかっても、オプションの意味がわからない場合、あなたはどうしますか？
ls -ltr とGoogleで検索すればある適切な結果が表示されるかもしれません。しかし、2020年現在全てのコマンドラインオプションで検索しても、なかなか Gooleは適切な答えを表示してくれません。とくに短いコマンドラインオプションについてはかなり不正確です。
man ls としてみましょう。...
railsでテストコードを少なくする技術 - TDD on railsの間合い - Qiita
以前、上記のような記事を書きました。
「Model SpecやRequest Spec/Feature Spec(今ならSystem Spec)を中心に書いて、実装速度を上げていこう」という話でした。
その後、Ruby on Railsのコードを読み書きする中で、自分自信の考えが少し変化しました。ここで一度新しい僕のRuby on Railsでのテストとの向き合い方をまとめたくなりました。
いろいろと変化している部分があり長くなるので、今回はModel SpecのValidationの書き方を以前のコードと比べつつ見ていきましょう。
前述の記事のvalidationのテスト という項目のコードです。(一部改変しています)
describe Post, type: :model do
describe '#validate' do
subject { Post.new params }
context '全てのデータが正しいとき' do
let(:params) { body: "iiyon" }
it { is_expected.to be_valid }
end
context '正しくない場合' do...
Ruby on Railsの作者であるDHHは、2012年に投稿されたブログポストの中では5つの技術書を紹介しています。タイトルは『The five programming books that meant most to me』。
The five programming books that meant most to me: http://t.co/u0RKkEU7
— DHH (@dhh) December 26, 2012
日本語でいうと「私がもっとも参考になった技術書 5選」といったところでしょうか？
どのような本を選んだのかと、その本に関するエピソードや読み方？のようなものを書いていきます。
5つの本は以下になります。名著と呼ばれるものが並んでいますね。
どんな種類のテストでもrandomにテストは落ちてしまうことがあります。
Ruby on Railsを利用している場合にもっともこのような不安定なテスト (flaky test) になりがちなのは、Capybaraを利用したsystem test/system specではないでしょうか。
私がrandomに落ちるテストと戦った中で得た経験をここに記しておきます。
ページ遷移の直後や描画された直後にclick_linkやclick_buttonなどを実行すると、ブラウザの描画よりもブラウザを操作するテストの実行が早く走ってしまいrandom落ちを引き起こします。
そういうときの解決策として sleep 0.5 などとして、テストの実行を止めるアイデアを思いつくでしょう。
しかし、capybaraは Capbypara.default_max_timeout までは、対象のコンテンツを探してくれるメソッドが用意されています。
ですので、基本的に自前でsleepする必要はありません。
例をいくつか挙げておきます。
click_link '次へ' # ここでrandom落ちしたら
within '.some_dom' do # 次への親要素を探すまで待たせる
click_link '次へ'
end
find('.next').click # 次へのリンクを探してからクリックする
別に問題じゃなさそうなことに問題って名前をつけたのは公式で用意してくれているバッチインターフェースが二つあって、いつも迷っちゃうからだ。
$ rails foo:bar:baz
のようにコマンドを作れるのがrake taskです。
これは普通にrails db:migrateやrails g scaffold Fooのようにいろいろなところで開発者が使うからおなじみのコマンドです。
もう一つのインターフェースが、rails runnerと呼ばれるやつで、こちらは引数に自由にruby(しかもrailsの資産をつかった)のコードを書くことができる。
基本的にどっちを使っても問題はありません。しかしrails runnerを作るときはインターフェースを自分で考える必要があります。以前言及した記事としては app/batches 配下にバッチフレームワークのようなものを作り、 rails runner FooBatch.run のように書くものでした。
自前のバッチフレームワークのようなものが必要なのはひょっとしたら過去の時代の話かもしれません。例えばkuroko2やjenkins、rundeckのようなcron replacementと呼ばれるツール群を使えば、共通処理で書いていた排他制御やロギングなどをそちらに任せることができます。そしてkuroko2やjenkinsの先ではrailsの入ったdockerを実行させるようなことも簡単にできます。...
GitHub が新たに開発した GitHub用のCLIツールがめっさ便利なので、勢いあまって記事を書いたのですが、塩漬けにしていたので、とりあえず公開。
もう速報性はなくなってしまったけれど、便利に使っています。便利。
cli/cli： GitHub’s official command line tool
これね。
$ git push origin feature-bransh
したあとは、そのまま
$ hub pull-request -o
とするのが手癖として根付いています。
手癖になってはいるのけれど、解決できていない問題がありました。
それはPull Requestをdraftで生成できないことです。
ですので、DraftのPull Requestを作りたい場合は $ hub browse を使ってブランチを表示。その後、ブラウザ上でPull Requestを作成していました。
$ gh pr create -w
これを使えば今までやりたかったPull Requestの作成が簡単になるだけではなく、全てをdraftで作ってから細かい点をブラウザ上で修正するというワークフローがやりやすくなりました。
見た目を伴う修正の場合は、スクリーンショットをPull Requestのdescriptionの項目に貼ったりしますので、この辺りも便利です。
...
オンラインコミュニティnoraneeresのメンバーと一緒に、愛媛県八幡浜市に行ってリモートワークをしてきました。
...
はい。 #しがないラジオmeetup 4 - connpass に参加してまいりました。
(そういえばpodcastの話はあんまりしなかったな〜)
『しがないラジオ』というpodcastを一回でも聞いたことがある人が参加できるmeetupです。podcast好き率高めですが、エンジニアとかそういう縛りは特にありません。
今回は公募枠LT5枠とスポンサーLT1枠、パーソナリティのお二人のLT2枠と、懇親会という内容でした。
見事、公募枠のLTに当選し登壇してきました。
最近、登壇とかやってなかったし、LTにしては10分と割と枠があったので、緊張感もあり楽しめました。
— すぎちゃん🎙🎧💻 (@koheiSG) December 17, 2019
なんだか、見境のなくあやかりまくったスライドが気がついたらできてました。ごめんなさいmm
10分のLTにスライドは40枚。
緊張と早口で大阪弁全開でまくしたて立ったぜ。
...
流しのRails業でチームの中で共有したtipsをちょっとずつブログにも書いていくぞという。気持ち。
ちょっと初心者向けの話題のように思うかもしれないけれど、私もなんども苦しんだことなので。
$ rails g scaffold Book name:string price:integer
scaffoldでこのように生成したとしよう。
そうすると、BooksController#create は以下のように生成される。
# POST /books
# POST /books.json
def create
@book = Book.new(book_params)
respond_to do |format|
if @book.save
format.html { redirect_to @book, notice: 'Book was successfully created.' }
format.json { render :show, status: :created, location: @book }
else
format.html { render :new }
format.json { render json: @book.errors, status: :unprocessable_entity }
end
end
end
もう少し簡易化してみましょう。
# POST /books
def create
@book = Book.new(book_params)
if @book.save...
プロジェクト管理ツールBasecampの最高技術責任者、デイヴィッド・ハンソンさんの仕事術 | ライフハッカー［日本版］
iA writerを知ったのも、この記事だった。
自分のタスク管理のやり方を見直そうとなんとなく調べていたら、こんな記事を見つけた。
確か、以前にも読んだことがある内容だったんだけれど、iA writerもタスク管理の方法も試せていなかった
DHHという憧れの人物のタスク管理が響かないタイミングもあるんだな。本当に人生はタイミングですね。
私はほとんどのことにNoと言っています。そうすれば、自分で本気で選んだ少数のことにだけに、完全にコミットできます。
余計なことは人生から取り除けば時間はたっぷりあるはず。
明日はいくつかNoと言えるようにしたい。
メールのInboxを空にすることには執着しています。
僕はメールはほとんど見ないけれど、DHHのGTDの基本はメールになっているよう。
また、slackは本当に有害だと思うので、どうにかしたい。
あとはtwitterを読まないということも大事だよなぁ。フォローを減らすなりリストしか見ないなり情報を減らす必要がありそう。
一般的に私がトラッキングするのは、自分のコントロールが及ばないことに関してだけ
私の場合はomnifocusを整理する必要がある。...
このソフトはめっちゃいいです。このソフトが刺さる人は下記のランディングページの動画を見ただけで釘付けになって、とっさにダウンロードしてしまうはずです。
iA Writer： The Benchmark of Markdown Writing Apps
iA Writer updates for the public betas of iOS 13 and Mac OS Catalina are available. Some small bug fixes, too. Update and enjoy. Tell us over mail ([email protected]) if you find something funny. https://t.co/rOOtgFcqyG pic.twitter.com/j1WbnZnD6A
— iA Writer: The Writing Experience. (@iAWriter) August 12, 2019
何がいいって、書けば書くほど集中できます。...
現在フリーランスのエンジニアをしています。
— すぎちゃん@noracast (@koheiSG) January 25, 2019
常駐仕事、リモート仕事、請負仕事を同時並行的にやっています。
技術力の壁を突破するためには、自分でできる事業より大きな事業にコミットしたいので、正社員でサービスの成長にコミットする仕事を探しています。#Twitter転職 pic.twitter.com/Z7aMcjTxPT
転職活動をすることを表明しましたが、
今現在自分が壁と考えていることを書きます。
私の経験上AWSの管理者権限をフリーランスエンジニアとして、任されることは少ないです。
AWSのサービスをフル活用して貢献するためには、
AWSやインフラに精通し、社外だとしてもこの人間に権限を委譲した方が生産性が高いと認定された場合に限ります。
こういった権限はAWSだけではなく様々な重要な意思決定に絡んできます。
...
rails 界隈では Sider の普及に伴い rubocop を業務で使っている方も増えてきたのではないでしょうか？
しかしながら、一度荒れ果てた荒野にrubocopを放っても成果はほとんど上がらないことでしょう。
必要なのは、すべてのコードを綺麗にするぞ！という高尚な志ではなく、現実を少し改善すれば、それでOKという意識低い気持ちな気がします。
--lint オプションrubocopには -l または --lint というオプションがあるのをご存知でしょうか？
こいつはlintオプションと呼ばれるやつで、bugに繋がりやすい警告レベルを指摘してくれます。
こいつをまずデフォルトにしましょう。
.rubocop ファイルに --lint と記述すると、rubocopのコマンドが常に--lintオプションがついた状態で実行されるようになります。
.rubocop ファイルを使うことで、プロジェクトのメンバー全員がそのオプションをつけてrubocopを実行することができるため、「 rubocop -l と実行してください！」などと呼びかける必要がなく便利です。
rubocop_todo.yml と向き合う次にこの状態で、rubocop_todo.yml を生成します。
rubocop --auto-gen-config
プロジェクトにこれ以上 --lint に違反するコードを入れないようにするためです。
rubocopを入れると、rubocop対応で色々と対応工数が増えてしまうと恐れている方もいらっしゃると思いますが、...
一般的にFactoryBotは大きなプロジェクトになってくると無駄なデータを作成する可能性が増えてきます。
例えば、こんな時。
factory :tag do
article
end
it do
create_list(:tag, 10)
# 10個タグがある場合のなんらかのテスト
end
articleがtagを複数持てるDB構造になっているとして、
tagが10個以上付いているページのfeature specなどを書きたい場合がある時に、
上記のような書き方をしてしまうと、tagが10個だけできればいいものの、articleも10個できてしまうのです。
これを抑制するために、
factory :tag do
article { nil }
end
このようにartilceは敢えてnilを渡して、validateエラーが起こるようにしておきます。
そうするとうっかり、 create_list(:tag, 10) なんて書いてもテストが落ちるようになり、、
it do
create(: article)
create_list(:tag, 10, article: article)
# 10個タグがある場合のなんらかのテスト
end
おそらく、このようなテストになってくれるはずです。
あくまでデフォルトの話であって、traitを使う分には特定のcontextの名前を入れることができるので、問題ないと考えています。
factory :tag do...
このテーマ。僕はずっとずっと悩んで来た問題です。railsdm周りで話題になってたっぽい。
ベストプラクティスというものはまだ見えない。
でも、いろいろな実績が出て来たし、自分でもいろいろやって見たのでまとめて行きたいと思います。
basecamp wayですね。
それぞれハマりどころが多くrailsに精通していないと使いにくいと思います。
DHH信者にオススメの設定です。
Rails Way は良きものだけど Basecamp Way はガン無視しますね
— たにみち (@ttanimichi) 2018年3月28日
気持ちはわかるけど、染まって見るのもなしではないかな。
部分的にreactなどのviewを使う設定。場合によってはcssもstylesheet_pack_tagを使うパターン。
個人的にはこのパターンってreact使う必要ある？という気もします。
が、例えばKPIに直結する非常に重要な機能だけをSPAにして、...
テストコードで再現テストをしてから、bugfixするやつ。
これうまく行ったら超気持ちいいけど、いつも気持ちいいとは限らないのでメモ。
だいたい再現テストコードがエッジなパターンすぎて、
仕様を説明する助けとして不適切になってしまう。
describe 'somemethod' do
subject { describe_class.new(params).somemethod }
context 'A' do
let(:params) { 'a' }
it { is_expected.to eq ('A') }
end
context 'B' do
let(:params) { 'b' }
it { is_expected.to eq ('B') }
end
# 再現テストのコンテキストがハイコンテキスト
context 'B and hogehogehoe' do
let(:params) { 'a' }
before do
# ハイコンテキストな記述
end
it { is_expected.to eq ('A') }
end
end
↑この程度なら全然いいんだけど野生のコードはこんなのじゃすまない。
このままマスターに入れてマージすると、仕様を説明することを阻害するよなぁ的に。
...
ブログを jekyll + github pages での運用から、独自のCMS(heroku + rails)に移行しました。
記事の雛形は make post みたいなコマンドを書いて、サクッと記事を書き始められるようにしてはいたのだけれども、、、
ちょっとした修正を出先や移動時間にするのにgithubに接続してブラウザから修正することにイライラしており、サクッと編集できるものが欲しかった。
jekyllのプラグインとか拡張とかに限界を感じていた。
買収が発表される前から検討していたので、半分冗談ですが、移管完成がこのタイミングになったのはこれもある。
blogはコミットを外に公開したくなかったので、privateリポジトリで運用していましたが、
microsoft買収により自分が課金する必要もないかなと思いました。
このお金はherokuに払っていくぞ！頑張れheroku！
(あといくつかのprivateリポをgitlabかbitbucketに移管すれば、コスト削減も同時に達成できます。ありがとうmicrosoft。)
この辺りのツールはスマホからも修正がかなり簡単で圧倒的に使いやすいのです。...
前回 に続いてどうやってプログラミング覚えたか？シリーズです。
こうしてHTML/CSSをなんとなく覚えた私ですが、次は動的なサイトを作りたくなっていきます。
geocitiesではhtml/css/javascriptは満足に動きますが、サイトを訪れた人が掲示板などサーバー上で動作するプログラムを置くことはできませんでした。
当時、ホームページを個人で運営している人は二つのいずれかの方法で、掲示板を運営していました。
前者は会員登録をすれば誰でも簡単に自分のサイト専用の掲示板を持てます。
後者はCGIの知識が多少必要とされますが、CGIスクリプトは配布されているものを使用すれば、動かすだけであれば、プログラミング自体の知識は必要ではありませんでした。
今でいうと、blogを始めるときにライブドアブログやアメブロを使うのか？wordpressやmovabletypeを使うのか？みたいな違いです。
wordpressを使えば様々なデザインや動きもカスタマイズできますが、ライブドアブログやアメブロではそこまでできません。
自分はカスタマイズも想定して、CGIが動くxreaと言うレンタルサーバーに自分のサイトを移管しました。
xreaにサイトを移管してから、配布されてるCGIスクリプトをサーバーで動かしました。...
きっかけはバンドを組んでないのにホームーページを作ろうとしたこと
中学校二年生の頃、バンドを組んでないのにバンドのホームページを作りたいと思っていました。
ある日、ある友達がホームページを持っていることを知り、彼にfront homepage express入門本を借り、早速サイトの制作に取り掛かりました。
その本を読み終え、geocitiesに簡単なテキストサイトを公開したように思います。
front homepage expressだけではいい感じのサイトにならず、どうしてもかっこ悪いデザインになってしまう。そこで本の巻末にあったメモ帳でhtmlファイルを編集する方法でサイトの更新を行うようになりました。
この時友達に質問したことを今でも覚えています。
sg「画像の横に文字書くのにはどうすんの？」
友達「罫線のない表を組めばいい」
tableレイアウトを覚えるとどんなデザインでも実現できるようになりました。
僕は様々なレイアウトのページをhtmlで作っていました。
htmlだけを作るのが楽しくなって、絵を描くようにいくつもサイトを作っていました。
サイトのメニューをいい感じに作れるようにframeタグもうまくつかっていました。
この頃にはエディタもterapadというお気に入りのエディタがありました。
「違う。。何かが違う。。俺のサイトはyahooとは全然違うぞ！！」
そう思った僕はありとあらゆるサイトを 右クリック→ソースを表示 を繰り返し、cssを学んでいきます。
ググりまくる中で、プロはレイアウトをdivで組むしいということを知り、floatレイアウトを覚えました。
...
jekyllにブログを変えてみました。
markdownで記事を書けるのはやはりすごい楽です。
お気に入りのエディタであるvimで書けることも素晴らしいです。
やったこと、やってないことをまとめておきます。
bloggerで運営していたブログを移管しました。
一部labelページ以外を除いて、同じURLに移行しました。
bloggerで長らく運営していたこのブログですが、
bloggerのhtmlがなかなか弄りにくいことが主な要因です。
blogger自体テーマがあまり充実していないのと、良いテーマがあっても、
それをカスタマイズするのにhtmlのようなxmlを弄るのに疲れてしまいました。
wordpressという手段もあったのですが、静的サイトジェネレータに興味があったので、
今回のような形になりました。
ちなみに静的サイトジェネレータをjavascriptで作ろうとしたのですが、
そこは挫折してしまいました。。
なんでhugoじゃないの？とかなんでoctopressじゃないの？
って質問があると思うので、書いておきます。
rubyでpluginを作れることとgithub pagesでメジャーな手段になったことくらいでしょうか。
hugoは正直魅力的なので、どこかで試してみたいとは思っています。
htmlを弄りやすいようにしたいことが、今回の動機でもあったので、
octopressはテーマは充実していますが、htmlがそんなに得意ではない自分ではoctopressのテーマは弄りにくいなぁと思いました。
あと、jekyllの方がdocsも充実しているように見えたのと、コード自体の見通しもよかったです。
...
毎年F1放送にがっかりしているF1ファンの皆さまこんにちは。koheisgです。
BSフジ、2016年のF1放送はなし 【 F1-Gate.com 】
今年はついにBSフジでの録画放送も廃止となり、日本国内でF1を見るためには有料放送の契約が必須となりました。
これを契機にCSを契約されたF1ファンも多いのではないでしょうか。
地上波での録画放送は数年前に廃止になっているので、
すでにF1を見ている人は限られた存在になっているかもしれません。
僕は現在CS契約をするかしないか非常に悩ましい決断を迫られているところです。
だって、CSの契約とか金持ちがやることでしょ。
僕は子供の頃、友達の家を下記で金持ち判定していました。
ぶっちゃけ家にいる時間なんて対してないわけですよ。
F1という番組を見るだけのために、CS契約して月数千円ってバカみたいな話です。
それでもF1という娯楽は自分は大好きなので、CS契約するか否かを迫られているわけです。
そもそも、去年F1を決勝レースは録画したりあの手この手を振り絞って見ました。
でも、結果はメルセデスの圧勝。ハミルトンは早すぎだし、大したことないロズベルグにだって勝てそうにありませんでした。
その中で、フェラーリ勢がなんとか一矢報いるかどうかを見守るF1。
そんなF1なら正直、今年は見なくていいんじゃないかという気もしてきました。
今年のF1っておもしろいのだろうか。
...
ワーキングメモリとは自分の脳内のメモのことです。
例えば、買い物に行ったときにメモがなくても、あれとこれとそれが必要と思って、
買い物を順番にすることができます。これがワーキングメモリです。
認知症予防で注目されている分野でもあります。
GTDやチケット駆動開発をしていると、自分で覚えておくべきことは、
全て何らかの形でメモをとることになります。
チームで仕事を行うときのエビデンスにもなるし、自分の記憶に依存することなく物事を進めていくことができるため、非常に大事なことです。
しかし、あまりにも自分が何も覚えておらずチケットやTODOリストを見ないと何もできないくらいに馬鹿になっているような気がするのです。
顕著な例がプログラムを書く時で、あの標準メソッドってどんな引数の順番だったっけ？とgoogleを頼ることがあまりにも多いこと。
もっと、フロー状態に自分を持っていくためにはもっと "ググらないこと" を実現していかなければならないと思ったのです。
例えばターミナルを開いている時は、開発や作業に集中できます。
ドキュメントを作っている時に仕様が全て頭に入っていれば、ドキュメントを書くことに集中できます。
自分の脳の容量を上げていけば、自分の開発スピードをあげることができるんじゃないかなぁ？
と今実践しようと思っているところです。
GTDとは少し考え方が違うのですが、inboxくらいは頭の中に入っていてもいいんじゃないかなぁと思う今日この頃なのでした。
...
php-nabeのバージョン管理に僕はphp-nabeを愛用しています。
phpenvやphpbrewなど数ある中でこれを使っています。
phpを使わないでphpを管理したいという思想に惚れた訳です。
で、たまに php-nabe ext-install extname でphpの拡張がインストールできるのですが、
下記のようなエラーがよくでます。
$ php-nabe ext-install openssl
Cannot find config.m4.
Make sure that you run '/Users/kohei-sugi/.php-nabe/php-nabe/build/php-5.3.3/bin/phpize' in the top level source directory of the module
/Users/kohei-sugi/.php-nabe/php-nabe/bin/php-nabe: line 416: ./configure: No such file or directory
そんなときは、srcのファイルの中を覗きに行って、
mv config0.m4 config.m4
をしてあげて、もう一度実行するとOKです。
自分でコンパイルしたい欲求を程よく満たしてくれるので良いですよね。。
ただ、普通にyumでphp入れたとき見たいなお手軽感がないので、recipe的な機能を作って、
コンパイルオプションとかをデフォルトで選んだりできれば良さそうやなぁなんて思ってる今日このごろ。
historyを見たところ下記のようなextを良く入れているっぽい。
php-nabe ext-install php_pdo
php-nabe ext-install php_mysql...
とあるrubyのプロジェクトを進行中に不要なファイルがたまってきました。
$ git status -b -s
# master
?? a.rb
?? b.rb
上記のファイルは必要ないので、 git clean -fd を実行します。
$ git clean -fd
Would skip repository vendor/bundle/ruby/2.2.0/bundler/gems/slim-0726c443dfdd
Would remove vendor/bundle/ruby/2.2.0/bin
Would remove vendor/bundle/ruby/2.2.0/build_info
Would remove vendor/bundle/ruby/2.2.0/cache
Would remove vendor/bundle/ruby/2.2.0/doc
Would remove vendor/bundle/ruby/2.2.0/extensions
Would remove vendor/bundle/ruby/2.2.0/gems
Would remove vendor/bundle/ruby/2.2.0/specifications
oh!!!
vendor/bundle の中のgemが消えてしまいました。。
仕方なく bundle install するわけですが、なんで .gitignore の中に入っているはずの、
vendor/bundle 配下のファイルが消えてしまうのでしょう。
自分自身 .gitignore の書き方にあまり自信がなかったので、
いろいろ調べてみましたが、特に問題なし。
git clean -fdx
...