マージコミットを含む大きめのgitブランチをcherry-pickで別ブランチに持っていくには
はじめに
マージコミットを含む大きめのgitブランチを,別のブランチに持って行きたい状況が発生したのでメモ*1.
取り込みたいブランチを1コミットにまとめ,これを取り込み先ブランチにcherry-pickマージする方法を記す*2.
なお,複数コミットを1コミットにまとめる方法について,一般にはgit rebaseでsquashやfixupを用いることが多い*3が,マージコミットに対してはうまくいかなかった*4.
そこで,ここでは取り込みたいブランチについて差分パッチを作成し適用するという方法をとった.
やりかた
# Xを1コミットにまとめるための一時的なブランチ(B_dummy)を作成 git checkout A1 git checkout -b B_dummy # B1〜B3をパッチ化(参考[3]) git diff --binary A1..B3 > X.patch # パッチをB_dummyにあて(参考[4]),B1〜B3を1コミット(=X)にまとめる git apply X.patch git add [target files] git rm [target files] git commit -m 'this is X: patch A1..B3' # 別ブランチA'1に移動し,トピックブランチB'を作成し,Xをcherry-pickで持ってくる git checkout A'1 git checkout -b B' git cherry-pick X
参考
- [1] git rebase -i はやっぱりイケてる件【git】【rebase 】【iオプション】 - DRYな備忘録 - http://otiai10.hatenablog.com/entry/2012/11/10/013925
- [2] git rebase interactive: squash merge commits together - Stack Overflow - http://stackoverflow.com/questions/1725708/git-rebase-interactive-squash-merge-commits-together
- [3] gitで差分を抽出してpatchで使えるファイルを生成 | 秋山ブログ - http://d.akiroom.com/2013-10/git-diff-extract-patch/
- [4] Git - プロジェクトの運営 - https://git-scm.com/book/ja/v1/Git-%E3%81%A7%E3%81%AE%E5%88%86%E6%95%A3%E4%BD%9C%E6%A5%AD-%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E9%81%8B%E5%96%B6#%E3%83%A1%E3%83%BC%E3%83%AB%E3%81%A7%E5%8F%97%E3%81%91%E5%8F%96%E3%81%A3%E3%81%9F%E3%83%91%E3%83%83%E3%83%81%E3%81%AE%E9%81%A9%E7%94%A8
Poderosaでコマンド実行結果をクリップボードにコピーするには
はじめに
Poderosaには,コマンド実行結果をPoderosa実行元(ローカル)のクリップボードにコピーする機能があります.
これでファイルをcat
してクリップボードにコピーとか,ディレクトリ構成をtree
してコピーとかできます.便利!
やりかた
- コマンド実行時,Enterキーを入力する代わりに
Ctrl+,
キーを入力 - するとポップアップメニューがでますので「コマンド結果をコピー(C)」を選択
Ctrl+,
でポップアップが出ない?
Ctrl+,
にキーバインドされているみたいなのですが,私の環境では適切に動作できませんでした.
キーバインドを変更することで,適切にポップアップメニューが表示できるようになりました.
- ツール > 詳細プリファレンスエディタ を選択
- フィルタに「org.poderosa.terminalemulator.commandPopupKey」を入力
- 項目をダブルクリックし,値を「Ctrl+Oemcomma」から変更(例えば「Ctrl+Shift+C」など)
参考
RSpecで複数の指定行を実行する方法
はじめに
RSpecで特定のケースのみを「複数」実行したい状況が生じたためメモ.
やり方
行指定オプションを複数回指定する.
$ rspec [file_name] --line_number [line_number_1] --line_number [line_number_2]
略記式で以下のようにも記述できる.
$ rspec [file_name]:[line_number_1]:[line_number_2]
例えば,デグレでhoge_spec.rbにおけるx行目とy行目のit文がredになってしまい,実装修正後にgreenになっていることを確認するとき,以下のように記述すればOK.
$ rspec hoge_spec.rb:x:y
また,複数ファイルにわたる場合でも記述できる.
$ rspec hoge_spec.rb:x:y fuga_spec.rb:z
実際の開発時には,他オプションも付けて以下のように実行すると良さそう.*1 *2 *3 *4
$ rspec -fd -c --seed 1234 --fail-fast hoge_spec.rb:x:y fuga_spec.rb:z
参考
- Felix Clack — Run single and multiple lines in RSpec - http://felixclack.com/post/49917595185/run-single-and-multiple-lines-in-rspec
SRP(単一責任原則)とCC(循環的複雑度)によるコンポーネント内の技術的負債の定量化
はじめに
ソースコードを静的解析することでRailsのコンポーネント(単一ファイル)の技術的負債を定量化します.
方針はこちらの記事*1に従って行います.
なお,SRPの算出はgit blameを用いて*2行い,CCの算出はrubocopのMetrics/CyclomaticComplexityを用いて行います.
# ref: 第8回 Perlによる大規模システム開発・設計のツボ(3):Perl Hackers Hub|gihyo.jp … 技術評論社 # http://gihyo.jp/dev/serial/01/perl-hackers-hub/000803 # コンポーネントの単一責務性の違反指数(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 --no-pager blame --line-porcelain $target_filepath | sed -n 's/^author //p' | sort | uniq -c | sort -rn | wc -l) + \ ( $(cat $target_filepath | wc -l) / 100 - 5) \ )) } # コンポーネントの循環的複雑度(CC) # CC=循環的複雑度が20を超えるメソッド数 function get_CC() { local target_filepath=$1 echo $( \ rubocop --format simple --only Metrics/CyclomaticComplexity --config <(echo -e "CyclomaticComplexity:\n Max: 20") $target_filepath | grep 'Cyclomatic complexity' | wc -l \ ) } # コンポーネントの負債指数(P) # P=SRP×CC+(SRP+CC) function get_P() { local srp=$1 local cc=$2 echo $(( $srp * $cc + ( $srp + $cc ) )) } # コンポーネントの負債指数(P)が大きい順に "P SRP CC ファイル名" を標準出力 for file in `git ls-files app lib | grep -E '\.rb$'`; do _srp=$(get_SRP $file) _cc=$(get_CC $file) echo $( get_P $_srp $_cc ) $_srp $_cc $file done | tee technical_dept_result.log | sort -k1,1 -nr
※gistはこちら*3
関連する過去記事
ni66ling.hatenadiary.jp ni66ling.hatenadiary.jp
*1:第8回 Perlによる大規模システム開発・設計のツボ(3):Perl Hackers Hub|gihyo.jp … 技術評論社 - http://gihyo.jp/dev/serial/01/perl-hackers-hub/000803
*2:git blameによるSRP(単一責任原則)の定量化 - どこでも見れるメモ帳 - http://ni66ling.hatenadiary.jp/entry/2015/06/25/000444
*3:技術的負債の定量化 - https://gist.github.com/KenshoFujisaki/9cefd372c9cec0814a08
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 --no-pager blame --line-porcelain $target_filepath | sed -n 's/^author //p' | sort | uniq -c | sort -rn | wc -l) + \ ( $(cat $target_filepath | wc -l) / 100 - 5) \ )) $target_filepath } # SRPが酷い順(大きい順)に "SRP ファイル名" を標準出力 for file in `git ls-files app lib config vendor script | grep -E '\.rb$'`; do get_SRP $file done | sort -k1,1 -nr
※ここではrailsのリポジトリを対象にしたため,rbファイルを対象にしていますが,別言語でも全く同様に扱えます.