gitignore公式リファレンスの要点メモ
gitignoreってどうやって書くんだっけってよくなるから、今一度ちゃんと公式リファレンスを参照して今後使いそうな・参考になりそうな部分だけ抽出したカンペを作ります。
参照元
では早速...
Files already tracked by Git are not affected
すでにgitの管理下にあるファイルはgitignoreの影響を受けない。gitの管理下にあるというのは、git add以上の操作をしているファイルが該当する。
To stop tracking a file that is currently tracked, use git rm --cached.
すでにgit管理下にあるファイルを管理しないようにしたい場合はgit rm --cached <target>とするとよい。おすすめは、git rm --cached .で一旦全部管理外から外し、git add .とすることで再度.gitignoreにマッチしないものを再度全部管理下に戻す、です。-rは再起的に削除するためのオプション、-fは強制的に削除するためのオプション。
within one level of precedence, the last matching pattern decides the outcome
複数のパターンにマッチする場合には、後から記述されているパターンが優先される後勝ち方式。
Patterns read from a
.gitignorefile in the same directory as the path, or in any parent directory (up to the top-level of the working tree), with patterns in the higher level files being overridden by those in lower level files down to the directory containing the file.
深い階層にある.gitignoreが優先される
These patterns match relative to the location of the
.gitignorefile
.gitignoreを基準にしたパスで書く
An optional prefix "
!" which negates the pattern; any matching file excluded by a previous pattern will become included again.
"!"をパターンの頭につけてパターンの否定ができる
If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular .gitignore file itself. Otherwise the pattern may also match at any level below the .gitignore level.
先頭に"/"を付けるとその.gitignoreが存在する階層でパターンにマッチするものを探す。頭に"/"がない場合には深い階層を再帰的に探索する。
If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular
.gitignorefile itself. Otherwise the pattern may also match at any level below the.gitignorelevel.
先頭または中間にスラッシュが存在する場合は記述されている.gitignoreと同階層のみを探索する
If there is a separator at the end of the pattern then the pattern will only match directories, otherwise the pattern can match both files and directories.
末尾スラッシュがあればディレクトリのみマッチするが、ない場合はファイルおよびディレクトリのどちらもマッチする。
An asterisk "
*" matches anything except a slash. The character "?" matches any one character except "/". The range notation, e.g.[a-zA-Z], can be used to match one of the characters in a range. See fnmatch(3) and the FNM_PATHNAME flag for a more detailed description.
ワイルドカードでパターンを記述することができる。"*"でスラッシュ以外のなんでもマッチ、"?"でスラッシュ以外の一文字にマッチする。
A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, "
a/**/b" matches "a/b", "a/x/b", "a/x/y/b" and so on.
アスタリスク二つはスラッシュで一つ以上の任意のディレクトリに相当する
終わり
こんなところですかね。迷ったらここを見ればいいように自分で活用しながらブラッシュアップいきます。
CSS設計の自分的な正解
CSSでスタイリングするときってidentifierの付け方とか、ファイルの分け方とか、同じ結果を達成するにしてもやり方は一通りではなく自由度が高い
だけど、何の指針もなくidentifierをなんとなくな気持ちでつけ続けると、将来的にいろんな不都合が生じてしまう可能性がある
ファイルの分け方とか、identifierの付け方とか、スタイルのモジュールの分け方や粒度とか、細かいけどひとつひとつ戦略的に決定することで保守性の高い、再利用性の高い、いけてるCSS設計ができて開発体験も開発効率も上がることができると思う
CSSを適当に書くとよく見る問題:
- 特定のスタイルを変更しようとした時の影響範囲が予想できず変更するのが怖い&したくない
- スタイリングモジュールの再利用性が悪く同じようなスタイルを繰り返し書いてしまって非効率
- 特定の要素を変更したいけど、既存スタイルの詳細度が高すぎてimportantというジョーカーを使いたくなっちゃう
- HTMLの構造やタグの種類を変更した途端に見た目が崩壊する
これらの罠を回避するためのテク:
- スタイリングを単一責務の考え方に基づいてモジュール分けする。これを進めていくとTailwindのようなユーティリティモジュールという考え方にたどり着くと思う
- idを使ったりclassを無駄に組み合わせたり、不必要に詳細度を上げるようなidentifierの付け方をしない。クラスを組み合わせるのはベースクラスの拡張とか、状態を表現するときなどに限る
- identifierには基本的にタグ名は使わずCSSにHTMLのタグ構造の知識を持たせない
- ツールや命名規則を駆使して擬似的にネームスペースを作って影響範囲を限定的にする
などなど。
さらにTailwindみないなユーティリティクラスのライブラリを使えば下記のような嬉しさがある
- CSSを修正する行為がないので影響範囲とか気にする必要がない
- クラス名を考える労力を省くことができる
pug🐶良さそうじゃんか
HTMLテンプレートエンジンのpugってたまに聞くけど、最初に知った時はそんなに魅力を感じなかった
でも、今は割といいのではないか？と考えが変わってきました
pugとは何か
pugっていうのはHTMLよりも書きやすい記法でWebページのマークアップを可能にするライブラリです
それに加え変数、条件分岐、繰り返し、importなどの便利な記法も可能にしています
とは言ってもpugで書いたファイルはそのままではブラウザが解釈できないので、HTMLへのコンパイルが必須
何がいいのか
pugを使うと開発体験をちょっと良くすることができます。ちょっとなんだけどそれが何気に重要かもと思うようになり、pug良さそうじゃんかと思うようになりました
僕が思うpugの魅力:
- 閉じタグが必要ないので、コピペミスが減る。ある程度入れ子になった要素群の位置を変えるとき、どこからどこまでをコピーすればいいか慎重にならないといけないし、何げミスる
- 変更した時のgit差分がHTMLよりも見やすい
- この閉じタグはどの要素のものだ？みたいな迷いが不要になる
こうして書いてみると、テンプレート的な機能が嬉しいというより、閉じタグが必要ないことによる嬉しみがほとんどであることに気づいた
