技術的な話題この記事は公開されてから1年以上経過しており、情報が古い可能性があります。普段の開発はもちろん、確認用!作業用!などとやったり放っておくと増えていくブランチを一掃する。チェックアウトしてからやったほうがいい。ブランチをチェックアウトしてからやったほうがよさそう。技術的な話題この記事は公開されてから1年以上経過しており、情報が古い可能性があります。テストをもりもり追加したけど、それだけいい感じに動かしたいなあってやつ。つけると変更のあったファイル名だけが出力される。ちなみにブランチと書いたものの、コミットが示せればいい。みたいにハッシュとか。したらこいつをパイプしながらゴニョゴニョすればおけ。ここ最近、手元で使ってみてるのはこれ。tool実行すると、ブランチを指定できて(リモート可)、ワーキングディレクトリとの差分があったテストだけ実行できる。なくて、たまには違うブランチもやりたいよね。思ったけど、ソースだけ変えた場合って出てこないよね...。作れるし、いい感じに解析して、影響のありそうなテストだけいい感じに動かしてくれる君みたいなの。技術的な話題この記事は公開されてから1年以上経過しており、情報が古い可能性があります。Cloneそのほか勉強になった記事ギョームで使ってるあるシステムのリポジトリが大きすぎて、クローンめっちゃつらい、というかできないんだけど!となったので調べた。リポジトリの肥大化は、長年積み重なったログ、うっかりコミットされた大きなファイル、バイナリファイルの積み重ねが主な原因っぽい。つの方向があると思う。つめはリポジトリ自体のログをねじ曲げる方向。ログが原因なので、そのログから原因要素を取り除けばいいじゃん!という理解。クローンするときに工夫する方向。ログが大きすぎるのでログを最小限にしていく。リポジトリを作り直すリポジトリのログをねじ曲げるにあたって、手っ取り早い改善策はリポジトリを作り直すこと。最新の状態を手元に持っておき、リポジトリを捨て、最新の状態でファーストコミットをする。リポジトリに紐づく情報はポイしてもよい、そんな決断ができるなら一番簡単で効果も高い方法です。これからクローンするのはを楽にしたいんだけど!という用途にはちょっと違うかも。サブコマンドを使って不要なファイルを歴史から隠蔽するfilter-branchを使うと、ログを遡ってコマンドを適用していけます。これを使ってログに潜む悪のファイルを精査します。つかったことないのでわからんね、かなしみ。rewrittenこういう使い方で、まあまあ、簡単に捨てられそうですね。試しに適当なリポジトリで実行してみたら、キレイサッパリとファイルが消え去りました。...ということで、方法1はどちらもログをぶっ壊していくので、コミットハッシュが変わります。自分も含め、既にクローンなどによってリポジトリを追跡してた人は、整合性が取れなくなるので、再度ローカルのリポジトリ状況を刷新する必要がありそうです。しよう!とかそういう話じゃなくて、過去のログを持ち込まないとか、そういうところ。いうプロパティが設定でき、ログをどこまで遡ってクローンするかを決められます。...これをするとログの遡りが少なくなるので、その分早くクローンをすることができます。大きくなったリポジトリで試したらこれくらいの違いでした。秒程度にまとまって非常にすばらしい。値を増やすと補完できるっぽい。したリポジトリは、そういうリポジトリになるようで、深さを再設定しないと永遠とログが出てこないそうです。ままならなかったようですが、今は改善されたようです。ツールの類もクローンするときは全部これでええやんけ。data-src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>。