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) + \ $(
インデントコミットで真犯人がわからなくなった場合の git blame
config_param :queued_chunk_flush_interval, :time, :default => 1 を追加したコミットがどれかを探したいとします。 しかし、git blame を見るとこんなかんじに、インデントコミットによってほぼ全ての履歴が上塗りされていてどれだかわからない、みたいな状況にどうやって真犯人を探そうかという話です。 1. git blame -w を使う インデントコミットを無視したいだけであれば git blame の -w オプションが使える。-w は比較の際に whitespace を無視してくれるオプション。git diff にもあるよね。 $ git blame -w lib/fluent/output.rb ... (省略) 14d01c71 (Masahiro Nakagawa 2013-03-27 03:56:51 +0900 1
gitでブランチを切り替えた時に何かする(例えばrbenvでRubyのバージョンを切り替えたり) - ( ꒪⌓꒪) ゆるよろ日記
タイトルの通りのことをやりたかったっぽいので。 例えば、現在のRubyのバージョンはREE 1.8.7だけど、次回リリースからは1.9.3にあげることになっている場合なんか、masterブランチはREE使うけどdevelopブランチは1.9.3で動作させる必要があるっぽいけど、checkoutするたびにrbenv localとかするのダルいしよく忘れるので全力回避したいっぽいです。 で、どうやるかというと、gitのhookでpost-checkoutというのがあり、そこに色々書くとふんわりとやってくれる風味っぽい。 gitリポジトリの.git/hooks/post-checkout をこんな風に書いておくとよいっぽい。 #!/bin/sh # Change ruby version CURRENT_BRANCH=`git rev-parse --abbrev-ref HEAD` RUBY_
Big Sky :: 意外と知られていない github 技
github で git diff from..to を表示する - #生存戦略 、それは - subtech で text/plain な diff が表示される。.. じゃなくて ... 。 http://subtech.g.hatena.ne.jp/secondlife/20121225/1356421602 github のコミットページ URL は、実は凄く良く出来ている。 例えば pull request のページ Add each Gem bundled data pointer in mrb_state by masuidrive - Pull Request #605 - mruby/mruby - GitHub Showing 17 changed files with 183 additions and 36 deletions . Show Diff Stats H
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
一人で使えるGithub Issue
Promise本での利用方法 JavaScript Promiseの本というのを書いてる それぞれのセクションレベルでIssue+pull-reqeuestsで書いてる リポジトリ => azu/promises-book 途中(後半)から積極的にIssueを使い出した Issue数:50、Pull Requests数:20 ワークフロー Issueを立てる git-issue + git-flow + percolでissueのブランチを切る [WIP] pull-requestsを立てる ref #id push -> review merge + close #id でissueも閉じる git flow finish でローカルとリモートブランチを削除
GitHub を用いた開発フロー テンプレート - ペパボテックブログ
Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scope
GitHub初心者はForkしない方のPull Requestから入門しよう // qnyp blog
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
Git ライフを快適にする知られざるコマンドたち
Git 初心者〜中級者に向けて、目立たないけど便利なコマンドを紹介します。
【翻訳】あなたの知らないGit Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
git pullのhookをglobalに設定する
git pullした際にanythingのファイルリストを更新したかったのですが、 やり方分からなかったので調べました。 まずgit pullの際のhook、 http://stackoverflow.com/questions/4185400/is-there-any-git-hook-for-pull post-mergeに記述すれば良いみたいです。 それからhookのglobalな設定、 http://stackoverflow.com/questions/2293498/git-commit-hooks-global-settings git initした際のテンプレート用のディレクトリをglobalに設定すれば良いみたいです。 なので、 $ # git initの際のテンプレートディレクトリ $ mkdir -p ~/.git_template/hooks $ # pullした時
zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita
zsh で Git 使ってる人はプロンプトにブランチ名とかを表示してる人も多いと思う。 zsh に標準で入ってる vcs_info っていうのを使うとだいたいいい感じにできるんだけど、できないことも当然ある。 例えば stash した数の表示には対応していないので、自分で無理矢理な感じで Git コマンドを呼び出してプロンプトに表示してる人もいると思う。 でも zsh 4.3.11 ぐらいから vcs_info に Hooks というのが追加されて、元の機能に自分で処理を追加できるようになってる。これを使うと好きなようにカスタマイズできるようになるので紹介する。 この記事でできるようになること こんなことがプロンプトに表示できるようになる。 使用しているバージョン管理システムの名前(svn, git, hg, ...) 現在のブランチ名 マージ失敗のエラー表示 さらに Git の場合は以下
Jenkinsで外部パラメータで与えたブランチを対象にビルドできるようにしておくと凄惨性あがって墓ドル - ( ꒪⌓꒪) ゆるよろ日記
テストが終わるまでの時間で書いてみる。 Jenkinsでジョブを実行させるときに、外部パラメータで任意のブランチを対象にビルドできると墓ドル。 例えば、自分のローカルブランチをマージするまえに、テストが通るか確認したい場合とか。 そんなのローカルでテストすりゃーいいじゃんって言われるかもしれないが、 テスト全部通すのに時間が掛かるようになってると、とりあえずCIに実行を投げておいてあとで確認するほうがずっと効率がいい。 F.Y.I: Building github branches with Jenkins ジョブの設定 「ビルドのパラメータ化」にチェックをつけて、以下のようにbranchって名前のパラメータを設定しておく。 「ソースコード管理システム」で「Branches to build」のところに、設定したパラメータである"$branch"を入れておく。 ジョブの設定は以上。上記の方
フック（hook）を使ってコミットしたら自動的にデプロイするようにする - ちなみに
Gitさんはいくつかのタイミングで好きな処理をフックできる賢い子です。 $GIT_DIR/hooks配下にタイミングごとのスクリプトが用意されていて、それを書き換えることで任意の処理を行わせることが出来ます. タイミングなどの詳しい説明はman githooksに書かれています。（最初にこれを見ていれば僕の数時間は失われなかったのに） 今回やりたかったのは、ローカルでWebサイトをこねくりまわして、気に入ったらコミットしてリモートにpush、そうすると自動的に公開用のディレクトリでpullするというものです。 やったことは、リモート側で $ cat path/to/repos/hooks/post-receive #!/bin/sh (cd /path/to/site/directory; git --git-dir=.git pull) $ chmod +x path/to/repos/
Railsで今いるブランチによってデータベースを切り替える - ( ꒪⌓꒪) ゆるよろ日記
ブランチングモデルとしてgit-flowを使っていて、メインラインとして、本番適用中のmasterブランチと、次期リリース用のrelease/9999ブランチと、メイン開発ブランチのdevelopがある。 ところが、開発中は頻繁にブランチを移動するし、ブランチによってDBのスキーマが異なるなんてザラにあるし、ブランチ切り替える度にconfig/database.ymlを書き換えるのもタルいので、こんな風に書いた。 development: adapter: postgresql database: my_app_<%= case `git symbolic-ref --short HEAD` when 'master' then 'master' when 'develop' then 'develop' when /release\/.*/ then 'release' when /ho
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
sorry
既に git 管理しているファイルをあえて無視したい - Qiita
GitHub - koichiro/git-daily: git-daily is a tool which helps you to do daily workflow easier on Git. for ruby version.
