お手軽Gitリポジトリ分析 | 株式会社ヌーラボ(Nulab inc.)
みなさんこんにちは。Backlog課のGitチームに所属するテリーです。Gitを触ってるとたまにちょっとした集計をしたくなります。その度に検索したり考えたりするのも少しめんどくさいので、業務上ではあまり必要ではないがたまに確認したくなるようなコマンドを集めてみました。どのコマンドも書き換えることなくコピーアンドペーストで動くようになっているのでぜひ興味を持った方は自分の環境で試してもらえると嬉しいです。 リポジトリの傾向を知るコマンド 一定期間毎のコミット数を知る 「このリポジトリっていつ頃が一番盛んにコミットされていたのかなー？」 GitHubなどが提供しているこの機能実はBacklogでは提供されていません。（今後の機能開発頑張ります）そのためちょっと気になった時にコマンドで探れると大変嬉しいです。 年別・月別を知る git logの出力結果をAuthor dateだけにして--dat
リポジトリ数が1億件に達成しました！ | The GitHub Blog
2018年11月8日米国時間、GitHubは1億件のリポジトリという、大きなマイルストーンを達成しました。大きなコミュニティの力なくして、このようなマイルストーンは達成できませんでした。世界中のほぼすべての国や地域にいる、3,100万人の開発者が互いに協力することで11億件ものコントリビューションを行っています。 リポジトリは単にコードを保存する場所だけではなく、アイデア、実験、好奇心、インスピレーションが生まれる場所でもあります。このマイルストーンを祝うとともに、何百万人もの人が一緒に仕事をした結果としての開発環境におけるトレンドや功績を、The State of the Octoverse 2018(2018年10月時点の統計情報)を見ながら振り返ってみましょう。 Octoverse 2018のテーマは、11億にのぼるコントリビューションと、かつてないほど多くのプロジェクト全体で成し遂
git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
今年よかった習慣: ライフログ収集および可視化 - yasuhisa's blog
データを眺めるのが好き 収集している情報 実現方法 データから分かった知見(?) 今後 年末なので、今年買ってよかったものに引き続き、今年やってみてよかった習慣について書いてみたいと思います。 データを眺めるのが好き 昔からデータを眺めるのは好きだったんですが、今年の5月くらいから自分に関するデータをとにかく収集してみました。可視化することで何か有益な視点だったり、生活の改善点が見つかるのではないか、という目的です。色んなデータを集めまくった結果、以下のようなグラフができあがります。ちょっと画像が小さいですが、毎日の歩いた歩数や体重、気温、録画した番組名、自宅マシンの負荷状況などが載っています。 収集している情報 上の画像ではとりあえずBlogに上げれるようなデータしか見せていないですが、収集している情報としては以下のようなものがあります。使用しているスクリプトで公開できるものはgithu
Androidアプリを新規リリースする際のあれこれ - クックパッド開発者ブログ
こんにちは、投稿推進部の吉田です。 少し前に、お料理アルバムという「日々の料理を写真を記録する」ためのアプリのリリースしました。初めて会社のプロダクトのリリース作業を経験して、色々と学びがあったので共有したいと思います。 見出し releaseビルドをCIで作成する releaseビルドから不要なモノを排除する Google Playストアのリファラを活用する Google AnalyticsとGoogle Playストアの連携をする リリース直前チェックリスト releaseビルドをCIで作成する リリース版apkはコマンドから生成できる環境を整え、CIで作成するのがお薦めです。 CI上でのビルドすることで、ビルド手順の共有が不要になり、開発チームの誰でもボタン一つでビルドが可能になります。 また、ビルドをCIに任せることで、keystoreとパスワードを開発者全員に共有する必要がなくな
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Octoverse 2023: The state of open source
Codecov - The Leading Code Coverage Solution